ウェブサイトデザイン分析: モジュール化 - 効率的なリファクタリング

モジュール化と言えば、おそらく最初に思い浮かぶのはプログラミングにおけるモジュール設計でしょう。モジュール設計では、プログラム設計は機能ブロック単位で行われ、最終的にモジュールの選択と組み合わせによって最終製品が構築されます。この考え方をページ構築に適用することは新しいことではありません。多くのページ構築エンジニアが、次のような段階を経てきたと思います。第 1 段階は、基本的に共通スタイルの有無を考慮せずに、複数のページのスタイルを CSS ファイルに上から下まで独自の慣習的な順序で記述し、デザインのプレゼンテーションを完成させることです。第 2 段階は、共通の色、アイコン、ボタンなど、さまざまなページから共通のスタイルを抽出し、いくつかの基本要素の再利用を実現します。第 3 段階は、ナビゲーション、著作権情報などの共通機能モジュールを抽出し、いくつかの共通モジュールの再利用を実現します。

先ほど説明した第 3 段階の方法にはすでにモジュール思考が含まれており、多くのチームには成熟したモジュール開発ソリューションもあります。モジュラー構造について初めて聞いたのは、韓国のインターネット企業で働いていた3年前のことでした。一部の製品では、共通の機能モジュールまたはコンポーネントをモジュール化して、モジュールの独立性と再利用性を最大限に高めるUIOという手法を使用する必要がありました。当時、私のようにチームの多くの同僚は、この作業方法はコーディングの自由を制限すると考えていました。構造上の制約が多すぎると、作業効率が低下しました。さらに、製品間で矛盾があったため、最終的にはチーム全体には適用されませんでした。

では、モジュール構築アプローチを採用すると、どのような利点があるのでしょうか。おそらく最初は適応プロセスが必要で、チームメンバーが当時の私と同じような考えを持つことになるかもしれませんが、全員がこの作業方法に適応して熟達すると、ページ構築の効率が間違いなく大幅に向上します。

チームが、ページ数が多く作業負荷も大きい緊急プロジェクトを受け取ったというシナリオがあるとします。最初のチームは、チームリーダーが各人に数ページを割り当て、全員が自分のページを完成させて一緒に納品します。異なるページ間で構造が似ているモジュールについては、より慎重なチームであれば、誰かに書いてもらい、それを必要とする全員にコピーしてもらうことに同意するかもしれません。あまり気にしない場合は、全員に自分のページのコンテンツをすべて書かせ、タスクの完了に集中します。 2 番目のチームは、すべてのページを事前に共通または繰り返しのモジュールに分割し、モジュールの独自性に応じて各人に割り当てました。一部の人はフレームワークの構築を担当し、一部の人はモジュールの作成を担当し、最終的にフレームワークとモジュールが統合されました。その後、ページは開発作業計画に従って順番に配信されました。比較の結果、2 番目のチームは複数の人が協力してページを作成するため、開発に必要な最初のページを最速で作成でき、後の段階ではページ内で再利用可能なモジュールをさらに見つけることができます。最終的には、最初のチームと比較して全体の作業時間を半分に短縮できる可能性があります。モジュールの再利用はチームの作業時間に大きな影響を与えるだけでなく、下流の開発者が同じモジュールを再コーディングまたは再開発する必要がなくなることも意味します。さらに、製品のアップグレード時に、2 つの動作モードのコード冗長性とコード拡張性に大きなギャップが生じます。さらに、チームで BIGPIPE または LESS 開発手法を使用する場合、CSS モジュール化は協力するための最善の手段であり、必須です。

作業にモジュール方式を採用することを決定する場合、特定の原則に従うことが、モジュール方式を機能させるのに大いに役立ちます。

かつて、オブジェクト指向 CSS に関する記事で、オブジェクト指向 CSS には、構造をスキンから分離し、コンテナーをコンテンツから分離するという 2 つの主な原則があると指摘されていました。最初の原則はモジュールの考え方に反映されており、これはモジュールの設計と制作をレイアウトフレームワーク自体から分離することとして理解できます。つまり、モジュールを特定のレイアウト専用のスタイルで記述することはできません。これは、スキンの変更機能を備えたWeiboのような製品に特に当てはまります。モジュールが多くのスタイルを記述したり、異なるスキンスタイルで構造を変更したりする必要がある場合、このモジュールの制作は失敗です。2番目の原則は、レイアウトとコンテンツの分離について説明しています。レイアウト内の特定の位置は、特定のタイプのコンテンツのみを配置するために使用する必要はありません。これは、モジュールの柔軟性と再利用性として理解できます。

次に、チームコラボレーション開発の原則を遵守します。この仕様には、ファイルディレクトリ構造、ファイルとスタイルの命名仕様、画像スプライト仕様、モジュールの分割と呼び出し仕様などが含まれます。たとえば、ファイルディレクトリの深さに関する規制、共通スタイルの使用規制、モジュールスタイル名の一意性規制、モジュールファイル名とスタイル名は一貫している必要がある規制などがあり、誰もが作成するモジュールが統一され、標準化されていることを保証します。

構造的表現形式に応じてモジュールを分割する原則。これはモジュールプログラミングとはまったく異なります。通常、プログラミング開発ではモジュールを機能ごとに分けますが、ページ構築では、異なる機能を持つモジュールが同じスタイルを示すことがあります。モジュールスタイルの再利用を最大限にするために、モジュールを機能ごとに分けることはできません。簡単に言えば、同じ外観構造を持つモジュールを1つのモジュールにまとめることができます。Weiboの右側のモジュールを例にとると、「興味のある人」と「おすすめのアプリケーション」のモジュールの外観は同じで、左側に写真、右側にテキストと機能ボタンがあり、同じスタイルのモジュールです。

