2022年Webフロントエンド開発プロセスと学習ルート(詳細版)

序文

フロントエンドは人間とコンピューターの対話とユーザー エクスペリエンスに重点を置き、バックエンドはビジネス ロジックと大規模なデータ処理に重点を置きます。理論上、ユーザー指向の製品では、すべての問題 (製品、設計、バックエンド、さらには目に見えない問題も含む) がフロントエンドにさらされ、一部の問題 (データの問題、計算の問題、セキュリティの問題など) のみがフロントエンドにさらされます。 .) バックエンドが露出しているということは、フロントエンドが搬送と接続において重要な役割を果たしているということです。

フロントエンド技術の更新は日々変化しており、フロントエンドフレームワークの技術選択は争いがあり、視覚的な美しさのトレンドは常に変化しており、視覚化効果は非常にクールであり、ユーザーの操作システムは徐々に洗練されており、フロントエンドフレームワークの技術選択は常に変化しています。スマートデバイスのアップグレードと適応は終わりがありません。これらすべてにおいて、フロントエンドのフィールドとフロントエンドの学生には、トスをすること、トスするのが大好き、そして繰り返しトスすることという 1 つの要件があります。

1. フロントエンド開発プロセス

見直しが必要

一般に、要件レビューを行う場合、PRD にはインタラクティブなドラフトのみが存在し、ビジュアルなドラフトはまだ存在しません。レビューが終了し合意に達した後、ビジュアルドラフトを出力する必要があります。

1. 需要分析: 需要ポイントを 1 つずつ検討し、需要の合理性、対話型レビュー、論理的な分類、不足している可能性のある部品を検討します。

ヒント: ロジックの並べ替えのプロセスには多くの時間がかかり、開発プロセス全体で実行されます。

2. 関与するチャネル/環境:

チャネルと環境は需要の盲点となることが多く、テクノロジーの選択と開発の進捗に影響を与える重要な要素でもあります。

  • アプリ: アプリのネイティブ ページ、アプリの埋め込み H5、アプリの埋め込みアプレット。
  • 小規模プログラム: テクノロジー スタックの観点: 小規模プログラムのネイティブ ページ、小規模プログラムに埋め込まれた H5、アプリに埋め込まれた小規模プログラム。
  • 通常の H5: Wechat H5、M ステーション (つまり、通常のブラウザ環境)
  • B面:運用管理プラットフォーム等

3. 実現可能性分析: 実現に技術的な困難があるかどうか、および他の依存条件があるかどうか。

データ ソース: インターフェイス、構成可能およびフロント エンドによってハードコーディングされたもの。構成可能な部分はフロント エンドによって読み取られるか、インターフェイスによって読み取られてからフロント エンドに返されます。ヒント: 構成可能な柔軟性はリスクと正の相関関係があります。

異常なフロー設計: フォールト トレランス、災害復旧、ボトムアップ、ダウングレード、フォールバック メカニズム、リスク制御可能。prd は通常、正常なフローのロジックのみを記述しますが、異常なフローについては研究開発生の協力が必要な場合が多く、総合的な検討を行う必要があります。

6. 需要の変更: 需要が明確でない場合、需要が変更される場合、需要が追加される場合、需要が削減される場合、時間の追加、時間の変更、人員の追加などが発生した場合、リスクを考慮する必要があります。事前に予測されていた。

ビジュアルレビュー

1. 進捗状況のフォローアップ:ビジュアル ドラフトは複数回に分けて納品されますか、それとも一度に納品されますか? これが最初に考慮すべきことです。

過去の経験によると、フロントエンド プロジェクトの進捗の遅れの半分はビジュアル ドラフトの進捗に依存しており、新しいページの開発のため、フロントエンドの作業の 30% ~ 50% がページの作成にかかっています。工事。

2. ビジュアルドラフトのファイル形式:

  • Sketch プロトタイピング ソフトウェア: .sketch 形式。通常、視覚的なドラフトを描くために使用されます。
  • Figma プロトタイピング ソフトウェア: .fig 形式。
  • Axure プロトタイピング ソフトウェア :: .rp 形式。Axure は通常、インタラクティブなドラフトを描画するために使用されます。忠実度の高いモックアップを出力する場合は、Sketch または Figma をお勧めします。
  • Photoshop ソフトウェア: .psd 形式。画像処理を専門とするもちろん、CP アウトソーシング担当者の中には、単一のスキルを持ち、PS を使用してビジュアル ドラフトを出力することを好む人もいます。
  • Adobe Illustrator ソフトウェア (AI ソフトウェアと呼ばれます): .ai 形式。ベクターグラフィックスを作成します。
  • Adobe After Effects (AE) ソフトウェア: .aep 形式。アニメーションを作成します。

備考: Sketch は、Mac プラットフォームに固有のプロトタイピング ソフトウェアであり、最もよく知られており一般的です。Figma は 最近人気のあるフルプラットフォームのプロトタイピング ソフトウェアであり、Sketch に代わる傾向にあります。

【ポイント】 ビジュアル入稿の際、ビジュアル系学生は「寸法入り」のビジュアル仕様ファイルを出力する必要があります。

3. 要件を確認します。要件とインタラクション設計のすべての設計ポイントがカバーされているかどうかを確認します。

4. 視覚的な仕様を確認します。

  • スタイルと色がページと商品の全体的なスタイルと一致しているかどうか。
  • サイズ仕様:モバイル端末上のモックアップの幅は750pxです。
  • タイポグラフィー、配置、一貫性。基本的なデザイン原則を理解するには、「誰もが読むデザインの本を書く」という本を読むことをお勧めします。
  • フォント: フォント サイズ (通常は 12 ピクセル以上、特に 10 ピクセル以上は小さい)、フォントの太さ (太字の属性値は 700 であることに注意してください)、および特殊なフォントフォントの著作権問題には特に注意してください。

