私は最近、ブログの読者から手紙を受け取りました。 読んだ手紙：
こんにちは、フィリップ、あなたがどのように素晴らしいフロントエンド開発者になったのか尋ねてもいいですか？ 何かアドバイスはありますか？
率直に言って、自分が「素晴らしい」フロントエンド開発者だとは思っていなかったので、彼らが同じような質問をしてくれたことに驚いた。 実際、私はこの分野で働き始めたばかりのときに引き受けたすべてのことに対して十分な資格があるかどうかはわかりません。 仕事に応募したのは、自分がどれだけ知らないかわからなかったからですが、 面接した人たちがどんな質問をすればよいかわからなかったからです。
しかし、結局、私はそれぞれの役割に対処し、チームの貴重なメンバーになりました。 （私も準備ができていなかった新しい挑戦のために）去ろうとしていたとき、私は通常、代替品を拾うように頼まれました。 それらのインタビューを振り返り、思い出すと、私は知識にどれほどの重要性を抱いていたかを驚かされます。 理論的には成功する可能性があることは今ではわかっていますが、現在は過去を自分で雇ったことはないでしょう。
ウェブ分野で長く働くほど、優れたスペシャリストと非常に優れたスペシャリストの主な違いは知識の量ではなく、彼らの考え方にあることを理解しています。 もちろん、知識は非常に重要な場合もありますが、急速に変化する環境では、新しい知識を獲得する能力は常に（少なくとも長期的には）すでに所有している知識を上回ります。 しかし、最も重要なことは、この知識をどのように使用して日常の問題を解決するかです。
仕事を成し遂げるために必要な言語、フレームワーク、ツールについて語る多くの記事があります。 私は別のアプローチを取りたかった。 この記事では、フロントエンド開発者の考え方についてお話しします。「優れた開発者になるにはどうすればよいですか？」という質問に対して最も包括的かつ詳細な回答ができることを願っています。
問題を解決するだけでなく、コードで実際に何が起こっているのかを理解してください
CSSとJavaScriptを扱う人の多くは、この「何か」が機能するまで何かをしてから先に進みます。 私は誰かのコードを見るといつも同じような写真を観察します。
私はよく「なぜfloat：leftを追加しましたか？」または「overflow：hiddenは本当に必要ですか？」と尋ねます。これに応えて、「わかりませんが、削除しても機能しません」というフレーズがあります。
JavaScriptと同じ話。 競合状態を防ぐためにsetTimeoutがどのように使用されるか、またはこのアクションが他のページイベントハンドラーに影響を及ぼすことを心配せずに誰かがイベントの拡散を停止する方法を確認します。
私は、あなたが仕事をするために何かを必要とする状況がすぐにあることを理解しています。 しかし、あなたが問題を理解しようとして時間を無駄にしないなら、同じ熊手を続けてください。
問題の解決策が機能した理由を理解しようとするのは時間の無駄であると考えることができますが、将来の時間の節約に役立つことをお約束します。 使用しているシステムを完全に理解していれば、問題を解決する際に推測することはできませんが、なぜそうする必要があるのかを理解できます。
将来の技術の変化を予測することを学ぶ
フロントエンドコードとバックエンドコードの主な違いの1つは、バックエンドコードがほとんどの場合、管理下の環境で実行されることです。 それどころか、フロントエンドは制御できません。 ユーザーのプラットフォームまたはデバイスはいつでも完全に変更できるため、コードは簡単に対応できるはずです。
2011年に、私は何らかの理由で人気のあるJavaScriptフレームワークのソースコードを読んで、そこに次の行を見ました（少し簡略化しました）：var isIE6 =！IsIE7 &&！IsIE8 &&！IsIE9;
この場合、コードは6番目より古いIEのすべてのバージョンを処理しましたが、IE10がリリースされるとすぐに、アプリケーションの重要な部分が完全に機能しなくなりました。
現実の世界では、機能検出は100％の保証を与えるものではないことを理解しています。また、ブラウザーの誤った動作を考慮に入れ、機能検出が誤って正（または負）の値を返すものを考慮しなければならない場合があることを理解しています。 ただし、これを行う場合、これらのバグが発生しない将来を保証する必要があります。
今日私たちが書いたコードは、現在の仕事を辞めた後でも、長い間存在します。 私が8年以上前に書いたコードの一部は、今でも大規模なサイトで機能しています-この考えは同時に誇りと懸念を生じさせます。
仕様を読む
ブラウザーにはバグがありましたが、そうでしたが、2つのブラウザーが同じコードを異なる方法で処理する場合、人々はいわゆる「良いブラウザー」が正しく、「悪い」ブラウザーが間違っていることを確認せずに想定することがよくあります。 しかし、これは常にそうであるとは限りません。そのような仮定が誤っていることが判明した場合、あなたが加えた変更はほぼ確実に将来崩壊するでしょう。
この話題の例は、フレックスアイテムの標準サイズです。 仕様に基づいて、フレックスアイテムの初期の最小幅と最小高さの値はauto（ゼロではありません）です。つまり、デフォルトでは、コンテンツの最小サイズより小さくならないはずです。 過去8か月間、FireFoxはこれが正しく実装された唯一のブラウザです[1]。
このようなブラウザ間の非互換性が発生し、Chrome、IE、Opera、Safariでサイトが同じように見えるが、FireFoxで異なる場合は、FireFoxが間違っていると思われます。 実際、私はこれに何度も出くわしました。 Flexbugsプロジェクトにはこのような非互換性の問題があるとよく言われましたが、なんとかこれを回避していくつかのソリューションを実装しようとすると、Chrome 44のリリースで2週間前にすべてが崩壊していました。ブラウザの正しい動作を（実際に）補償しようとした人の数[2]。
2つのブラウザーが同じコードを異なる方法で表示する場合、コードを編集するには、時間をかけてどちらが正しく機能するかを理解する必要があります。 その後、将来は何もやり直す必要はありません。
いわゆる「優秀な」フロントエンド開発者は、最先端の人々であり、新しいテクノロジーが普及する前に適応し、開発に貢献することさえあると付け加えます。 仕様を調べて、すべてのブラウザーに表示される前にテクノロジーがどのように機能するかを想像する習慣を身に付けると、選択したグループの一部となり、仕様の開発を理解し、影響を与えることができます。
他の人が書いたコードを読む
他の人のコードを楽しみながら読むことは、おそらく土曜日の夜にやりたいことではありませんが、間違いなく、開発者のスキルを向上させる最良の方法の1つです。
自分で問題を解決することは学習するのに最適な方法ですが、それがすべてであれば、すぐに限界に達するでしょう。 他の人のコードを読むことで、問題を解決する新しい方法に心を開くことができます。 チームで作業している場合、またはオープンソースプロジェクトに参加している場合は、作成しなかったコードを読んで理解する能力は非常に重要です。
企業が新しいエンジニアを採用するときに犯す最大の間違いの1つは、新しいコードを最初から作成するように依頼することだと考えています。 既存のコードを評価し、エラーを見つけて修正するように依頼されたインタビューに行ったことはありません。 ほとんどの場合、エンジニアが既存のベースを補完または変更するためにかかるため、これは非常に悪いことです。 ゼロから何かを作成することはほとんどありません。
あなたより賢い人と仕事をする
私は、フリーランスの仕事（常に独立して仕事をする）を望んでいるバックエンドの開発者よりも多くのフロントエンドの開発者がいるという印象を受けました。 おそらくこれは、フロントエンドの開発者が自分で学ぶことが多く、2番目のカテゴリは大学でほとんどの知識を得るためです。
ここでの問題は、独学で自分自身で働くことで、あなたよりも賢い人と仕事をすることから利益や経験を得られないことです。 アイデアやコードについて話し合う相手はいません。 少なくとも私のキャリアの初期段階では、人々があなたよりも賢く経験豊富なチームで働くことをお勧めします。
ある時点で自分で作業を開始する場合は、オープンソースプロジェクトの一部になります（または残ります）。 そのようなことに積極的に参加することで、チームワークと同じ利点が得られます。
車輪を再発明する
自転車を発明することはビジネスには良くありませんが、トレーニングには適しています。 サンプルウィジェットまたはイベント委任ライブラリをnpmから取得したいと思うかもしれませんが、これらのことを自分で書き込もうとするとどれだけ学習できるか想像してみてください。
この記事の読者の中には、これから異議を唱える人がいるかもしれません。 しかし、誤解しないでください。 既製のコードを使用しないでくださいと言っているわけではありません。 バグが修正され、数年のテストで利点が確認されている、優れた実績のあるライブラリを使用することは、ほとんどの場合非常に優れたソリューションです。
しかし、この記事では、優れた開発者から優れた開発者に変える方法について説明しています。 私が素晴らしいと考えるこの業界の人々のほとんどは、私が絶えず使用している非常に人気のあるライブラリーのサポートを作成または支援してくれました。
もちろん、独自のJavaScriptライブラリーを作成しなくても成功したキャリアを作ることはできますが、自分が何をしているかを完全に理解する機会はありません。
多くの場合、この業界の人々は同じ質問をします。「次に何をすればいいですか？」新しいツールを学習したり、新しいアプリケーションを作成したりする代わりにこの質問をしている場合は、お気に入りのJavaScriptの1つを再作成してみてくださいライブラリまたはCSSフレームワークの1つ？
学んだことについて書く
そして最後に、あなたが学んだことについて書いてください。 これを行うべき理由は数多くありますが、最も重要なことは、問題をよりよく理解できることです。 何かがどのように機能するかを説明できない場合、あなた自身がそれについてよくない考えを持っている可能性があります。 紙で言葉を表現しようとするまで、完全に理解していないことすら知らないことがよくあります。
私自身の経験から言えば、記事を書いたり、コミュニケーションを図ったり、モデルを作成したりすることは、問題を思い切って完全に理解させるための最良の方法です。 あなたが書いたものを誰も読まなくても、そうであれ-プロセス自体は重要です。
注：FireFoxは、2014年12月1日のバージョン34で仕様の変更を導入しました。 Chromeは2015年7月21日のバージョン44でこれを実行しました。つまり、Operaも近日中にこれに到達する予定です。 Edgeは2015年7月29日にリリースされ、仕様に従って動作します。 Safariでの作業が進行中のようです。 Flexbug＃1は、この問題を解決するための優れたクロスブラウザーパッチと考えることができます。
開発と設計に関する当社の出版物：