先日、私は上級職に応募している JavaScript 開発者にインタビューしました。 同じく面接に同席していた同僚は、HTTP リクエストを作成し、失敗した場合は数回再試行する関数を作成するように候補者に依頼しました。
彼はボード上に直接コードを書いたので、おおよそのものを描くだけで十分です。 もし彼が単に事の本質をよく理解していることを示していたら、私たちはとても満足しただろう。 しかし、残念なことに、彼は成功する解決策を見つけることができませんでした。 それから私たちは興奮したので、タスクをもう少し簡単にすることに決め、コールバックを含む関数を Promise に基づいて構築された関数に変えるように彼に依頼しました。
しかし悲しいかな。 はい、彼が以前にもそのようなコードに遭遇したことがあるのは明らかでした。 彼はそこですべてがどのように機能するかを大まかに知っていました。 必要なのは、概念の理解を示すソリューションのスケッチだけです。 しかし、候補者がボードに書いたコードは全くのデタラメでした。 彼は JavaScript の Promise について非常に漠然とした考えを持っていましたが、なぜ Promise が必要なのかを実際には説明できませんでした。 後輩なら許されることだろうが、もはや先輩という立場にはふさわしくない。 この開発者は、どのようにして複雑な約束の連鎖のバグを修正し、自分が何をしたのかを他の人に説明できるでしょうか?
開発者は既成のコードを自明のことと考える
開発プロセスでは、常に再現可能な素材に遭遇します。 コードの断片を転送することで、毎回コードを書き直す必要がなくなります。 したがって、重要な部分にすべての注意を集中することで、作業する完成したコードを自明のものとして見ることができます。つまり、すべてが正常に動作すると単純に想定しているだけです。
そして、通常はうまくいきますが、物事が難しい場合には、仕組みを理解することが十分に役に立ちます。
したがって、上級開発者のポジションの候補者は、約束オブジェクトは自明であると考えました。 おそらく彼は、他の人のコードのどこかでそれらが発生した場合にそれらに対処する方法についてのアイデアを持っていたと思われますが、一般原則を理解しておらず、インタビュー中に自分自身でそれを繰り返すことができませんでした。 おそらく彼はその断片を暗記したのでしょう - それはそれほど難しいことではありません。
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});私もやったことがあるし、おそらく誰もが一度はやったことがあるはずだ。 彼らは、後で仕事で使用できるようにコードの一部を暗記しただけで、そこですべてがどのように機能するかについての一般的なアイデアしか持っていませんでした。 しかし、開発者がその概念を本当に理解していれば、何も覚える必要はありません。ただその方法を知っているだけで、必要なものすべてをコードで簡単に再現できます。
原点に立ち返って
フロントエンド フレームワークの優位性がまだ確立されていなかった 2012 年、jQuery が世界を支配していたとき、私は次の本を読みました。 、jQueryの作成者であるJohn Resigによって作成されました。
この本は読者に独自の jQuery をゼロから作成する方法を教え、ライブラリの作成に至った思考プロセスについてのユニークな洞察を提供します。 近年、jQuery はかつての人気を失っていますが、それでもこの本を強くお勧めします。 彼女について私が最も衝撃を受けたのは、これらすべてを自分で考えることができたかもしれないという持続的な感情でした。 著者が説明した手順は非常に論理的で、非常に明確に思えたので、根気よく取り組めば簡単に jQuery を作成できるのではないかと真剣に思い始めました。
もちろん、実際にはそんなことはできなかっただろうし、耐えられないほど難しいと判断しただろう。 私自身の解決策は単純すぎて単純すぎてうまくいかないように思え、諦めてしまいます。 私は jQuery を自明のものとして分類し、その正しい動作については盲目的に信じる必要があります。 その後、私はこのライブラリの仕組みを詳しく調べることに時間を無駄にすることはほとんどなくなり、単にこれを一種のブラック ボックスとして使用するようになりました。
しかし、この本を読んで私は別人になりました。 私はソース コードを読み始め、多くのソリューションの実装が実際には非常に透過的で、明白ですらあることを発見しました。 いや、もちろん、このようなことを自分で考えるとなると話は別です。 しかし、他の人のコードを研究し、既存のソリューションを再現することで、独自のコードを考え出すことができます。
得られるインスピレーションと気づき始めるパターンは、開発者としてのあなたを変えるでしょう。 あなたが常に使用し、魔法の成果物として考えることに慣れているその素晴らしいライブラリは、魔法にはまったく機能せず、単に簡潔かつ機知に富んで問題を解決するだけであることがわかります。
場合によっては、コードをじっくり読み込んで段階的に分析する必要がありますが、こうすることで、一貫した小さなステップで、解決策に至るまでの作成者の道を繰り返すことができます。 これにより、コーディング プロセスをより深く掘り下げることができ、自信を持って独自のソリューションを考え出すことができます。
初めて約束に取り組み始めたとき、それは純粋な魔法のように思えました。 その後、それらが同じコールバックに基づいていることがわかり、私のプログラミングの世界はひっくり返りました。 では、コールバックから身を守ることを目的としたパターン自体がコールバックを使用して実装されているということでしょうか?!
これにより、この問題を別の目で見ることができ、これが目の前にある難解なコードではなく、私が一生かけても決して理解できない法外な複雑さではないことがわかりました。 これらは、十分な好奇心と深い没頭があれば問題なく理解できるパターンにすぎません。 これが人々がコーディングを学び、開発者として成長する方法です。
この車輪を再発明する
独自のデータ バインディング コードを作成したり、独自の Promise を作成したり、独自の状態管理ソリューションを作成したりすることもできます。
これらすべてを誰も使用しないことは問題ではありませんが、これでその方法がわかりました。 そして、その後そのような開発を自分のプロジェクトで使用する機会があれば、それは一般的に素晴らしいことです。 あなたはそれらを発展させ、何か他のことを学ぶことができるでしょう。
ここでのポイントは、コードを運用環境に送信することではなく、何か新しいことを学ぶことです。 既存のソリューションの独自の実装を作成することは、最高のプログラマーから学び、スキルを磨くための優れた方法です。
出所： habr.com