5. どの図がフロントエンド構築用であるか、どの図がハードコーディングされた画像リソースであるか、どの図が構成可能であるか (構成可能な図では、各要素を分解する必要があります。この要素を背景図にマージするか切り取る必要があるか)別途、データを読み取ります。

6. 画像カット形式:png(透過形式)、jpg

カット画像の画像サイズは大きすぎないように注意してください。モバイル端末上の大きい画像(カーテンポップアップウィンドウの背景画像など)は50kb以内、小さい画像は20kb以内を推奨します。 画像は TinyPNG で圧縮できます– WebP、PNG、および JPEG 画像をアップロードする前に インテリジェントに圧縮します。

7. 複雑なグラフィックスやアニメーションの難易度や実装方法、技術的評価。詳細については、次の「技術選定」を参照してください。

スケジュール評価

1. スケジュールには通常、次の要素が含まれます。

  • 開発時間: ビジュアル構築時間、インターフェイス ドキュメント (インターフェイス プロトコル) 配信時間、フロントエンドとバックエンドの共同デバッグ時間、セルフテスト時間
  • 乗り換え体験時間
  • ターンアラウンドタイム
  • 開始時刻 (およびビジネスの開始時刻を確認する必要があります)

2. スケジュールを評価するときは、インタラクティブなドラフトではなく、ビジュアルなドラフトに従ってスケジュールを設定しますこれが最初に強調すべきことです。新しいページの開発では、フロントエンド作業の 30% ~ 50% がページ構築で行われます。インタラクティブなドラフトだけを見ていると、実際の開発ワークロードを評価することは不可能です。

3. フロントエンド開発作業には、概要設計、ビジュアル構築、ロジック コード、フロントエンドとバックエンドの共同デバッグ、セルフテスト、転送経験が含まれます。各項目を個別に分解して評価する必要があり、それらを合計して全体のスケジュールが作成されます。

4. スケジュールを立てるときは、ビジュアル ドラフトの遅延、不明確な要件、インターフェイスの進捗状況、テストの進捗状況など、他の依存要因を考慮する必要があります。もちろん、最も重要なことはオンラインの進捗状況です。緊急のプロジェクトの場合、発売時期に応じて開発スケジュールが前後することがよくあります。

5. 開発段階に入った後、テスト部門とテストリソースを調整し、転送時間を確認します。大規模プロジェクトや重要なプロジェクトの場合、時間を確保するために要件レビュー段階で事前にテスト部門に通知する必要があります。

6. 他のプロジェクトを並行して開発している場合は、スケジュールを立てるときに自分用のバッファを予約する必要があります。2 つのプロジェクトを並行して開発するのは一般的ですが、このプロジェクトがテストされているときは、他のプロジェクトの実行を避けることが困難になることがよくあります。

7. 開発スケジュール: 開発スケジュールに変更がある場合、特にテストスケジュールのリスクを評価するために、他の関係者に直ちに通知する必要があります。テスト スケジュールは、開発スケジュールよりも変更が困難です。

テクノロジーの選択

テクノロジーの選択は常に変化しており、100 の学派が争っています。ここでは、市場のテクノロジー スタックではなく、部門で一般的に使用されているテクノロジーの選択をリストする必要があります。

1. ページ開発フレームワーク:

(1) マルチターミナルページ:(ミニプログラムネイティブページ、H5)

注 2: 一部のビジネスでは、最初は H5 のみが実行され、その後の反復ではアプレットのネイティブ ページが必要でした。これもニーズ評価に考慮する必要があります。

(2) H5ページ:Vue.js フレームワーク、Reactフレームワーク

(3)アプリ側:

  • Android開発言語:Kotlin(新)、Java(旧)
  • iOS開発言語:Swift(新)、Objective-C(旧)

(4) B サイド開発、UI フレームワーク:

(5) Node.js バックエンド開発フレームワーク:

  • Koa: 新世代の Node.js フレームワーク。
  • Egg.js : Egg は、Koa に基づいてさらにカプセル化されたエンタープライズ レベルの Web 開発フレームワークです。
  • Express: 古い Node.js フレームワーク。

2.CSSプリプロセッサ:SASS

3. 複雑なグラフィックやアニメーションの難易度や実装方法、技術的評価:

  • gif アニメーション: 使用しないようにしてください。ファイルが大きすぎるため、効果がぼやけてしまいます。

  • CSS3 アニメーション: 単純な通常のアニメーションに適しています。例: Swinging Fish京西工場

  • Canvas : Canvas アニメーションと画像を共有するアプレットは Canvas で描画されます

  • 3D アニメーション: WebGL ( Three.js は WebGL の包括的なライブラリです) 一般的なケース: 太陽系

  • ゲームフレームワーク:Cocosエンジン

アウトラインデザイン

  • 需要の背景とリソース
  • リスクアセスメント
  • テクノロジーの選択
  • プロジェクト構造設計
  • 主要な機能ポイントのロジック設計
  • スケーラブルで再利用可能な設計
  • 依存関係インターフェース
  • ワークロードの内訳とスケジュール設定

開発リンク

1. コード設計:

(1) ディレクトリ構造の設計、コードスタイル

(2) 公開コンポーネントとツールの設計:再利用性、高い結合性、低い結合性の原則を確保します。Jingxi プラットフォームのパブリック コンポーネントを再利用できるものと、コンポーネントとユーティリティを個別に記述する必要があるものはどれですか。