モジュールの安定性の原則。私はよく新人に「自分の書いたコードの品質が平均的な人のものより優れているのはなぜだと思いますか？」という質問をします。ほとんどの人は、セマンティクスに従い、不要なネストを減らし、コードをできるだけ簡潔にしていると答えます。セマンティクスやコードの簡潔さは、品質を評価する上で確かに重要な側面ですが、データトラバーサルの合理性、DOMノードの操作性、拡張による破損への耐性を考慮したコードになっているかどうかの方が、ページ構築エンジニアのレベルをより反映できると思います。

モジュール適応性の原則。これは、あらゆるモジュールの幅と高さを可能な限り適応させる必要があることを意味します。特別な状況がない限り、モジュールの幅と高さを設定しないでください。この原則を採用して作成されたモジュールは、優れたプラグアンドプレイ機能を備えており、ページスプライシングを効率的に完了するための重要な前提条件です。各モジュールの幅が定義されている場合、異なるレイアウトでは、現在のレイアウトに適応するために各モジュールの幅、高さ、余白、その他の属性を再定義する必要があります。

マージンボトム原則。一般的に、Web ページのレイアウトは上から下へのフロー レイアウトです (複数列構造も各列内のフロー レイアウトと見なすことができます)。したがって、モジュールごとに統一された margin-bottom を事前に設定して、統一された間隔の目的を達成し、一部のモジュールでは上マージンを設定し、一部のモジュールでは下マージンを設定する状況を回避できます。 （左右の間隔は通常レイアウトフレームスタイルによって設定されます）

チームの協力規範と遵守すべき原則を策定した後、完全に自分の考えに従って作業を開始できるわけではありません。チームの協力は多方向です。チーム内のサポートに加えて、他のチームのサポートも不可欠であるため、次の 2 つの前提条件も必要です。

デザインはグリッドに厳密に従う必要があります。モジュールは独立していますが、最終的な製品は完全に静的なページであるため、最終的にはレイアウトにネストされます。分離されたモジュールを、デザイナーの意図と製品要件を満たすページに最短時間で組み合わせるにはどうすればよいでしょうか。グリッディングはスピードを保証します。グリッディングに従って厳密に設計されたレイアウト フレームワークでは、エンジニアはレイアウト フレームワーク スタイルと列の内部および外部の間隔を設定するだけで済みます。その後の作業では、ページで使用するモジュールをネストし、対応するモジュールのスタイルを呼び出すだけです。モジュールの適応性により、すべてのモジュールが完全に準備されていれば、通常、ページを組み立てるのに数分しかかかりません。

製品、デザイン、インタラクションの標準の統一。通常、プロジェクトの特定の段階では、製品と設計をモジュールに統一することは比較的簡単です。ただし、同じプロジェクトの異なる段階、特に異なるプロジェクト間または異なる製品間で標準的な統一を実現することは簡単な作業ではありません。仕様の統一性に問題がある場合、モジュール化はプロジェクトの特定の段階でしか行われません。新しい機能や新しいコンテンツが追加されるたびに、まったく新しいモジュールスタイルを追加する必要があります。移植性や再利用性が大幅に低下し、期待した効果が得られません。もちろん、製品は常に変化し、革新しています。製品を特定の仕様に従って設計することを永遠に要求することはできませんが、段階的に双方にメリットのある解決策を模索するために協力する必要があります。 Weibo では、各関係者による長期にわたる努力、特にインタラクティブ デザインによる製品機能コンポーネントの統一を経て、構築された WDL 仕様ライブラリがモジュール化に大きく貢献しました。

実際の状況を見ると、すべての条件、特に 2 番目の条件を満たすことは必ずしも順調ではないことがわかります。しかし、一歩引いて考えてみると、モジュール化をすべてのプロジェクトやすべての製品で長期的かつ安定的に最大限の役割を果たさせることはできないとしても、少なくとも、モジュール化がチームのすべてのプロジェクト タスクにもたらす効率性の向上は得られます。

全員の努力によりすべての条件が満たされ、チーム内でモジュール作業方式がスムーズに実行できたとしても、さまざまな問題に遭遇する可能性があります。避けられない問題の 1 つは、製品機能のアップグレードによるモジュールの変更です。このとき、元のモジュールを修正するべきでしょうか、それとも新しいモジュールを開始するべきでしょうか。2 つ目はモジュール分割の程度です。モジュールの表示と機能分割が曖昧な場合があります。特定のコンテンツをパブリック スタイル、モジュール、またはページ固有のコンテンツに分類するかどうかは、意見が分かれる場合があります。3 つ目はモジュールの分類です。簡単に検索できるように、どのような分類方法を採用すればよいでしょうか。同様の問題はたくさんあります。さまざまなプロジェクトや状況では、特定の問題を具体的に分析する必要があり、チームの知恵を発揮して最も合理的な対応策を見つける必要があります。

実装中にさまざまな問題やチームワークへの抵抗に遭遇するかもしれませんが、このモジュール式のチームビルディングの作業方法に徐々に慣れていくと、きっと気に入るはずです。そして、チームが各タスクを効率的に完了すると、人々もあなたのチームを好きになるでしょう。

(オリジナルのWeibo UDCブログ投稿。転載および出典の明示を歓迎します。購読も歓迎します)

原題: ウェブサイトデザイン分析: モジュール化 - 効率的な再構築

キーワード: ウェブサイト、モジュール、効率的な再起動モジュール、まず、プログラミング、機能ブロック、ウェブマスター、ウェブサイトのプロモーション、収益化