レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
「レガシーコード」の概念と、それから抜け出すための実践的な方法について記載した本。
ケント・ベックのXPとのつながりが多く見られる。ウォーターフォールを抜け出してアジャイルへ。細かいサイクルを繰り返すことで完成に近づけていく。
レガシーコードはテストのないコード？
第1部 レガシーコード危機
1章 何かが間違っている
他の分野のマネジメント手法と、ソフトフェア分野のものとの違い。最初にガチガチに作る発想だと、ソフトウェアはうまくいかない。
そもそも、ソフトウェアをどのように開発・保守していけばいいのかをほとんどの人が知らない。
リリースをまとめて大きく行うことは非効率的。
2章 CHAOSレポート再考
CHAOSレポート：ソフトウェアプロジェクトの成功率を評価したレポート。
しかし、このレポートの「成功」「問題あり」「失敗」の定義自体に疑問符がつけられる。
「初期の納期・予算・機能がすべて満たされていること」を成功の定義としているが、「初期」の納期・予算・機能は予測でしかない。
この定義で「成功」とされるプロジェクトには、コードの品質が悪く、使っていくうちにひどくなっていくプロジェクトも含まれる。保守が悪夢！
注目したいのは、「なぜ失敗するのか」
失敗の要因１：コードの変更 変更できないコードが多すぎる。変更したいときには膨大な手作業のテストが必要となる。
失敗の要因２：蔓延 見つけにくいバグがコードに含まれる。
失敗の要因３：複雑性の危機 「ちょっと」でつけた機能が、全体を複雑にし、保守・修正のコストを上げる。
これらの失敗が、アメリカだけで100億ドル単位の損失につながっている。
3章 賢人による新しいアイデア
アジャイルにしよう！アーリーアダプターからアーリーマジョリティのあいだを超え行き渡る時期が来ている。
第2部 ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
4章 9つのプラクティス
専門家が使う技術はすべて学習できる。専門家がすることを理解し、そのとおりにすれば、同じ結果を得られる可能性が高い。高い品質を保っている人を真似よう。
理論を守るところから始める。その経験から実践につなげていく。自然とできるようになるまでに10,000時間の練習が必要！
第一原理の例としては、「単一責務の原則」「オープン・クローズドの原則」がある。ただし、「何をすべきか」であって、「どうやるか」は教えてくれない。
「どうやるか」はプラクティスの守備範囲である。プラクティスの定義は以下の３つ。
- ほとんどの場合に価値があるものである
- 学ぶのが容易である。教えるのが容易である
- 実施がシンプルである。考えなくてもやれるくらいシンプルであること
変更しやすいコードを書くことは、将来発生する要求に比較的容易に応えられることに繋がる。
原則の理解、プラクティスを使う本来の理由の理解のためには、「良い」ソフトウェアとは何かを合意しておきたい。
「良い」ソフトウェアとは 当初の機能要件を満たし将来のニーズに対応できるように変更しやすくなっているものである。
9つのプラクティスとは以下の通り。
- 1.やり方より先に目的、理由、誰のためかを伝える
- 2.小さなバッチで作る
- 3.継続的に統合する
- 4.協力しあう
- 5.「CLEAN」コードを作る
- 6.まずテストを書く
- 7.テストでふるまいを明示する
- 8.設計は最後に行う
- 9.レガシーコードをリファクタリングする
変更可能なコードを作りつつ、ソフトウェア開発プロセスを効率化する助けになる。
5章～13章
9つのプラクティスについての具体的な解説。
14章 レガシーコードからの学び
全体のまとめとなる章。
これらのプラクティスは、ソフトウェア開発者がソフトウェア開発者のために始めたものであり、マネジメントのためのものではない。
引用「たとえそれがウォーターフォールプロセスだとしても、組織の同期点が開発プロセスの中でうまく機能しているようであれば、アジャイルのマネジメントプラクティスをたくさん導入する必要はないのだ。」
ソフトウェア開発の手法には正解はない。いろんな方法を拾い集め、自分の抱える問題に適用できるやり方を拾い集めていこう。