(3) ポップアップ ウィンドウの設計: ページに複数のポップアップ ウィンドウがある場合は、最初に抽象ポップアップ ウィンドウの基本クラスを設計することをお勧めします。ポップアップ ウィンドウを設計するときは、次の点を考慮する必要があります

  • 設計原則: 拡張が容易、再利用性が高い
  • コードの重複を避ける
  • 同時に複数のポップアップを避ける
  • ポップアップ ウィンドウの位置は厳密に中央に配置する必要があります (画面サイズの変化によってポップアップ ウィンドウの位置がずれることはできません)。
  • スクロールの貫通異常に対処します。

2. 視覚的な構成:

(1) バックエンドがインターフェースを開発するとき、フロントエンドはビジュアル構築を行い、ビジュアル構築が完了した後、フロントエンドはモックデータを通じてインターフェースを調整し、インターフェースドキュメントの定義に従ってフロントエンドロジックを記述します; チューニング段階。

(2) フロントエンドの子供用シューズが自分で写真をカットすることを学ぶことをお勧めします。これは、より制御可能であり、通信コストを削減できます。基本的な PS と Sketch の操作を学ぶだけで、フロントエンド フィギュア カッターの資格を取得できます。

(3) 通常のスタイルやアニメーションの場合は、画像の代わりにコードを使用することをお勧めします。写真を使用するとページを開くパフォーマンスが低下し、大きな画面での表示効果が比較的ぼやけます。

(4) カットアウトの寸法要件: 幅 100% は 750px となります。

(5)ピクセル レベルのビジュアル ドラフト:スニペースト スクリーンショット ソフトウェアを使用し、F1 を押してスクリーンショットを表示し、F2 を押してテクスチャを表示し、テクスチャの透明度を 50% に調整して、テクスチャをピクセル レベルでフロント ページと比較することをお勧めします。 

3. ビジネスロジックの実装:

(1)マインドマップを使ってビジネスロジックを整理し、その後手書きでコードを書くことを推奨します。マインド マップは、ロジックを明確にし、イベント後にレビューし、一目で効率的に他の人に説明するのに役立ちます。重要なのはアイデアであり、どのツールを使用するのがよりクールであるかではありません。

(2) インターフェースを呼び出す場合、フロントエンド自身のセキュリティ境界を明確にする必要があります。インターフェースフィールドが異常であると仮定すると、フロントエンドは独自のダウングレード措置を講じる必要があり、フィールドを完全に信頼して信頼することはできません。その結果、真っ白な画面が表示されたり、異常な操作が行われたり、ページがハングアップしたりすることがあります。

(3) 製品に必要なビジネスロジックの完成に加え、異常フローの設計やディザスタリカバリも常に考慮する必要がある。

(4) 多くのフロントエンドの子供靴が要件を作成するとき、彼らは prd を注意深く見ることを好まない習慣があり、インタラクティブ ドラフトとビジュアル ドラフトに対してのみ開発します。これにより手間は省けますが、次の 3 つの手順を忘れてはなりません。

  • 開発前に、製品子供用靴の prd の詳細を再度検討する必要があります。
  • 開発の過程においては、随時製品子供靴とコミュニケーションをとり、確認を重ねていきます。
  • 展開が80%に達したら、自分でprdを比較し、漏れがないか逐語的に読んでください。

4. 非機能要件。ビジネスコードを作成した後も、磨き上げる必要がある詳細がたくさんあります。例えば:

  • さまざまなチャネルを通じてシナリオを共有する
  • ppms 設定チェック: 動作設定側を検証する必要があります。これは製品の動作のためであり、設定は可能な限り人間化されている必要があります。
  • 埋没ポイントの追加: エクスポージャーレポート、クリックレポート、呼吸レポート
  • モニタリングレポート、テストレポート、badjsレポート
  • 重複したコードの合理化
  • console.log やデバッガーなどの冗長なコードを削除します。
  • 画像やフォントなどの静的リソースの圧縮
  • 一般的なパフォーマンスの最適化: スケルトン画面 (オンデマンド)、画像の遅延読み込み、画像のプリロード、手ぶれ補正スロットリング、表示領域での長いリストのスクロールから動的読み込みまで
  • 完璧なユーザー エクスペリエンス: 戻り位置、スクロールの浸透
  • 画面適応
  • 小さなプログラムコードのスリム化
  • 災害復旧訓練

5. コードの提出:

  • コードの競合を減らすために、最初に git pull、次に git Push を実行します。
  • コミットの粒度はできるだけ細かくする必要があります
  • コミットする前に、コードの差分を確認し、各行の変更を確認して、不必要な変更を送信しないようにしてください。
  • コミットメッセージの一般的な形式: feat、fix、docs、merge
  • コードをマージするときに競合が発生した場合は、コードを送信する前に必ず競合を解決してください。競合に他の人のコードが関係している場合は、対応するクラスメートを見つけて一緒に解決する必要があります。

6. セルフテスト:

  • prdと比較して、漏れをチェックし、空いた部分を埋めます。
  • エミュレータではなく、実際のデバイスでページを体験してください。
  • 後続のテストの進行をスピードアップするために、いくつかのテスト ケースを作成します。先ほど整理したマインドマップは、実はテストに最適な素材なのです。

製品体験

1. エミュレータではなく、実機で体験してください。iOS と Android の両方のエクスペリエンスを比較するのが最善です。

2. 体験中に、さまざまなトドリストを記録して分類します。

  • 確認すべき要件リスト: いくつかの小規模でリスク管理可能な需要ポイントを、健康診断の段階で子供用靴の製品に提示することができます。
  • 開発未完成リスト: 子供用靴の製品でどのような未完成部分を明確に説明する必要があるか。
  • 既知のバグリスト
  • 体験問題リスト: 体験中に製品フィードバックの問題を記録し、後で子供用の靴をテストするためにそれらを同期します。
  • 依存関係リスト: インターフェース、ビジュアルカットアウト、実際のテスト環境など。

