ピットフロントエンドに入ってから2年半近く経ちますが、この2日間、最初の面接でいきなり面接官からの質問を思いつきましたが、フロントエンドの働きをどう理解していますか？
当時の初心者の私にとっては、まったくナンセンスで、言葉が意味を表していないので、インタビュアーは混乱しているように見えました。考えてみると、ぎこちないチャットと呼ばれるかもしれません... 2年間の絶え間ないクロールの後この質問について私は新しい理解を持って、午前中に何も利用せずにこのブログを書き、そこで書くことを考え、理解したとおりにフロントエンドについて話しました。
技術的側面：
フェーズ1（初心者の村）
フロントエンドの初心者は、HTML、CSS、JavaScriptのコアスキルを習得する必要があります。これら3つは、フロントエンドの最下位のテクニカルサポートです。数年前の回答を見ると、別のjqueryがあるはずですが、私は個人的にこの段階だと思います。フロントエンドのサークルjqueryは必要なスキルとして使用できません。Jqueryは初心者にはとてもフレンドリーですが、現在mvvmフレームワークは世界中で飛んでいます。Vue、Angular、Reactは3つです。世界の一部。domを直接操作するjqueryよりもはるかに使いやすいです。もちろん、この段階では基盤です。ステージフレームワークやクラスライブラリなどを前に進めることができます。ネイティブJは常に最優先事項です。フレームワークを使用して基本的な原則を理解せず、習熟することはありません。RedBookJavascriptの高度なプログラミングを推奨し、Red Bookを学び、他のフレームワークを学ぶ前に強固な基盤を築いてください。あなたの研究について心配しないでください。次に、追加のスキルPhotoShopがあります。PSはそれを行わなくても実行できることを知っておく必要がありますが、それを知っている必要があります。一部の小規模企業では、UIはPSDのみを提供します。Sketchのようなものはありません。写真をカットする場合は、自分で処理する必要があるため、psは追加の必要なスキルです。
第2ステージ（ダンジョンオープン）
明確な成長段階に入り、モンスターとの戦いとアップグレードを開始します。この段階は最も長く続きます。この期間中に、無数のピットを登り、さまざまな失敗の経験を蓄積し、1つのレベルをスキャンする必要があります。HTMLとCSSに関しては、知っている必要があります。 BootStrap、ElementUI ...などのさまざまなUIフレームワークの使用、さまざまな画像のフォーマット標準、ブラウザーの互換性、モバイルとPCの違い、レスポンシブレイアウト、フレックスレイアウト、グリッドレイアウト、デザインの美観の向上などページ開発の効率を向上させるためのさまざまなスキルについては、UIフレームワークは、関心のあるもののさまざまな選択になります。
Js側では、学習用の主流のフレームワークを選択し始めることができます。前述のVue、Angular、およびReactはすべて適切な選択であり、オブジェクト指向プログラミング、オブジェクトカプセル化、プロトタイプ継承、クロージャー、同期および非同期の違いについては、A一連の高度なjs知識を深く理解する必要があると同時に、es6標準を理解する必要があります。RuanYifeng先生によるes6の紹介を参照できます。この本には、es6のさまざまな新機能、デフォルトパラメータ、テンプレート式、文字列、解凍式、改善されたオブジェクト式、矢印関数=＆>、Promise、letおよびconstのブロックレベルのスコープ、クラスクラス、モジュール化、およびその他の一般的な機能。コンポーネントを自分でカプセル化し、保守性を高く書くことができます。読みやすいコードそして通常は、他の人が書いたコードを読み、他の人の利点から学び、多くの技術文献を読む必要があります。最も重要なことは、自分の問題を要約することです。たとえば、遭遇した場合バグ、混乱している場合は解決できます。次に同じ問題が発生したときに、この時点で以前の問題の要約があるかどうかを確認できます。
ステージ3以上
さまざまなデザインパターンを理解し、さまざまなフレームワークのソースコードを理解し、フロントエンドとバックエンドを取得して、自分でjsフレームワークを作成できます...まあ、この段階までは作成しません......。
ワーキング
完全なワークフローは次のようになります。
プロジェクトの確立-プロジェクトの議論-需要の確認-製品のプロトタイプ-設計者がUI設計のプロトタイプを取得する際のバックグラウンド開発-フロントエンド開発-テストバグ-変更バグ-n回繰り返す-製品の受け入れ
上記は一般的なプロセスのセットです。少なくともフロントエンドでは、ビジネスロジックを整理し、ビジネスロジックを理解する必要があります。これは、将来の開発に非常に役立ちます。同時に、アプリケーションを選択できます。テクノロジーを活用し、ニーズに応じてプロジェクト構造を分割します。デマンドモジュールの分割と完全なプロジェクトの構築。もちろん、多くの自動化された構築ツールがあり、多くの時間を節約できます。今日のフロントエンド開発はもはやありません。静的なWebページの開発だけです。絶えず変化するフロントエンドテクノロジーにより、フロントエンドコードのロジックが作成され、インタラクティブ効果の管理がますます複雑になり、管理が困難になっています。モジュール式の開発および前処理フレームワークにより、いくつかの小さなモジュールにプロジェクトを作成すると、最終リリースの難しさが増します。統一された標準がないと、フロントエンドのプロジェクト構造は奇妙になります。プロジェクト開発全体でフロントエンドの自動化の構築がますます重要になっていますが、初心者はそれでも少しずつプロジェクトを自分で構築しようとする必要があります。さらにいくつかのプロジェクトを行うと、毎回この方法を繰り返すのは面倒です。結局のところ、これにより、自動ビルドを使用する理由をより深く理解できます...たとえば、メインスタックはvueであり、最も一般的に使用されるのはvue-cliです。次のような自動化ツールには多くのオプションがあります。 Bower、Gulp、Grunt、Node、yeomanとして、ニーズに応じて学習するのに最も適したものを選択する必要があります。
コミュニケーション
フロントエンドは、チーム内で最もコミュニケーションを学ぶ必要がある人です。インターフェースに問題がある場合は、UIと通信する必要があります。データに問題がある場合は、バックエンドと通信する必要があります。 。機能に問題がある場合は、製品と通信する必要があります。バグをテストする場合は、テストと通信する必要があります... emmmtired
沟通ui
フロントエンドはユーザーに最も近い人です。ウェブサイトやソフトウェアに対するユーザーの最も直感的な感情はフロントエンドに反映されます。おそらく最も直感的なのはUIデザイナーではないはずです。あなたはそれを知っている必要があります。私はフロントエンドであり、デザイナーのために話します。
UIとのコミュニケーションでは、UIデザインを受動的に実装するのではなく、独自のアイデアを合理化する必要があります。そうしないと、将来のやり直しによって、プロジェクトで最初に会社に来たときなど、双方の時間が無駄になります。スプライト画像はまだいくつかの小さなアイコンの写真に使用されていますが、ブラウザーのサポートがますます良くなっていることから、svgアイコンとfontアイコンが徐々に主流になっていることは明らかです。私はAlibabaアイコンライブラリにUIをプルするプロジェクトを構築しました。入って、UIは彼がプロジェクトに使用したアイコンを直接追加し、フロントエンドはプロジェクトからフォントアイコンを直接生成してプロジェクトにインポートします。画像をゆっくりと切り取り、アイコンを差し引き、マージすることが絶対に必要です。スプライト画像。はるかに簡単で使いやすいです。本当にかっこいいです。必要に応じて色を変更してください。別の例として、チャートを作成してechartsを使用する必要がある場合、デザイナーの心にどれだけの創造性がインストールされているかわからないため、そこで自由にプレイさせるのではなく、echartsに基づいてUIデザインスタイルを完全に任せることができます。セーブ二人の時間です。彼が良いスタイルを作っていることに恥ずかしさはなく、あなたはそれを達成することができません。
コミュニケーション製品
一般的に言って、プログラマーとプロダクトマネージャーの間でコミュニケーションをとるのは最も難しいです。殺害だけがあり、愛はありません。結局のところ、Ziはかつてこう言いました。「この要求は非常に単純です。
以下にLensuntopの記事を引用しますが、非常によく書かれていると思います
段落があることを忘れないでください：
Product Wang：プログラマー、緊急のニーズを実装しますか？
プログラマー：話してください。
Product Wang：電話ケースの色に合わせてAPP起動の色を認識してください。
プログラマーは風にめちゃくちゃになりました。。。
この段落から、製品とテクノロジーの間のさまざまな情熱の「火花」を反映することができます。プロダクトマネージャーの目から見た単純な要件は、私たちの見解では不可能です。そしてプログラマーは、製品マネージャーがなぜそのような要求を達成したいのか理解できません。では、プログラマーの観点から、プロダクトマネージャーとどのようにコミュニケーションをとるべきでしょうか。
1.ニーズを深く理解し、ニーズの動機と理由を明確にする
私たちのプログラマーは、製品マネージャーが電話ケースの色に応じて起動時にAPPの色を動的に実現したい理由を尋ねている必要があります。あなたは分析を聞きたいので、あなた自身の結論を急いで言わないでください-それは技術的に不可能です！疑問があるので、まず自分の疑問を解決してください。
2.共感
製品には製品の視点があります。私たちはプログラマーとして何を追求しますか？ロジックは正しく、高速で、拡張が簡単です。製品は何を追求していますか？正直なところ、私自身はこの問題について深く考えていません。慣性の観点から考えると、製品が存在する理由、その存在が解決できる問題、ユーザーエクスペリエンスが優れているかどうかなどが考えられます。これらは、製品を決定するコアバリューです。結局のところ、仕事の性質は人の思考論理に影響を与えるので、現時点では、製品の観点からあらゆるニーズを考えることが特に重要です。
3.すべての詳細をお見逃しなく
プログラマーとして、私はこの文に深く同意しなければなりません。句読点やタイプエラーが原因で、予期しないバグが発生します。製品を設計する際、プロダクトマネージャーは常に一般的な方向から問題を考えます。一般的な方向は間違っておらず、詳細を一般的な方向から切り離すことはできません。これが彼らの考えです。しかし、プログラムにとって、それは絶対に不可能です。詳細なロジックが全体的な方向を決定することが多いためです。例：需要があり、ユーザーの作品をレビューのために提出する必要があります。そうすれば、誰でも見ることができます。プロダクトマネージャーからこの要求があったとき、問題を検出できますか？ここにはいくつかの詳細があります：1。ユーザーがレビューのために送信した後、ユーザーは作品を編集できなくなります; 2。作品が複数回レビューされるかどうか; 3。レビュー履歴を記録する必要があります; 4。ユーザーの作品かどうかバージョン管理が必要です。バージョンを生成する場合、バージョンはどのようにして作成されましたか。5。レビューに合格した後、ユーザーは作業を再度変更できます。そうでない場合、ユーザーの作業は他の人には見えません...ただ単純な論理要件！しかし、関係する詳細が多すぎます。与えられた要件が曖昧すぎて十分に詳細でないため、コーディング時に書き留めることができないことがよくあります。
4.別の方法で「達成できない」と言う
それは実現できません、私たちはこの文を頻繁に言わなければなりません。しかし、プロダクトマネージャーと直接話すと、プロダクトマネージャーを夢中にさせる可能性があります。なぜなら、彼らが提起したいかなる要求も私たちには実現できないと彼らに感じさせるからです。しかし、時間が足りないなど、実現できないことが条件であるため、そうではありません。したがって、まず製品管理者の視点（「達成可能」）に同意し、次に製品管理者のニーズを達成するための条件を提案する必要があります。現実には、プロダクトマネージャーは愚かではなく、不合理な要件を提示することがよくありますが、要件に直面して、達成するまでの時間を評価する必要があります。この時間は、正確に評価するのはそれほど簡単ではありません。
5.不当なニーズに直面した場合は、積極的に代替案を探します
段落のニーズを考慮して、ユーザーが選択できるいくつかのAPPスキンを提供しましょう。これは、元のニーズよりも確実に実現が簡単で、より人道的です。別の話をすると、キッチンの蛇口を実装したいスマートホーム会社があります。人間の声によると、水温は数度に達する可能性があります。別の角度から考えてみてください。40度と45度の温度差を感じますか？そして、人間の声の判断に基づいて、これには音声認識システムが含まれます。互換性のある言語はいくつありますか？実際、左右の切り替えは非常にスマートだと思います。それほど複雑にする必要はありません。したがって、プログラマーは、より適切で簡単な実装方法を見つける必要があります。プロダクトマネージャーに単なる仮定を与えないでください。
6.文書の精神に従わなければなりません
開発時には、プロダクトマネージャーと詳細な話し合いをすることがよくあります。ただし、このディスカッションの結果は、製品のプロトタイプまたは要件リストには記録されませんでした。しかし、数か月後、私たち自身が、そもそもなぜそのような詳細について話し合ったのかを忘れがちです。したがって、すべてのニーズに基づいている必要があります。一方で、それは双方の利益も保護します。何かがうまくいかないまで待たず、誰が責任を負っているのかわからないでください。この点で、プログラマーはしばしば多くの苦しみを味わいます。
6.あなた自身の手順のための芸術的な心を持っている
要件がコードのスケーラビリティに影響を与える場合、コードではなく要件が最初に削減されると誰かが言ったことがあります。ある程度、私はこの文に同意します。私の意見では、プログラムはイデオロギー的な作品であり、芸術の領域に到達するには、機能、経験、論理の点で合理的でなければなりません。まるで芸術作品のように、自然に見えます！「醜い」ように見える作品は、人間の論理や習慣に適合してはならないからです。
執筆の終わりに、私はプログラマー自身に戻ったと感じています。実際、プロダクトマネージャーとコミュニケーションをとるとき、最も重要なことは理解することです。私たちは問題を作成するのではなく、問題を解決することです。主にこのコアを保持し、すべての問題を簡単に解決できます
一般的に言えば、バックグラウンドとの通信にそれほど問題はありません。ルールに同意した後、一般的に言えば、APIを介して通信しますが、インターフェイスをデバッグすると、不明な点がいくつかあり、そうではないと感じます。あなた自身の問題をタイムリーに。舞台裏でのコミュニケーションが最も賢明です。
責任の分割
フロントエンドが最後のレベルであり、すべてのニーズがフロントエンドの手で特定の製品に変換されるため、誰もがこの点に深く触れていると思います。これにより、簡単にバックポットになり、リードすることができます。プロジェクトへ延期されるケースが多く、設計図がタイムリーでなく、背景データに問題があり、一時的に製品を変更する必要があります。これらの問題がプロジェクトの延期の原因であることが証明できない場合は、間違いなくこのポットを覚えているでしょう。唯一の方法は-口頭での確認--à確認のために担当者にメールを送信する--à上司に通知する、これは面倒だとは思わない、何かがうまくいかないときは、より面倒になるこの、
書き込めません。上記はピット登り後のフロントエンドの理解ですが（ps：まだピットにいますが）、仕事のまとめと見なすこともできます。 。気に入らない場合は、スプレーしないでください。最後に、2018年のプロモーションと給料が上がることを願っています。ガールフレンドを見つけてください！
コードをスキャンして、フロントエンドの面接の質問を表示します