レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

12章プラクティス8設計は最後に行う

すべての設計を最後まで先延ばしにすべきだと主張しているわけではない。ただ、ソフトウェアの設計活動の中には、開発サイクルの最後に実施したほうが効果的・効率的なものがあるのは確かだ。ここで議論しているのはホワイトボードでやる設計の話ではなく、コードがすでに書かれていて、テストでサポートされている状態からの設計の話だ。この時点が、ソフトウェアの保守性を設計するのに最適のタイミングなのだ。

テストがあることで安全にコードをクリーンアップできる。そのため、コードが動作して、サポートするテストがある状態まで待ってから、コードの設計を形にする。適用するデザインパターンの判断やシステムのより良い理解は、プロジェクトの最初よりも、プロジェクトの終わりのほうが得られやすい。

今までのやり方とは順番が逆になるのだ。これまでの開発では、コードを動かし、開発サイクルの終わりまでにどれだけバグを取れるかにフォーカスしてきた。ただ、このプラクティスでは、これまでとは違い、いかに保守可能なコードを書くかという設計に努力を払う。

テストを最初に書いて、最後に設計をしよう。

12.1　変更しやすさへの障害

保守可能なコードは読みやすく理解しやすいため、変更が簡単で柔軟だ。コードを書いた開発者だけでなく、ほかのプロのソフトウェア開発者にとっても、読みやすく理解しやすいのが重要だ。

ここまで、「良いコード」の一面は変更しやすさにあることを見てきた。開発者に変更しやすいコードとは何かと質問すると、たいていは、ドキュメントがそろっているとか、意図がわかる名前がついているとか、一貫したメタファーに従っているなどの回答が返ってくる。それらはコードの理解をたやすくし、変更を楽にする。

コードを変更しやすくするために、開発者が利用できるガイドラインはあるだろうか？　答えはもうわかっているだろう。 ...