スパゲッティコードと闘う本「レガシーコード改善ガイド」

最近は派生開発とか保守開発がメインの仕事になってしまい、新規開発をやった経験が無いという若い開発者も珍しくないようだ。経験を積めないという点で気の毒なことだと思うが、それと同時に、これらの開発に対処するための確固たる方法論が無い点も由々しきことだと思う。学校で教わるソフトウェア開発はいつも新規開発だし、ソフトウェア開発関連の書籍も新規開発を当然のことのように取り上げることが多い。しかし、開発の現場で実際に多いのは、新規開発よりも既存コードをベースにした保守開発の方だったりする。

「レガシーコード改善ガイド」は、そんな保守開発において既存のコードをどのように扱っていくか解説した本だ。そもそも「レガシーコード」とは何を指すのか？著者は定義として下記の説明を挙げている。

テストのないコードは悪いコードである。どれだけうまく書かれているのかは関係ない。どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。テストがあれば、検証しながらコードの動きを素早く変更することができる。テストがなければ、コードが良くなっているのか悪くなっているのかが本当にはわからない。

ソフトウェア工学の王道を行く主張と見なされることは無いだろうけど、開発現場に即したこの定義には深く頷かざるを得ない。ビジネスとしてソフトウェア開発を行う以上、ベースとなっているコードがどんなに酷いもの（俗に言うスパゲッティコードとか、大河小説の如く長大なコード等）であっても、納期通りに機能変更・追加を行ってリリースしなければならないのだ。既存コードのややこしさに辟易した経験を持つ開発者なら、こんな結果オーライの定義も納得できるのではないだろうか。

著者は、こんな極悪コードに対処する数々の方法を教えてくれる。下記の手法はその一例だ。

• 「第13章 変更する必要がありますが、どんなテストを書けばよいのかわかりません」

振る舞いを維持するために必要なテストを、私は仕様化テスト (characterization test) と呼んでいます。仕様化テストは、コードの実際の振る舞いを明らかにするテストです。「システムはこれをするべきだ」とか「こうしていると思う」ということを確認するテストではありません。仕様化テストは、システムの現在の振る舞いをそのまま文書化します。

もちろん、一筋縄ではいかないコードも存在するわけで、その対処方法も説明されている。

• 「第15章 私のアプリケーションはAPI呼び出しだらけです」
• 「第17章 私のアプリケーションには構造がありません」
• 「第22章 モンスターメソッドを変更する必要がありますが、テストを書くことができません」

もう、どうしようもなくなったら、最後の手立ても用意されている。

• 「第24章 もうウンザリです。何も改善できません」

こんな優れた参考書が手元に有れば、どんなに滅茶苦茶なコードでも自信を持って対処できることだろう。（と願いたい...）

レガシーコード改善ガイド (Object Oriented SELECTION)