ロバストPython ―クリーンで保守しやすいコードを書く

7章実践的な型チェックの導入

開発者はいつの日か完全なグリーンフィールドプロジェクトで仕事をすることを夢見る。グリーンフィールドプロジェクトとは、完全な新規プロジェクトのことで全くの白紙状態からアーキテクチャ、設計、モジュール構造を決定できるプロジェクトだ。しかし、ほとんどのプロジェクトはあっという間にブラウンフィールドになる。つまり、レガシーコードだ。こういったプロジェクトには歴史の重みがある。アーキテクチャと設計の大部分はすでに固まっている。全面的な変更を加えると、今ここにいるユーザに影響を及ぼす。ブラウンフィールドという言葉には大きな泥の塊を相手にするという語感があり、悪く捉えられることが多い。

しかし、すべてのブラウンフィールドプロジェクトが辛い仕事になるわけではない。マイケル・フェザーズは、次のように言っている。

よく保守されたシステムは、コードの書き換え方を理解するのに時間がかかる場合があるが、大抵、一度理解すれば変更は簡単になりシステムをより快適に感じられる。レガシーシステムでは、どうすべきかを理解するのに長い時間がかかり、変更も困難だ。†1

[†1] Michael C. Feathers. Working Effectively with Legacy Code. Pearson, 2013. 邦訳は『レガシーコード改善ガイド』（翔泳社、2009年）。

フェザーズは、レガシーコードを「テストなしのコード」と定義するが、私は、レガシーコードを「最初に書いた開発者と議論できなくなったコード」と定義する。最初に書いた開発者と対話ができないなら、コードベースが自ら記述する振る舞いに頼るしかない。コードベースが作者の意図を明確に伝えるならば、それは保守されたシステムであり簡単に仕事に取りかかれる。全体を理解するために少し時間がかかるが、理解すれば機能を追加してシステムを発展させていける。しかし、コードベースが理解しにくければ、苦しい展開が待ち受ける。そのコードは保守不能である。ロバストネスが至上命令となるのはそのためだ。ロバストコードを書けば、コードが保守しやすくなるためグリーンフィールドからブラウンフィールドへの遷移に伴う問題が軽減される。 ...