ちょうど、携わっているプロジェクトのコードがレガシーで、アーキテクチャから考え直さないといけないフェーズに来ていた。書店に寄った際に、タイトルが目につき、なにかヒントが得られればと思い買ってみた。通して呼んだが特に気になった章だけメモする。
全体とおして
レガシーコードを通して、どんなコードがいいコードなのか、良いプログラマのメンタルモデル、良いプログラマの行動を学べる本だった。最近続けざまに読み返したい本が続いてるがこれもその一つ。
1章 - 何かが間違っている
過度なコメントはノイズになるっていう話。https://www.tegurin.dev/posts/abb8_0dmknd この投稿で読んだ。分析するときに目的の解答を得たいときに、寄与度合いの低い情報はノイズになり、分析時にコストになるという話を思い出した。コメントはコードの意図を読み解く手助けをするために書くものであり、過度なコメントをすると逆に読みづらい。
2章 - CHAOSレポート再考
> 今日、ソフトウェアはあらゆるビジネスの中心にあると言っても良い
ほんまよな。7, 8年前に書かれた本だけど今でもほんとにそう。
## 4章 - 9つのプラクティス
今働いている会社のエンジニアはここに出てくるような、メンタルモデルを持ってる人が多いと感じる。最初の設計は設計でリスペクトしつつ、必要あらば、しっかりと時間をとり、再設計、ドキュメント化して共有が適切にできている。ここで紹介されてる例で言えば、正しい場所が見つかるまで頻繁に名前変えたり移動する。使われないコードを即座に消す。変数も意味のある単位で分割して定義する。など当たり前っちゃ当たり前なんだけど、呼吸するようにやっていきたい。
8章 - プラクティス4 協力しあう
ペアプロは知識の共有において最も早い手法。そういえば、以前話したEMの人で、その人の前職で常にペアプロだったので、レビューもほぼなくマージしてたっていう話を聞いたのを思い出した。なんでそうしたか、こうやらないのはなぜかなど会話すると良いとのこと。新しいプロジェクトに携わる時は積極的にペアプロリクエストしていこうと思った。
エクストリームプログラミング聞いてことあるけどどんな内容の本か全く知らなかった。が、プラクティスを極限までやってみるとどうなるかってことが書かれた本らしい。読んでみたい。
## 9章 - プラクティス5 「CLEAN」コードを作る
CLEAN、Cohesive, Loosely coupled, Encopsulated, Assertive, Noredundant。凝集性が高く、疎結合であり、カプセル化されていて断定的である。の略らしい。カプセル化のメリットというか実装が具体的に想像できていなかったけど、インタフェースと実装を切り離すことで、利用側は、実装を気にしなくていいので、実装を変更した時に、インタフェースが変わらなければ、実装の変更だけにとどまるので変更の影響が他に波及していかないという学び。
明日のベロシティのために今日品質を上げる。急がば回れ。構造的なリファクタをしてから実装をする。
トレードオフを理解する。
スティーブンキングの言葉も引用されていて、「作家になりたければ絶対にしなければならないことがある。たくさん読んで、たくさん書くことだ」。真。
10章 - プラクティス6 まずテストを書く
テストファーストで振る舞いを先に定義して実装していく。TDD本も読んだことあるが、フロントエンドでどうやるかってのが未だ具体的になっていない。フロントエンドにおけるテストの考え方、実装、ちゃんと調べれば色々出てくるのでそろそろ本腰入れて一度やりたいところ。。。
13章 - プラクティス9 レガシーコードをリファクタリングする
外部の振る舞いは変更せず、内部構造を変えること。DIすることでテストしやすくなる。依存をモックしてしまう。2回目から適切にやるってのが腑に落ちた。１つの例で汎化するのは難しい。２、３こ具体的な例が出てきたら汎化せよ。これはチュートリアルやるくらいじゃ難しくてある程度の規模のアプリケーションを書いていくことで養われる感覚な気はする。リファクタリング本が次に控えてるのでこの章見て読むの楽しみになってきた。
やってみたいこと
- チャンスあれば積極的にペアプロやってく
- 使われなくなったコードを積極的に削除しにいく
- エクストリームプログラミング読む
- リファクタリング読む