アイデア、計画、アプローチ、方法論など、すべての情報を棚に置く必要があります。
私は障害についての考えが怖いです-私はすべてを体系化し、個人的なメモ、記事または文書に入れようとします。
しかし、システムが機能せず、リソースが制限されており、タスクの詳細が理想的な概念に対応していない場合はどうすればよいでしょうか？ カットの下で、開発方法論と階層化されたCSS組織システムに関する「厳密性のモデル」についての私の考えを共有します。
すべてを文書化する！
ドキュメントは、開発中に絶えず発生する問題のほとんどをカバーする必要があります。 新しい問題が発生した場合、すべての適切で最良のアプローチを書き留めて、再発明しないでください。
このシステムは、すべてを管理し、問題に備えます。
ドキュメントを暗記するのではなく、問題が発生した場合に解決策を探す場所を知ることが重要です。
世界は完璧ではない
実際には、理想的な方法がうまくいかない場合や、費用がかかりすぎる場合によく起こります。 方法論については細部まで考え抜くことができますが、明日は、製品を損なうことなく、一般的なコームとは一致しない新しいものが必ず登場します。
私たちが取り組む必要のあるプロジェクトの詳細は、互いに大きく異なる可能性があり、理想的な方法論の概念を根本的に再定義します。 BEMは Yandexにとって理想的ですが、中小規模のプロジェクトでは機能せず、害を及ぼすことさえあります。
会議や記事では、誰もが自分の経験、問題の解決策を共有し、ほとんどの場合、同僚の経験を自分のプロジェクトで直接使用することはできません。 最良のアイデアを導き出し、それらの方法論と文書でそれらを強調する必要がありますが、これを慎重に考えて文書化するのは常にそうではありません。
プランb
各方法論には独自の「厳密なモデル」が必要です。最も基本的なルールを強調する必要があり、例外を説明することを忘れないでください。 方法論のすべての原則は、基本的なルールから些細なルールまで、厳密なレベルに分割する必要があります。
さまざまな予期しない状況の場合に、アクションプランを指定せずに主な方向を設定するだけでは不十分です。 システムは、主要な基盤が制御不能になった場合でも機能するはずです。
無駄な計画を常に考え、期限の厳しさ、チームワークの問題、クライアント/マネージャーの気まぐれなどの外部要因の攻撃に備える必要があります。
主なものを覚えている
基本的な概念を常に覚えておくことは重要です。 廃棄物計画の存在は、それを使用しなければならないという意味ではありません。 最後に立ち、理想的なシステムを導入する必要があります。これは、フォールバックアプローチへの切り替えの危機にfeelしていると感じた場合のみです。
「予備」計画はないはずであり、すべてのシナリオは根本原則から考慮されるべきです。 システムは全体的なままであり、自転車スタンドではなく、あらゆる包囲に対応できる要塞を構築する必要があります。
マッス
私たちのCSS組織システムを一般に公開するために、私は元々、ドキュメントにバランスの取れた抽象性の概念を入れました。 基本的な基礎と推奨ルールがあります。
方法論は万能薬として認識されるべきではなく、すべてを熟考してすべての可能なシナリオを網羅することは不可能です。 MCSSは、独自のドキュメントの中核に組み込まれ、独自の製品のニーズに合わせて切り取られる必要があります。
厳密さと、特定のプロジェクトに合わせてシステムを調整する機能の両方を維持しながら、カミソリのエッジのバランスを取ることは困難です。 将来的には、モジュールごとに方法論を開発し、基盤をすべての基礎として残し、開発者がドキュメントの最も適切な部分を選択する機会を与えることが計画されています。 次に、基盤を含む各モジュールは、独自の厳密なモデルを維持する必要があります。
ドキュメントは、アドバイスや提案のために公開されています！ 近い将来、MCSS c Web Standards Daysのビデオプレゼンテーションと付随する記事がアップロードされます。