上位1%エンジニアの7つのシンプルな習慣
(engineercodex.substack.com)- 「エリートコーダーが他のコーダーより優れた能力を発揮する方法」
コーダーではなくエンジニアになること (Be an engineer, not a coder)
- エンジニアリングとは問題を解決すること
- 最高のエンジニアは、コードを目的達成のための手段だと考える
- コードを書く楽しさはあるが、目的のないコードを書くことには意味がない。むしろコードは、ユーザーのためのソリューションを設計するために使われる
- コーディングは創造性を追求するもの。創造性は制約の中でこそ生まれやすい。解決すべき明確な問題という「制約」を加えることで、エンジニアは自分が適切だと思う方法でソリューションを探求し、作り上げる自由を得られる
- 最高のエンジニアたちはプロダクト志向であり、何よりも人のための問題解決を最優先に考えており、これは次の段階につながる
コンピュータではなく人間のためのコード (Code for the human, not the computer)
「コンピュータが理解できるコードなら、どんな愚か者でも書ける。優れたプログラマは人間が理解できるコードを書く。」 - マーティン・ファウラー
- コードはコンピュータだけでなく、人間のためのものでもある
- コードは、そのコードを読み、保守し、あなたのコードの上に構築する同じチームのエンジニアのためのもの
- コードは、携帯電話を使う子ども、APIを呼び出す開発者、そして自分自身など、ユーザーのためのもの
- 最高のエンジニアたちは常に、あらゆるユーザーにとってのコードの価値を評価していた
- もし顧客のうち一人でも満足させられないなら、そのコードは本番に適用されなかった
コードそのものから距離を置くこと (Detach from the code itself)
- 優れたエンジニアはコードそのものに執着しない
- 最終成果物が全体としてより良くなるなら、90%ほど完成したコードであっても削除して最初からやり直すことを恐れない
- コードは個人的なものではないため、フィードバックを積極的に受け入れる
- コードは完璧ではない。誰も完璧なコードには関心がない。変化をもたらすコードに関心があるだけだ
- コードに執着しないよう自分を鍛える最善の方法は、「20年後には、自分のコードの大半が技術的負債になるか、もはや使われなくなるか、書き直されている可能性が高い」と理解すること
一貫した標準を使うこと (Use consistent standards)
- コードを書くときは、一貫した標準とコーディングスタイルを守ること
- 一貫性を保てば、将来の自分もチームメンバーも、コードをより簡単に読んで理解できるようになる
- 一貫したスタイルガイドを使えば、チームもコードベースもより簡単にスケールできる
- これが、MetaやGoogleのような企業が、時間が経ってもコードベースを読めなくなったり保守できなくなったりすることなく、大量のコードを素早くデプロイできる方法だ
- 優れた成果を出す企業はどこも、スタイルガイドを内在化し、その利点を理解し、できる限り従っていた
- Googleは一部のスタイルガイドをオープンソースとして公開している
- Metaは一部のオープンソースでC++スタイルガイドを持っている
- ヒント: チームのためにLinterによるフォーマットを設定するのは、間違いなく時間をかける価値がある
シンプルなコードを書く (Write simple code)
- 私が知るすべてのエリートエンジニアは、作る過程では複雑だったかもしれないが、最終的には読みやすく理解しやすいコードを生み出していた
- これについて私が最もよく使う表現は、彼らのコードが「美的に満足感がある」ということだ
- 彼らのコードは、クリーンで、整理されていて、論理的だった (clean, organized, and logical)
- コード内で下されたそれぞれの決定には意味があり、そうでない場合はコード内にきちんと文書化されていた
- クリーンなコードを書くよい方法は、SOLID原則のような原則に従うこと。もともとはOOP（オブジェクト指向プログラミング）を念頭に設計されたものだが、一般的なプログラミングにも拡張できる
- Single Responsibility: 1つのクラスは1つの責務だけを持つべき
- Open-Closed: ソフトウェアオブジェクト（クラス、モジュールなど）は、拡張には開かれ、修正には閉じているべきであり、それによって予測可能で保守しやすいコードを作れる
- Liskov Substitution: サブタイプは、プログラムの正しさに影響を与えることなく、ベースタイプの代わりとして使えるべき
- Interface Segregation: コードは、すべてを使わない巨大なインターフェースに依存すべきではない。代わりに、パッケージはより小さく特化したインターフェースを含み、インポートできるようにすべき
- Dependency Inversion: 上位レベルのモジュールは下位レベルのモジュールに依存すべきではなく、両者とも抽象に依存することで、より柔軟で疎結合なシステム設計を促進すべき
- その例としてNamingが挙げられる。よい名前にはマジックな値がなく、区別が明確で、説明的な関数名と理解しやすい変数を表している
意外性を許さない (Don’t allow surprises)
- コードは予想外の結果を生み出してはならない。これはコードの原則に従い、適切なテストを書くことで可能になる
- よいコードは予測可能だ
- テストはコードの明確さと予測可能性を強化し、自信を与えてくれる。優れた自動テストによって、チームは見えない部分を壊す心配なくコードを変更できる
- いくつかのテストの種類
- 個別コンポーネントや分離された関数に対する単体テスト
- 複数コンポーネント間の相互作用のための統合テスト
- ユーザー視点からシステム全体の機能を評価するエンドツーエンドテスト
- テストはシンプルであるべき。失敗したテストを読んだとき、何が悪かったのかを簡単に把握できるべき
- 何をテストしないべきかを知ることも重要
- たとえば、エンドツーエンドテストの労力がプログラムの実際の利点より大きいなら、テストは慎重な文書化、モニタリング、適切な人（例: コードオーナー）への通知に置き換えられる
- また、テストはフロントエンドコードにおける特定のCSSセレクタのような、コード内の実装詳細をテストすべきではない。データ属性やスクリーンショットテストだけに頼るようなやり方も同様だ
頻繁にコミュニケーションする (Communicate often)
- 優れたシステムは一人では作られない。優れたエンジニアたちは設計レビューを行い、フィードバックを求め、コードの初期設計を繰り返し改善していた
- 誰の知識にも、他人が埋められる空白がある。新しい視点は、コードをより明確にしたり、以前は思いつかなかった新たなアプローチをもたらしたりするのに役立つことが多い
- 最高のエンジニアたちは、よりよい最終成果物を得るために時間をかけて一緒に作業することを恐れず、コミュニケーションと協業を重視していた
- 文書の簡単なレビューを頼むためにチームメンバーにPingを送ったり、重要なプルリクエストにコードレビュアーを追加したりするだけでもよい
速く…そして遅くコーディングする (Code fast… and slow)
- 私が知る最高のエンジニアたちは、プロジェクトは素早く完了させるが、コーディング自体はゆっくり行う
- 変に聞こえるだろうか?
- 上記のすべての原則と習慣は、コーディングの最初の段階により多くの時間を追加する。しかし、これらの原則と習慣によって、エンジニアはプロジェクトの進捗を一歩ずつ前進させられる
- 標準を使い、適切にテストし、原則を使い、頻繁にコミュニケーションすることに時間を割くことで、長期的にはより多くの時間を節約できる
- インターンやジュニアエンジニアだった頃に私自身が経験したことでもあり、多くのエンジニアも同じだろうが、3歩前進を急ぐあまり障害物にぶつかり、5歩後退することがある
ルールを盲目的に従わないこと (Don’t follow rules blindly)
- 上記の「ルール」や「原則」は単なるガイドラインにすぎない。すべてがガイドラインにきれいに当てはまるわけではない
- ときには、書いているコードが円の中に入らない四角形のようなものかもしれないが、それでも構わない
- その場合は、なぜコードがその特定の方法で書かれているのかを文書化すること
- そうしないと、未来の自分のような誰かが後でそのコードを見て、「うわ、当時の自分は間抜けだったな。なぜこれが私たちの標準に従っていないんだ?」と思うかもしれない
- そして彼らは、以前と同じ結論にたどり着くために、20時間かけて標準に合わせてコードを書き直すことになる
- ソフトウェア開発の現実は、すべてのコードがクリーンだったり、ルールに完璧に従えたりするわけではないということ
- しかし、一貫性があり、クリーンで、理解しやすく、テスト可能で、価値のあるコードは存在しうる
- 最高のエンジニアたちに見られた別のパターン
- 少なくとも1つの分野に深いドメイン知識を持っている。 私が記録してきたすべてのエンジニアは、フロントエンドインフラ、分散システム、クリーンなUIなど、特定分野に集中して専門家になったからこそ、現在その分野のトップに立っている
- 自分自身を頻繁かつ適切にマーケティングする。 これらのエンジニアは目立たない場所に隠れていなかった。チームメンバーと働くすべての人が彼らの価値と専門性を知っており、それは適切な自己発信と、影響力のあるプロジェクトに取り組んだ結果だった
11件のコメント
良いインサイトが得られました。ありがとうございます :)
いい文章ですね！
技術も重要ですが、やはり人の役に立つプロダクトを作ることが大切だということを改めて考えさせられますね!!!
良い文章をありがとうございます！
よく見たら7つの習慣なのに、内容は9個ですね（笑）
私も数えてみましたが……一番後ろと一番前は、ただのタイトルのような気がします！ はは
うわ、本当にほとんど全部共感できる素敵な文章ですね（笑）
これまで見てきたこの手の文章の中でも、歴代級のコンテンツ
少し一般化すれば、すべての人の役に立つ良い文章ですね。
この程度になると要約というより翻訳みたいですが……要約を本当にありがとうございます。
折に触れて読み返す価値のある文章ですね。
本当にそうですね（笑）。私も何度も読み返してみようと思います。