以前読んだけど、最近の経験を踏まえて改めて読んでみたら当時はよりもすんなり理解できることが多かったので、気になる点を個人的な意見と共にまとめます。 初心者から中級者まで定期的に読み返すべき良書だと思います。

何を作ればいいのか

ユーザーの欲求・行動を知ることが大前提。 プログラムは開発者でなくユーザーに価値を提供するために作るものだから。

推測で実装するのはダメ。説明できないから。ユーザーのニーズを探り、また実際の行動を追いかけて初めて、何を作ればいいのかが見えてくる。 その際は抽象的なものではなく具体的なシナリオで考えること。

APIなどの利便性は、常に使う相手のことを考えたものであるべき。 開発者にとって楽なものは工数に現れ、ユーザーにとって良いものはメリットに現れる。

また、YAGNI・DRYの原則は守るべき。最適化もまだ早い。 最初はアドホックな実装で構わない。どうせ要件は後で変わるのだから。

技術的負債・リファクタリング

技術的負債を持つことは悪くない。 問題はそれをいつまでも返済しないこと。

リファクタリングの注意点

• テストコードの用意。仕様の確認
  • →まずゴールと現状を知らなければ手を付けてはいけない。テストがないのはありえない。
• ゼロから書きなおすのは基本NG
  • 既に動いていてバグ修正も行われているものを作りなおすのは手間が掛かり過ぎる。
• 少しずつの修正が大事
  • 他人にも流れが理解しやすい。うっかり互換性を壊すなどの心配がない
• 好みやエゴ、新技術はそれだけでは改修の理由にはならない。
  • どのくらいメリットがあるかを示す必要がある。

オブジェクト指向 ドメイン指向

単純なデータのやりとり（get/setなど）を記述するのではなく、そのドメイン・オブジェクトに特化した処理を記述する。 そうすることで、自然言語に近くなり、初見でも仕様を理解しやすくなる。

また、扱うデータは必要最小限が理解しやすい（テストもしやすい）ので、それ用の型を用意してあげるとより理解が楽。例えば数字を扱う場合でも、それがある値の範囲内にあるべきならそれ用の型を用意する。（時間なら23までとか。欧米なら11か12までかもだけど。）

レビュー

コードレビューはコードの質を上げるためだけではなく、互いの技術の理解度チェック、仕様の確認にも役立つ。 （前者は実装コード、後者はテストコードで確認できる？）

コメント

コードに書けないことのみをコメントに残す。 例えば、その実装を用いた理由や他の候補案など。あるいは外部に公開するインターフェースも、内部でどう動くかまではコードに起こせない（インターフェース利用者が黄にすべきではない）ので必要になるだろう。

しかし、それ以外のものをコメントしたい場合は、コードで表現できないかをまず考える。表現出来ない場合は、言語か自分の能力に限界がある可能性が高い。

するべきことは常に明確に

「〜〜の実装」などという曖昧な内容で作業（チケットの消化）をすべきではない。これには以下のようなものが内包されている。

• 〜〜の実装案の収集
• 収集した案の中からの検討
• 検討方針の検証コード
• 実装

これらをきちんと分けるべき。

実装方針・仕様が曖昧な状態でリポジトリを変更してはいけない。まず検証する際は別の小さなサンプルで試す。 つまり、なるべく小さく試せることが重要になる。（そのために定期的にリファクタリングし粗結合を保つ。）

見積もりとコミット

見積もりはプログラマ（実装する人）が決めるもの。希望納期はお客様が決めるもの。 コミットは、プログラマ・PM・お客様の合意で決まるもの。 見積もりや希望納期はPMが決めることはできない。 これはもちろんスケジュールとターゲット（実装内容）を含んだもの。

プロであるために

医者と比較してみる。

• プロはその場しのぎでなく確実に業務をこなす。
• プロは常に学び続ける。
• プロは自分の書いたコードに責任を持ち、バグが出ないとみなせるレベルで仕上げる。
• プロはタスクリストの数を常にコントロールする。
• 自分に出来ないことはない。後は納期とコストの問題。

もしこれらを意識出来ていなければ、形・思考だけでもプロになりきってみる。それも仕事の一部。