コードレビュー / コードレビュー

コードレビューはテスト中に行うことができます。

レビュー順序:

  • ビジネスコアロジック
  • コーディング標準
  • 重要な位置やピットを踏みやすい場所には詳細なアノテーションが必要です
  • システム保証(監視、災害復旧、ダウングレード)
  • システムのセキュリティとリスク
  • ユーザー体験

ビジュアルウォークスルー

テスト中に視覚的なウォークスルーを実行できます。

視覚的な子供用の靴にはすべてピクセルの目があり、1 ~ 2 ピクセルの違いがあってもそれを見ることができます。したがって、フロントエンドの子供用靴のセルフテストを強化し、ピクセルレベルで視覚的なドラフトを復元するよう努めることをお勧めします。

フロントエンドの子供用靴には Snipaste スクリーンショット ソフトウェアを使用し、F1 を押してスクリーンショットを撮り、F2 を押してマップし、テクスチャの透明度を 50% に調整して、ピクセルでテクスチャをフロントエンド ページと比較することをお勧めします。レベル。

テストセッション

1. セルフテストの品質を強化することをお勧めします。テスト段階に入ると、子供用の靴は煙テストが行​​われ、品質が基準に達していない場合は返送されるため、非常に恥ずかしいことです。

2. セルフテスト、テスト、リリースに必要なメインプロセスのチェックリストを整理し、各イテレーションで使用できます。

紹介メールの基本要素には次のものが含まれますが、これらに限定されません。

  • prd リンク、モックアップ リンク
  • ページリンク
  • プロジェクト関係者
  • データ構成システム
  • ホストエージェント
  • インターフェイスのドキュメント
  • 簡単な設計、フロントエンド開発の仕上げ(ある場合)
  • テストケース (ある場合)
  • コア ビジネス ロジックのコーミング (存在する場合)
  • 体験問題一覧
  • テストの焦点に関する推奨事項
  • リスクアセスメント

3. 子供の靴によって発生したバグ リストをテストするには、開発学生は XX 時間以内に完了する必要があります。完了しないと QA から促されます。

4. バグチケットの数を制御する必要があります。そうしないと、責任を問われて再開されます。同様の問題については、テスト用の子供用の靴を同じバグ リストにマージすることをお勧めします。

5. テスト管理システムは、誰もがバグ処理に対処するためのプラットフォームであり、個人的な問題を気軽に記録するために子供の靴をテストするためのものではありません。したがって、テストする子供たちの靴に注意を促し、問題がバグであることを明確にしてから請求する必要があり、バグでない場合は言及しないか、コミュニケーション後に拒否する必要があります。

発売予定

  • リリース順序: 通常、バックエンドが最初にリリースされ、次にフロントエンドがリリースされます。
  • 依存関係の準備ができているかどうか: 構成されたデータ、構成項目など。
  • オンライン ビジネスやオンライン データに影響はありますか?
  • ローカル環境、開発環境、ガンマ環境はすべて検証する必要があります。
  • フォールバックメカニズム
  • チェックリストを公開する

オンライン確認

  • リリース完了後、オンライン確認メールを出力する必要があります
  • ページエクスペリエンスとページパフォーマンスを観察する
  • 監視データと営業電話の量を観察する
  • 概要レビュー

2. フロントエンドエンジニアリング

Gitのバージョン管理

1. フロントエンド コード ウェアハウスの git ブランチ仕様:

2. コミット メッセージの形式では、次の 10 個のロゴのみが許可されます。最も一般的なものは、feat と fix です。

  • 特技: 新機能
  • 修正: バグを修正する
  • ドキュメント: ドキュメント
  • style: 形式は変更されますが、コードの動作には影響しません。
  • リファクタリング: リファクタリング (新しい機能でも、バグを修正するためのコード変更でもありません)
  • テスト: テストを増やす
  • 雑務: ビルド プロセスまたは補助ツールの変更
  • up: このカテゴリは上記のカテゴリに属さない場合に使用できます
  • merge: 手書きのコミットメッセージが必要な場合に、ブランチのマージに使用されます。
  • revert: 前のコミットを取り消すために使用されます

3. 事業所、命名規則:(日付を追加することをお勧めします)

  • 機能ブランチ: feature_xxx_YYMMDD
  • 緊急バグ修正ブランチ: hotfix_xxx_YYMMDD
  • アプレット リリース ブランチ (自動生成): release_YYMMDD

コード仕様

  • コードのフォーマット: より美しく
  • コードの書式チェック: ESLint

CSSプリプロセッサ

  • SASS (さらに使用)
  • 少ない
  • PostCSS

パッケージ管理

  • パッケージ管理ツール: npm (最も一般的)、yarn
  • cnpm、nvm、nrm の共通コマンド

コンパイルビルド

  • webpack (最も一般的)
  • 素早く
  • ゴクゴク
  • Babel: ES6 構文を ES5 構文に変換する

小規模プログラムエンジニアリング

テスト関連

  • テストケースコードを書く
  • 単体テスト
  • 自動テスト

3. フロントエンドのコア知識

フロントエンドエントリーのコアナレッジポイント

ブラウザ

  • ウェブ標準: 構造標準 (HTML)、プレゼンテーション標準 (CSS)、動作標準 (JS)
  • ブラウザは 2 つの部分に分かれています: レンダリング エンジン (例: ブラウザ カーネル)、JS エンジン
  • ブラウザの仕組み: 再描画とリフロー、V8 エンジン
  • アプリの WebView コンテナはブラウザに相当し、H5 Web ページを埋め込むことができます

