最悪のプログラマーの感想

これは元の記事 The Worst Kind of Programmer を読んだ後の感想です。

この記事の著者は明らかに似たような経験を持っているため、この記事では彼の偏見を感じることが難しくありません。しかし、多くの点で議論や学びがあると思い、ここに記録しておきます。

記事の中で、過去のプロジェクトにおいて Frontend Lead がいて、彼はプロジェクトのアーキテクチャを熱心に設定し、Angular、Nx、Rx を選択しました。バックエンドの技術リーダーは Spring Boot フレームワークの下で様々なライブラリを追加しました。とにかく、とてもクールで流行の技術を使っていました。

プロジェクトの要求が増えるにつれて、この前端 Lead はアーキテクチャを調整し続け、ビジネスロジックと技術の核を分離しようと試み、Junior には API ドキュメントの作成やテストの記述など、比較的簡単な要求をさせました。

後になってこの Frontend Lead が退職すると、チームは複雑すぎるコードのメンテナンスができなくなり、専門家を呼んで火を消し、開発の生産性を維持しようとしました。しかし、アーキテクチャの複雑さはチームの生産性に影響を与え続けました。リファクタリングや書き直しのコストは非常に高かったです。

問題はどこにあるのか？

私が見る限り、これは経験の浅いエンジニアが行う行動のように思えます。（自分の過去を思い出して反省します🙏）

先に述べた例で、この Frontend Lead は真剣で、おそらく彼の履歴書にもう一つの輝かしい記録を加えることができたかもしれませんが、実際にはチームの開発速度を落としてしまいました。

だから私は常に過剰設計は万悪の根源であると強く信じています。新しいフレームワークを使ってはいけないと言っているわけではありませんが、いくつかの記事を読んだだけで新しいフレームワークやライブラリを安易に導入するのは、最初は大したことないと思ってもプロジェクトに大きな影響を与えるものです。

優れたエンジニアリングプロセスは常にシンプルで適切な解決策を求めるべきです。私が好きな例の一つは、ピアノのハンマーアクションの変化で、Mark Rober のこのビデオでの説明がとてもわかりやすいです。

なぜピアノのハンマーアクションはあんなに複雑に見えるのか？なぜ単に何かを弦に叩きつけるだけではダメなのか？鍵盤を押したまま音を続け、離すと停止するにはどうすればよいのか？

これらはすべて、単純な問題から始めて一歩ずつ進化して現在の形になったもので、最初から答えを見つけ出せるわけではありません。なぜそうなったのかを理解すると、全体のメカニズムがちょうど良い設計であることに感嘆します。同じ理由で、ソフトウェア開発も最初からいろいろなフレームワークを導入するのではなく、現在の問題に対して一歩ずつ最適な解を見つけ出すべきです。

記事の後半で私があまり同意しない部分もありますが、問題解決能力、長時間労働、ソフトウェア開発への情熱などは非常に良い特性だと思います。もちろん、長時間労働は人生の段階によって変化しますし、他のことに焦点を当てたいと思うこともあります。

もう一つ、よく見落とされる指標は**コードが「容易に変更・削除できるか」**です。

関連するコードの部分をいじるとき、特定の部分を削除しても連鎖反応を引き起こさない自信があるか、または設計時に実装を簡単に置き換えることができるか、さらに他の人もコードを変更したいと思ったときに、彼らが迅速に理解して同じ方法で変更できるかどうかです。この点から見れば、私はアダプターパターンがとても好きです。インターフェースが決まれば、後の実装はどうでも良いのです。

Code Review で非常に厳しい人もいますが、多くの場合、個人の視点や好みに基づいて批判するのではなく、全体的な機能の設計やコードをより読みやすくする提案をするべきです。

ましてや、フォーマットに関して言えば、チーム内での大半の議論がフォーマットに関するものであるなら、ESLint や Prettier の設定を見直すべき時かもしれません。

コミュニケーション

チーム内で、どんな重大な決定をする時でも、少なくとも最初にチームと議論すべきだと思います。

全員が同意する必要はありませんが、チームの他のメンバーを馬鹿にするようなことはせず、自分の解決策が最高だと思わないことが大切です。通常、皆は製品をより良くし、開発をスムーズに進めたいと考えています。

ここで注意すべき2点があります：

1. 時にはチームメンバーが現在の書き方に慣れてしまっているため、新しい提案に無意識のうちに反対することがあります。この場合、背景となぜ新しい提案が良いと考えるかを説明できます。
2. チームの中でより経験豊富なメンバーとして、新しい提案を見たときには、より多くの文脈や歴史的なデータを相手に提供できます。

Jeff Bezos と Lex Fridman の Podcast で触れられている「disagree and commit」についてです。

この考え方が大好きです。

同意しないが全力で支持する。一度決定が下されれば、同意しなくても全力で支持することで、最終的にはただ意見の応酬が続くのを避け、プロジェクトが前進していることを少なくとも確認できる素晴らしい態度だと思います。

特に、チームメンバー全員が賢い場合、通常は同意しない部分はほんの一部だけです。（もちろん、それは一流のチームであることが前提です）

Disagree and commit は、多くの議論を省くための非常に重要な原則です。人生のどんな取り組みにおいても、チームメイトがいれば意見の不一致は発生します。社会内、企業内で、私たちは紛争を解決するために多くの仕組みを使用しています。そして、その多くは本当に悪いです。合意に至るための非常に悪い方法の例は妥協です。

Bezos は最悪の方法が妥協であり、双方が折り合いをつける結果は、結局は縫合怪物を生み出すことだと述べています。

この点で私も多くを感じています。権限が十分でない場合や、まだ信頼を築いていない場合、妥協を強いられることが確かにあります。また、ソフトウェア開発が要求が来て、評価した後に開発チームが実装する状態にあると、開発チームが全体の構想過程にあまり参加していないこともよくあります。

それが原因で、技術はまあまあなのに、自分で製品を作ろうとすると何も作れないような気がしたり、自分が作ったものがユーザーが欲しいものではないと感じることも、最近私が直面している課題の一つです。皆さんはどのような良い方法を知っていますか？