概要
オライリーから出ている 「レガシーコードからの脱却」
を読んだので、重要な章を抜き出してノウハウをメモする。
第1部
1章 何かが間違っている
ほとんどのソフトウェアは作り方や保守の仕方を間違えている。
ウォーターフォールは最後にまとめてリリースするため一か八かの博打。
3章 賢人による新しいアイデア
アジャイルはウォーターフォールよりは良い。
一方で、アジャイルをしているチームも技術プラクティスを上手く使えていないために期待した利益が得られないでいる。
第2部
4章 9つのプラクティス
- やり方より先に目的、理由、誰のためかを伝える
- 小さなバッチで作る
- 継続的に統合する
- 協力し合う
- 「CLEAN」コードを作る
- まずテストを書く
- テストでふるまいを明示する
- 設計は最後に行う
- レガシーコードをリファクタリングする
9章 プラクティス5 「CLEAN」コードを作る
うまくカプセル化されたソフトウェアはアウトサイドインで設計することによって得られる。
- アウトサイドインプログラミング
- コンシューマの観点で機能を設計する
- サービスが何をやっているかを示す名前をつける
- どう動くかは隠す
- インサイドアウトプログラミング
- 問題を小さな塊に分解し、それらを縫い合わせる
- 最初に実装してしまうと全体が見えなくなる
「知らぬが仏」という言葉はソフトウェアにおいては常に真である。
CLEANなコードを作る。
- C: Cohesive (凝集性)
- L: Loosely coupled (疎結合)
- E: Encapsulated (カプセル化)
- A: Assertive (断定的)
- N: Nonredundant (非冗長)
名前は説明的、能動的、肯定的なものにし、結果的にシステムがどう変化するのかを反映する。
10章 プラクティス6 まずテストを書く
多くのテストを書きすぎたり、実装依存のテストを書いたりするとTDDは上手く行かない。
ふるまいを表すのに必要なテストだけを書く。
「ユニットテスト」のユニットとはふるまいの単位であり、メソッド、クラス、モジュール等ではない。
12章 プラクティス8 設計は最後に行う
最初のアーキテクチャレベルの設計というよりはコードの詳細設計的な話。
テストを書いた後にリファクタリングで設計を変えていく方が良い。
13章 プラクティス9 レガシーコードをリファクタリングする
コードを変更する場合は一緒にレガシーコードをリファクタリングする。
感想
プラクティスの大半はテストが必要というのもあって、上手いテストを書くことが非常に重要だと感じた。
Google本でも書かれていたが、やはりユニットテストだからといってメソッド単位でテストしたり、ホワイトボックステストを書くのは良くない。
最後に設計せよというプラクティスがあったが、そのためにはホワイトボックステストがあってはならないはずである。
この辺りの考えに対する後押しが得られたのが良かった。