HTML5

  • セマンティック タグ: <header>、、<article> など<footer>
  • 「マルチメディア」タブ: <audio><video>
  • 強力なローカル ストレージ機能とデバイス互換性:indexDB、HTML5 APP Cookie
  • 3D、グラフィックス、特殊効果: SVG、Canvas、WebGL
  • より効率的なリアルタイム接続: WebSocket、サーバー送信イベント
  • アクセシビリティ体験

CSS、CSS3

  • CSS ボックス モデル、BFC
  • フローティング、位置決め(絶対位置決め、相対位置決め)
  • フレックスレイアウト
  • 聖杯レイアウト、両翼レイアウト
  • セレクター: 子孫セレクター、交差セレクター、共用体セレクター、疑似クラス セレクター
  • 2D 変換: モバイル移動、回転回転、ズームスケール
  • 3D変換:パースパースペクティブ、3Dモバイルtranslate3d、3D回転rotate3d、3Dレンダリングtransform-style
  • CSS3アニメーション:アニメーション
  • CSSハック
  • Retina スクリーンで 1px ピクセルを実現する方法

JavaScript の基本

  • ES6 構文: strict モード、アロー関数、Promise、Symbol データ型、Set および Map データ構造

  • ES6~ES5

  • JSデータ型変換、暗黙的型変換

  • 組み込みオブジェクトとそのメソッド

  • 配列のさまざまなメソッド: マップ、フィルター、すべて、リデュースなど。

  • イベント機構、プロトタイプ継承、即時実行機能

  • DOM操作、仮想DOMの差分アルゴリズム

  • BOM ブラウザの操作

  • イベント バブリング メカニズム: キャプチャ フェーズ、ターゲット フェーズ、バブリング フェーズ。

  • 非同期プログラミング: Ajax、Promise、async await

  • セッションストレージとローカルストレージ、Cookie

  • イテレータ イテレータとジェネレータ ジェネレータ

  • ウェブソケット

  • 非同期プログラミング

  • シングルスレッド

  • キャンバスイメージ描画

  • SVGアニメーション

JS アドバンスト

  • JS の 3 つの山: プロトタイプとプロトタイプ チェーン、スコープとクロージャ、非同期とシングルスレッド
  • スコープチェーン、クラス、継承、プロトタイプの継承
  • このポインティングとバインディングのルール
  • 深いコピーと浅いコピー
  • 安定化とスロットリング
  • マクロタスクとミクロタスクを約束する
  • ブラウザのリフローと再ペイント
  • Promise のロジックと API 全体を手書き:solve、reject、then、catch、finally、allSettled、race any
  • 高次関数
  • イベントの代表団
  • 電話をかける、申し込む、バインドする
  • 引数擬似配列
  • 関数のカリー化
  • モジュール性: CommonJS、AMD、CMD、ESModule
  • JS の高レベル文法: イテレータ イテレータ、デコレータ ジェネレータ
  • JS の高レベル構文: Decorator、Proxy/Reflect、MutationObserver、オブジェクト プロパティ記述子、Object.assign、Object.freeze、Object.seal
  • JSメモリリーク、JSガベージコレクションアルゴリズム
  • TypeScript の型チェック
  • Vue.js、React.js のソースコード分析
  • Vue.js および React.js の状態管理: Vuex、Redux、Redux Toolkit、React Hooks、zustand
  • V8エンジンのソースコード

Node.js

  • 折り返し電話
  • 時間駆動のメカニズム
  • モジュラー
  • 関数
  • ルーティング
  • グローバルメソッド
  • ファイルシステム

ウェブセキュリティ

  • クロスドメインの問題、同一オリジンポリシー、JSONP
  • コルス
  • XSS
  • CSRF

ページフォーム

  • 多端末適応型レイアウト

  • SPA シングルページ アプリケーション

  • PWA (Progressive Web App): 小規模プログラムの元祖

4. フロントエンドフレームワーク

各フレームワークとツールには、独自の制約、値、ベスト プラクティスがあります。

JSフレームワーク

  • Vue.js
  • React.js
  • Svelte (軽量フレームワーク、最近比較的人気があります)。
  • 角度付き (段階的に廃止)

比較:

  • Vue: 宣言型プログラミング、データ駆動型思考
  • React: 関数型プログラミング。データを変更したい場合は、API を呼び出して変更する必要があります。

vue では、望むものはほぼすべて与えられますが、react はより自立性を追求します。

CSSフレームワーク、コンポーネントライブラリ(B側で共通に使用)

ナレッジベースフレームワーク

  • Vuepress (Vue.js ベース、推奨)
  • Docusaurus (React.js ベース、推奨)
  • GitBook
  • docsify: 簡単な Wiki ドキュメントを作成します。ケース: Gravedigger の Wiki

補足: ナレッジ ベース フレームワーク。まず、強力で成熟しており安定している Vuepress と Docusaurus をお勧めします。

APIドキュメントフレームワーク

  • TypeDoc: TypeScript プロジェクトから HTML、マークダウン、その他のドキュメントを生成します。
  • storybook : UI コンポーネントを構築するためのナレッジ ベース。UI コンポーネントのスタイルとインタラクティブな効果は、オンラインでプレビューできます。

クロスエンドフレームワーク

  • Flutter (最近人気が高まっています): Flutter の Dart 開発言語。ARM 64、x86、および JavaScript コードにコンパイルできます。

  • ReactNative (徐々に衰退): アプリ、ウェブ

  • タロウ: アプレット、H5

デスクトップアプリケーション開発フレームワーク

  • 電子フレームワーク。事例: VS Code ソフトウェアは Electron で開発されています。

