高品質のコードを書くことは、すべてのプログラマーの必須スキルの1つであり、プロジェクトのメンテナンスと共同開発を効果的に実行できます。
01序文
フロントエンドの最初の開発は、クラウドのクラウドのようなもので、すべてをまとめて書き込み、次に一緒にスクレイピングして、最後に実行できます。実際、フロントエンドの全員がページの混乱の頭痛を感じるでしょう。誰がそれを最適化したくないのですか？しかし、なぜ高品質のコンポーネントライブラリは言うまでもなく、今からコードを解放し、実際に箱から出してそれを行う成形ツールがないのはなぜですか？
初期の開発から現在に至るまで、コードは高度なデカップリングにすぎないため、各部分は独自のコンテンツに責任があり、構造、スタイル、および動作が分離されているため、コードの機能は非常に明確で何でも見ることができます。結局のところ、多くのフロントエンドは自分のWebサイトの再構築を要求しましたが、結局のところ、次世代から残った製品を引き継ぐことは誰も望んでいませんでした。
02コードメンテナンスの難しさ
フロントエンドコードの保守が難しいのはなぜですか？実際には、主に次の3つの点が原因です。
ブラウザレベル
ブラウザは私たちのフロントエンドの人々が頻繁にやり取りするツールであり、実際、ブラウザはフロントエンドファミリを生み出し、私たちの生存の基盤でもあります。ユーザーが何かを見たり、対話したりする必要がない場合、または存在する必要がない場合。ホログラフィックプロジェクションの知識はありますか？そのテクノロジーが普及したとき、私たちはどのような仕事をしていますか？
ブラウザーの互換性はますます向上していますが、主流のブラウザーは一般に多くのcss属性と互換性があります。少なくとも、Flexレイアウトのfairy属性など、サポートする必要がある最も一般的に使用される複数人の属性。特定のブラウザー（Googleなど）の使用に慣れている場合、360ブラウザーを使用しようとすると、ルートが表示されないことがあります。Google検索に慣れているように、Baiduを使用する必要があります。
そのため、フロントエンドのブラウザー間の互換性は、私たちが乗り越えなければならないハードルであり、互換性がどんどん良くなっても、IEや360のブラウザーを使用するユーザーは少なくありません。しかし、IEとの互換性は人生の浪費であるという格言があります。
技術レベル
各企業は異なるテクノロジーを使用しているため、実際には多くの企業が独自の内部フレームワークを持っていますが、内部フレームワークを使用して既存の技術フレームワークと統合する必要があり、これも頭痛の種です。入社したばかりの従業員であっても、プロジェクトを開発する前に、社内の技術フレームワークを学ぶ必要があります。
多くの企業は、jQueryの世界であるvueや創業時の反応などの妖精のフレームワークを持っていない可能性があります。プロジェクトの最下部は一夜で変更できないため、多くの企業は新しいテクノロジーの出現を知っていてもそれを使用しません探査段階にもあります。会社がコードをリファクタリングするために新しいテクノロジーを使用する必要があると想定します。または、新しいテクノロジーに対する従業員の理解が十分でないため、記述されたコードにも特定の設計上の脆弱性があります。したがって、深い理解がなければ、保守が難しいコードを書くのは簡単であり、私たちのチームにとって読み取りが困難になり、最終的には保守が難しいプロジェクトになります。
チームワーク
チームワークが本当の問題です。私たちが自分で書くプロジェクトとは異なり、私たちは好きなように書くことができ、私たちがそれを理解できないことを恐れていません。コードを送信するとき、masterブランチに直接プッシュするために他のメンバーの同意は必要ありません。これらはすべて私たちの個人的な開発慣行であり、会社レベルまたはプロジェクトレベルで、あなたは物事を選ぶだけです。
大規模なプロジェクトでは、通常、開発者が多くなります。誰もがさまざまなモジュールやさまざまな機能を担当します。誰もが独自の独立したブランチを持ちます。コードをメインブランチにマージするときに、コードを確認する必要があります。これは完璧です3.システム開発プロセス。したがって、プロジェクトが複雑になるほど、チームワーク要件も高くなります。一般的には、コード開発ルールがあり、誰もが互いに遵守する必要があります。そうしないと、通常のコードが汚染され、プロジェクトの維持が困難になります。チームワークの最大の困難は、テクノロジーではなく人です。
要約：
プロジェクトのコードを分離し、構造、スタイル、および動作を分離することに加えて、シンプルさ、再利用性、および構造の特性にも注意を払う必要があります。これを行うことができれば、プロジェクトはプロフェッショナルに見え、コードの保守性と拡張性が向上し、開発者が新しい機能やモジュールを追加しやすくなります。
03高品質の構造コード
セマンティック
HTML5が登場した後、多くの新しいタグと属性が追加され、セマンティクスの概念がフロントエンドの人々の目に現れました。構造コードを作成する前に、通常、divとクラス名/ ID名を使用してモジュールに名前を付けることを選択しましたこれは、いわゆるDIV + CSS開発モデルです。それで、このアプローチは実行可能ですか？もちろん、それは実行可能であり、他の人はそれに非常に快適です。つまり、cv操作はもう少しです。
もちろん、デメリットもあります、たとえば、最も重要なことは、構造が明確でないことです。ナビゲーションまたはモジュールを記述するか、またはdiv全体を記述するかです。この構造は明確ではありませんが、クラス名またはID名を追加しないと、コードがどのモジュールに属しているかがわかりません。そして別のポイントは、それが検索エンジンに友好的ではない、あなたのウェブサイトの構造と情報を正確に特定できないことです。
では、コードがセマンティックかどうかはどのようにしてわかりますか？非常にシンプルで、すべてのスタイルを削除して、ページ構造が適切に表示されるかどうかを確認するには、一般的なセマンティックタグにデフォルトのスタイルを設定します。表示に問題がなければ、構造は整然としており、セマンティクスはより優れていますが、そうでなければ、再度記述できます。
モジュラー
モジュール性は実際にはセマンティクスに従いますが、セマンティクスが優れている場合は、対応するモジュール性が優れています。モジュール化の焦点は、ラベルの選択が妥当かどうかにあるべきだと思います。たとえば、テキストはp / spanタグを使用し、タイトルはH1-6タグを使用する必要があります。すべてのテキストがdivをユニバーサルラベル要素として使用するわけではありません。pを使用できる場合は、divを使用しないでください。p自体はテキスト用であり、特定の基本的なスタイルがあるためです。
要約：
しかし、今ではこれらのことに注意を払っていないようです。高価値のコンポーネントライブラリの出現により、cvが直接使用する必要があるものだからです。しかし、私たちが注目しているのは、これが学習を避ける理由であるということではありません。コンポーネントが最も基本的なスタイルと構造で構成されていても、学習の背後にホイールを作るという考えが最も重要だからです。コンポーネントがビジネスニーズを満たせない場合は、CSSコードを記述する必要があります。
04高品質のスタイルコード
ボックスモデル
一般的なインタビューでは、CSSボックスモデルの理解について多少の質問を受けますが、準備ができていない場合、友達が内容を混乱させる可能性があります。ここでもう一度繰り返します。
- IE：要素の幅は、幅+ボーダー+パディングで構成されます
- 標準：要素の幅は、パディング+ボーダーを含む幅です
スタイル編成
私たちのページのスタイルをどのように書くかも私たちが考慮しなければならない問題です。それはあなたの期待に応えるためにページを書き留めるのに適切なスタイルです。
したがって、ここではスタイルの構造を参照できます。reset.css+ common.css + view.css
まず、1つ目は、基本となるスタイルに焦点を当てた基本的なスタイル標準です。ここで、リセットとは、ブラウザーのすべてのデフォルトの基本スタイルをリセットし、一貫性を保つためにすべてのブラウザースタイルを満たすことを試みることを意味します。以前にワイルドカード*を言ったときのことを覚えていますか？これは非常に激しいスタイルのリセットですが、非常に危険なオペレーターでもあります。危険なのは、ページのすべての要素ノードをトラバースし、スタイルを設定する必要があることです。ここでは、オンラインのreset.cssを使用することをお勧めします。選択する方法がたくさんあります。検索が面倒でプロジェクトがnpmのインストールをサポートしている場合は、直接npm i reset-cssを使用すると、簡単、高速、便利になります。
common.cssは、いくつかのコンポーネント関連のスタイルを参照します。たとえば、vueでコードを記述した場合、vueファイルは3つの部分で構成でき、その1つはコンポーネントに属するスタイルコードを記述します。ここでは、コンポーネントを再利用しますとても便利になります。view.cssについては、実際には上位レベルの準備であり、ページスタイルファイルに属しています。
セレクター使用
セレクターは特定のノードのスタイルを書き込むことができます。一部の学生は、自分のノードスタイルを正常に適用できると言いますが、それでもその使用方法に注意する必要がありますか？実際、CSSセレクターのマッチングスキームから始めましょう。セレクターは右から左にマッチングされます。.classul li apなどのセレクターは、最初にグローバルのpタグにマッチングし、次にaタグにマッチングします。等々。
したがって、最初の問題は、セレクターのネストが深すぎないようにする必要があることです。これは、パフォーマンスが非常に高くなるためです。IDを一意の要素と照合できる場合、他のセレクターは必要ありません。要素がより効率的にマッチングされるのは、セレクターのこのマッチングルールのためです。これは、長期検証後の結論でもあります。最後に、スタイルの継承にもっと注意を払い、何度も繰り返されるスタイルを記述しないようにする必要があります。
近年登場したcssプリプロセッサは、スタイルの記述を効果的に改善できます。オブジェクト指向の記述方法を使用し、スタイルコードをより多く再利用します。スタイラス、scssなどがあります。
コーディングスタイル
スタイルスタイル：cssのコーディングスタイルも人によって異なりますが、読みやすいように、一般的に複数行の記述を使用する必要があります。スタイルコードが1行で記述されている場合、必然的に読み取りが困難になります。後でプロジェクトをリリースするときに、コードを圧縮できます。
id / class：idセレクターは、通常、グローバルに一意の要素ノードで使用されます。要素ノードが一意であると判断された場合は使用できますが、要素ノードが一意でない場合は、クラスを使用することをお勧めします。
05高品質の動作コード
良い習慣
プロジェクトには複数人による開発が含まれるため、各人が使用する変数は自分で保守する必要があります。これにより、コードの競合を効果的に回避し、通常のコードをカバーできます。したがって、他の人のプロジェクトモジュールに簡単に影響を与える可能性があるグローバルスコープで直接コードを記述することを禁止する必要があります。それで、私たちの回避方法は何ですか？
- 対立を避けるためのチームワーク
（function（）{}）（）などの無名関数にコードを記述して、コード内の変数がグローバルではなく、この関数に属している内部変数が他の変数に属さないようにしますコードには影響があります。匿名でコードをラップすると、グローバル変数を効果的に制御し、潜在的な競合を回避できます。
- 統一エントランス
また、エントリポイントが統一された関数のファイルをロードし、関数のエントリポイントをinitとして選択して、すべての初期化操作がここで実行されるようにすることもできます。これにより、DOMReadyイベントをシミュレートできます。
- 上部にCSS、下部にJS
この操作は、すべての人が従うべき慣行である必要があります。これは、ブラウザーページの読み込みの最適化を促進し、空白ページの時間を削減し、ユーザーエクスペリエンスを向上させます。
JSレイヤー
実際、ここでの階層化はCSSの階層化と同じであり、ベースレイヤー、共通レイヤー、ビューレイヤーのフォームを参照することもできます。基本レイヤーは、異なるブラウザーの違いをカプセル化し、統一されたインターフェースを提供し、互換性のあるいくつかのタスクを実行できます。共通層は再利用可能なコンポーネントを提供し、その機能はビュー層にコンポーネントを提供することです。共通層とベース層の両方がビュー層のコンポーネントを提供できますが、共通層がより大きなコンポーネントを提供できるという違いがあります。たとえば、いくつかのドラッグアンドドロップ機能の実現。ビューレイヤーは最初の2つのレイヤーへの直接の呼び出しであり、インターフェースリクエストなどの特定の機能要件に関連する操作などのページロジックの実装です。
実用的なヒント
- レジリエンス
柔軟性とは、要件が追加されるたびにjsコードを変更することなく、顧客からの要求に簡単に対応できることを意味します。これは非常に不便です。たとえば、イベントプロキシのように、追加したノードごとにイベントリスナー関数を手動で追加しなくても、いくつかの合理化された操作を実装できます。
- 再利用性
ここで基本的に実装する関数は、最初にこのコードを再利用してビジネス関連または機能関連のコードを削減し、一度記述すればどこでも使用できるようにする方法を最初に検討する必要があります。共通であり、コンポーネント間の機能に影響を与えないことが私たちの追求です。パラメータを渡すことでメソッドを実装できます。
- 副作用を避ける
私たちが開発した基本的なコードは現在のニーズを満たすことができるかもしれませんが、使用プロセス中に望ましくないいくつかの副作用もあるかもしれません。この問題を回避するには、関数の結合が高すぎるかどうかを検討する必要があります。デカップリングなどを検討してください
06まとめ
今日は、高品質のコードを書くことについてお話ししますが、実際にはまだ手遅れである多くの側面があり、読者自身も関連情報を参照することができます。主に、構造、スタイル、動作の3つの側面から説明されています。これは、フロントエンドのhtml、css、jsに対応する基本言語でもあります。
構造に関しては、セマンティックライティングとモジュール式ライティングについて話しました。スタイルに関しては、ボックスモデル、スタイルライティング、スタイルスタイル、セレクターの使用について話しました。動作に関しては、ライティングの良い習慣、jsレイヤー化などについて話しました。
実際、具体的な実装はすべての人が理解する必要があります。これらは前任者が要約した経験です。プロジェクトの具体的な詳細は、上記のルールに従って記述できます。コードの品質レベルを向上させる必要があると思います。