Electron は非常に人気があり、多くの企業で使用されており、VS Code、Facebook Messager、Twitch、Microsoft Teams など、成功を収めているソフトウェアが多数あります。Electron は簡単に始めることができますが、遅い、メモリを消費する、サイズが大きいという問題は明らかです。パッケージ化された Chromium がコンテンツを消費するため、Electron はメモリを消費します。同時に、Hello World はコンパイル後に 1 億 2000 万以上の費用がかかります。

VS Code、Chrome、およびアプレット開発者ツールは、基本的に Chrome カーネルを実行します。したがって、これら 3 つのソフトウェアは多くのメモリを消費し、非常にスタックしていることがわかります。私はこれを「フロントエンド頭痛の三銃士」と呼んでいます。

フロントエンド視覚化フレームワーク、チャート ライブラリ

  • ECharts: Baidu のオープンソース チャート ライブラリ。
  • D3.js: ビジュアル JS ライブラリ。
  • Three.js : ネイティブWebGLパッケージに基づく 3D エンジン  。太陽系ケース #
  • Cocosエンジン: ゲームアニメーション開発フレームワーク。
  • Egret Engine : H5 ゲーム エンジン、H5 ゲーム ソリューションの完全なセット。Egret エンジンを搭載している会社は 2022 年初めに倒産したため、使用はお勧めできません。

エディタフレーム

  • wangEditor: 中国で非常に人気があります
  • TinyMCE:海外でも大人気
  • ueditor: Baidu のオープンソース フレームワーク。古くなり、徐々に衰退していきます。
  • Monaco Editor: VS Code のオンライン バージョン

Node.js フレームワーク

  • Koa: 新世代の Node.js フレームワーク。
  • Egg.js : Egg は、Koa に基づいてさらにカプセル化されたエンタープライズ レベルの Web 開発フレームワークです。
  • Express: 古い Node.js フレームワーク。

サーバーサイドレンダリングフレームワーク

  • Next.js (React.js ベース)

  • Nuxt.js (Vue.js ベース)

フロントエンドテストフレームワーク

  • Mocha : JS テスト フレームワーク。
  • Tiga : クロスエンド (H5、アプレット) プロジェクト用の自動テスト SDK。バンプラボが制作。

5. フロントエンドのパフォーマンスの最適化

パフォーマンス分析ツール

  • コンソールのウォーターフォール チャート ウォーターフォール

  • コンソールのパフォーマンス ツール: 日々の開発プロセス中のランタイム パフォーマンスを観察および分析します。

  • コンソールの LightHouse: ポイントの実行、パフォーマンス レポートの出力、パフォーマンスの分析

  • WebPageTest Web サイト: Web サイトのパフォーマンスを評価する

  • パフォーマンス この API: リアルタイムでパフォーマンスを動的に測定します

パフォーマンスパラメータ

  • 最初の画面時間 = 白画面時間 + レンダリング時間。事前解析、事前ロード、事前レンダリング、遅延ロード、遅延実行。
  • FPSフレームレート
  • パフォーマンスの尺度: RAIL モデル
  • ネットワーク環境が弱く、比較に時間がかかる

ブラウザレンダリングの最適化

  • レンダリング プロセス、クリティカル レンダリング パスを理解する
  • リフローと再塗装を削減
  • ユーザーはURLを入力してからページ読み込み表示が完了するまでどのようなプロセスを経たのか

JavaScriptの最適化

  • JS リソースの最適化: オンデマンド読み込み、コンパイルとパッケージ化、解析と実行、非同期読み込み
  • V8 エンジンの動作原理、パフォーマンス最適化原理
  • 安定化とスロットリング
  • 無限スクロールリスト: ノードのリサイクルを実行します
  • スケルトン画面のスケルトン:レイアウトの動きを軽減
  • タイム スライシング: 長時間実行されるタスクを小さなタスクに分割し、ブロック単位で実行することで、ユーザーのラグ感を軽減します。
  • JSメモリ管理

リソースの最適化

  • リソースの圧縮とマージ: http リクエストの数を減らす、リクエストされたリソースのサイズを減らす、http キャッシュを使用する
  • HTML の最適化: iframe の使用を減らし、ノードの深いネストを回避し、テーブル レイアウトの使用を回避します。
  • CSS の最適化: ページ レンダリングの CSS ブロックを減らし、できるだけ早く CSS をロードします。GPU を使用して CSS アニメーションをレンダリングします。contain 属性を使用してレイアウトと描画時間の消費を削減します。
  • 画像の最適化: 画像の代わりに CSS3、SVG、IconFont を使用します。画像の遅延読み込み、画像のプリロード、プログレッシブ画像、レスポンシブ画像、8kb 未満の画像の代わりに Base64 を使用します。
  • フォントの最適化: フォントのちらつきの問題。特殊なフォントを使用する場合は、Web フォントを動的にロードすることをお勧めします。
  • サードパーティ リソースの非同期読み込み: 制御できないサードパーティ リソースは、ページの読み込みと表示に影響します。

ビルドの最適化

  • ツリーシェイク、コード分割 (コード分割)
  • コードの縮小難読化
  • パッケージ化するときは、変更しないライブラリを繰り返しビルドすることを避けてください。

ネットワーク伝送の最適化

  • Gzip を有効にしてリソースを圧縮する
  • CDN 伝送: すべての静的リソースが CDN 上に配置されるため、ユーザーは必要なコンテンツを近くで入手でき、光ファイバー伝送の距離を大幅に短縮できます。
  • リダイレクトを避ける: 301、302 リダイレクトは応答を遅くします。
  • dns 事前分析: dns-prefetch を使用して事前にドメイン名を解決し、リソースの読み込み速度を向上させます。DNS 事前解決により、画像ベースの Web サイトにアクセスする際の読み込み時間を約 5% 短縮できます。
  • PWA、サービスワーカー
  • SSRサーバーレンダリング/ノードストレート

6. フロントエンドのツールとリソース

フロントエンドのドキュメント

フロントエンドコミュニティ

  • GitHub
  • スタックオーバーフロー
  • ナゲット

JS 学習リソース

JSコード仕様

1、Airbnb JavaScript スタイルガイド:

2、クリーンコードJavaScript:

フロントエンド ブラシに関する質問

CSS 学習リソース

フォント関連のリソース

キャプチャツール

互換性ビューア

画像関連ツール

デザインツール

フローチャートツール

アウトラインノート

  • ムブ:https : //mubu.com

  • フェイシュマインドノート

マークダウンエディタ

  • タイポラ
  • VSコード

コードエディタ

  • VSコード
  • 崇高なテキスト

7. おすすめのフロントエンド本

JS クラシック ブック

  • レッドブック: 「JavaScript 高度なプログラミング」
  • Little Yellow Book: 「あなたの知らない JavaScript」第 1 巻と第 2 巻
  • Rhino Books: JavaScript の決定版ガイド
  • グリーンペーパー: 「JavaScript 言語の本質とプログラミングの実践」

高度な JS

  • 「フロントエンド開発の高度な基礎知識」
  • JavaScript の 20 年間
  • 「JavaScriptの啓蒙」
  • 「最新のJavaScriptを深く理解する」
  • 「JavaScript 忍者攻略」
  • 「保守可能なJavaScriptの書き方」
  • 「驚異の JavaScript エンジニア: フロントエンドからフルエンドまで 上級・上級」
  • 「JavaScript の設計パターンと開発実践」
  • 「WebKit テクノロジー インサイダー」
  • JavaScript の黙示録

CSS

  • 「CSSワールド」
  • 「CSS新世界」
  • 「CSS の謎を解く」
  • 「CSSをマスターする」

Vue.js

  • 「Vue.jsの設計と実装」
  • 「Vue.js徹底解説」

Node.js

  • 「Node.js徹底解説」
  • 「Node.js: 多数の C++ 拡張機能」

データ構造とアルゴリズム

  • 「ソウル・オブ・コンピューティング」
  • 「ビッグトークデータ構造」
  • 「JavaScriptのデータ構造とアルゴリズムを学ぶ」

後部

  • 「ドメイン駆動設計」
  • 「推薦制度実践」
  • 「データ集約型アプリケーション システム設計」
  • 「コード改善への道: コード農家から職人へ」

プロジェクト管理と認識

  • 「神話の男ムーン」
  • 「ハッカーと画家」
  • ジョエル・スポルスキーの著書: 「ソフトウェア・カプリス」、「ジョエルがソフトウェアについて語る」、「ジョエルが語る、優れたソフトウェア開発手法」
  • 「フェニックスプロジェクト」
  • 「継続的デリバリー2.0」
  • 「グーグル ソフトウェア エンジニアリング」
  • ソフト スキル: コードを超えたサバイバル ガイド
  • 「リスタート3 忙しさからの飛び出し」
  • 「プログラマーの思考トレーニング」
  • 「経営者の常識」

製品

  • "啓示"
  • 「網」
  • 「誰もがプロダクトマネージャー」
  • 「ユーザーエクスペリエンス要素」
  • 「有効ニーズ分析」
  • プロダクト ロジックの美しさ: 複雑なプロダクト システムの作成
  • 「WeChatの背後にある製品ビュー」
  • 「ユジュンプロダクトメソドロジー」
  • 「Bエンドでの勝利を決定づける ~プロダクトマネージャー昇格への道~」
  • 「プロダクトマネージャーのためのテクノロジー」
  • 「リーンデータ分析」
  • 『プロダクトマネージャーインタビュー集』
  • 「エクスペリエンス エンジン: ゲーム デザインのパノラマ探索」

デザイン

  • 『デザイン心理学』全4巻
  • 「ユーザーエクスペリエンス要素」
  • 「天市城神」
  • 『みんなのデザインブック』
  • 「Face4について:インタラクションデザインの本質」
  • 「デザイン・イン・デザイン」
  • 「コクーンから来た蝶」
  • 「シンプルさを第一に: インタラクティブ デザインのための 4 つの戦略」
  • 「Web フォーム デザイン: 石を金に変える芸術」
  • 心に響く: 素晴らしい iPhone アプリをデザインする
  • 一瞬の美しさ: Web インターフェイスのデザインがユーザーを動かす仕組み
  • ユーザー エクスペリエンス メトリック: 収集、分析、およびプレゼンテーション

操作する

  • 『オペレーションライト』全2巻
  • 「ユーザーグロースを最前線でやっています」
  • 「グロースハッキング: スタートアップのためのユーザーと収益の成長を攻略する」
  • 「フロープール」
  • 「スーパーオペレーション」

仕事

  • 『スティーブ・ジョブズ伝』
  • 「トップ・オブ・ザ・ウェーブ」
  • "勝つ"
  • 「なぜインターネットで良い仕事ができるのか: 技術的思考からビジネス ロジックまで」
  • 「コンピュテーショナル広告」
  • 「詳細な議論:Zuo Hui」
  • 「オンライン: データはビジネスの本質を変え、コンピューティングは経済の将来を再構築する」
  • 「小売業の哲学」
  • 「電子商取引が見えます」
  • 「サーフボードに乗った会社」
  • 『決算書がわかる本』

思考と認識

  • 「質問することを学ぶ」
  • 「速くも遅くも考える」
  • 「明確な思考の芸術」
  • 「友達として時間を取りましょう」
  • 「知識人」
  • 「人があまり行かない道」
  • 「コミュニケーションの方法」
  • 「なぜ私たちは眠るのか」

8. フロントエンドの概要と認識

研究開発の視点、要件の理解方法

クリックすると大きな画像が表示されます

上記のフローチャートからわかるように、プロダクト マネージャーの成果物は何でしょうか? PRDですか?明らかに違います。

プロダクトマネージャーの仕事は、デザイナーやエンジニアの仕事とは大きく異なります。エンジニアは実用的なコードを提供することが期待され、デザイナーはモックアップを提供することが期待されます。また、プロダクト マネージャーにとっては、prd を提供するだけでは十分ではありません。

プロダクト マネージャーは、発売後のページ効果やデータ パフォーマンスを含む、製品サイクル全体をフォローアップする責任があります。要件仕様を書くことは、プロジェクトを伝達し、前進させる手段ですが、仕様自体には本質的な価値はありません多くのプロダクト マネージャーは、自分のアイデアを伝えるために prd を使用せず、会話を使用し、ホワイトボードにアイデアを描くことができます。仕様を書いたものの、それに従って実装しなかったプロダクトマネージャーもいます。

フロントエンドエンジニアが持つべきスキルや資質とは何でしょうか?

  • 技術基盤、技術ビジョン、技術追求
  • ビジネス機能の開発に加えて、開発仕様、エンジニアリング、コンポーネント化、モジュール化、テスト、デザインパターンについての一定の理解と実践も必要です。
  • コミュニケーションと表現スキル、文章表現スキル、要約レビューの習慣
  • グローバル思考、抽象思考、継続的デリバリー意識
  • チームワークを大切にプロジェクトの第一陣を担当
  • 包括的なトレードオフ: コスト、効率、品質、リスク、経験
  • プロダクト、デザイン、ビジネスなどの分野に注力。学際性がさらなるイノベーションにつながります。

フロントエンドの認知

1. 私たちの時間のほとんどは事業開発に費やされていますが、要約の共有、基本的な能力構築、研究開発効率の向上、技術運営の構築、技術の構築、等

2. 質問することを学びます。日常生活で問題を尋ねて解決するとき、私たちはしばしばXY 問題に陥りがちで、その結果、目標が不明確になり、思考が不明確になり、コミュニケーション効率が低くなり、さらには完全に間違った方向に多くのリソース、時間、エネルギーを浪費することになります。それは助けを求める人にも、助けを与える人にも表れます。

問題に直面したときは、その文の意図、事実、感情、期待を理解します。質問をし、それに答えることを学ぶことは一種の知恵です。質問するという知恵をご覧ください 。

3. プロセス全体をフォローアップし、継続的に提供し、ビジネス価値を創造します。

4. フロントエンドの本質は、ビジネス、設計、およびコンピューティング機能をリンクして、ユーザーにプロフェッショナルな人間とコンピューターの対話エクスペリエンスを提供することです。

5. 製品力・技術力とは、情報を判断し、要点を把握し、限られたリソースを統合し、自らの価値を製品にパッケージ化して納品し、報酬を得る力である。

6. 部門システムには、運用、製品、ビジョン、開発、テスト、アーキテクト、リーダー、マーケティング、データ分析、運用保守など、多くの役割があります。仕事によっては「やるかやらないか」の問題ではなく、程度の問題もあります。境界線を気にすることを前提に、率先して責任を持ち、全体的に考え、共感力を高めることで、能力と責任が徐々に高まっていくことの現れです。

7. 謙虚さ、敬意、信頼は、調整された業務と健全な協力の基礎です。

8. 組織内の人間関係はどうあるべきですか? 経営する側と管理される側の関係だと考える人もいれば、協力関係だと考える人もいます。そして、組織内の関係は献身的な関係だと思います献身的な基盤がなければ、組織的な関係は存在しません。組織には人間同士の相互貢献関係、部門間の相互貢献関係、上司と部下の相互貢献関係があり、そのような献身的な関係の中で組織は真に存在し、その役割を果たします。

献身的な関係によって生み出される基本的な現象は次のとおりです: プロセスに参加している各人は、次のプロセスにどのような貢献ができるかに関心を持っています。各部門は、他の部門と調和のとれたインターフェースを持つためにどのように調整するかに関心を持っています。あなたがどのように協力するかによって上司をサポートすることができ、上司はあなたに問題の解決や部下の支援を依頼するでしょう。

能力も大切ですが、それ以上に努力が大切です。

9. 優秀な人にはいくつかの特徴があります: 敏感、我慢できない、手動で最適化できる。

10. フロントエンドは人間とコンピューターの対話とユーザー エクスペリエンスに重点を置き、バックエンドはビジネス ロジックと大規模なデータ処理に重点を置きます。理論上、ユーザー指向の製品では、すべての問題 (製品、設計、バックエンド、さらには目に見えない問題も含む) がフロントエンドにさらされ、一部の問題 (データの問題、計算の問題、セキュリティの問題など) のみがフロントエンドにさらされます。 .) バックエンドで露出しているということは、フロントエンドが の搬送と接続において重要な役割を果たしているということです。

11. フロントエンド技術の更新は日を追うごとに変化しています。フロントエンドフレームワークの技術選択は終わりのない流れで現れています。視覚的な美しさのトレンドは常に変化しています。視覚化効果は非常にクールです。ユーザーの操作システム徐々に洗練され、水上でも、スマート デバイスのアップグレードと適応は終わりがありません。これらすべてにおいて、フロントエンドのフィールドとフロントエンドの学生には、トスをすること、トスするのが大好き、そして繰り返しトスすることという 1 つの要件があります。

おすすめ

転載: blog.csdn.net/weixin_47367099/article/details/125262681