レガシーコード改善ガイド

真面目にテスト駆動開発を学びはじめて一ヶ月が経ちました。

今まではネットで調べて得た程度の知識しかありませんでしたが、この一ヶ月の間に二冊の本を読むことで、自分のソフトウェア開発に対する考え方が大きく変わりました。

一冊目は「テスト駆動開発入門」です。詳細は以前の記事を見ていただくとしますが、この本を読んでようやくTDDというものがどんなものであるか体感することができました。

テスト駆動開発入門

とはいえ、それはあくまで理想の世界であり現実はそんなに上手くいかないもの。だから「TDDとかやった方がいいかもしれないけど、とりあえず今のシステムは動いてるし、今回のプロジェクトは下手に動かさない方がいいよね」などと思っていました。

しかし二冊目の本「レガシーコード改善ガイド」はその考えを見事に打ち砕いてくれました。

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

テストがないコードはレガシーコードだ！

この本の帯に大きく書かれたこの一文は、まるで死刑宣告のようです。いつ作られたかなどもはや問題ではないのです。例え2010年3月13日に完成したばかりのシステムでさえこの本の定義においては「レガシー」なのです。

例えていうならマトリックスです。いきなり目覚めさせられ、現実突きつけられ、絶望して死にたくなります。

しかし、読み進めていくうちにこの本の本質は絶望させることではないと分かりました。

私なりに先ほどのキャッチフレーズを補足してみます。

テストがないコードはレガシーコードだ。しかし、レガシーコードと戦うための武器はここにある。

「レガシーコード改善ガイド」には、現実と戦うためのさまざまな「武器」が紹介されています。

この本で紹介される重要な武器の一つが、「仕様化テスト」です。言い換えれば「現状を保護するためのテスト」です。DBでいうバックアップ、RPGでいうセーブみたいなものです。たとえ現在の仕様が正しかろうが間違っていようが、現状を現状のままに保護することで「うっかり動作を変えてしまってもすぐにわかるんだ」という安心感を持つことができるのです。

何万行単位のレガシーコードが目の前にある。しかし要件追加、バグ修正の要請は次から次へと銃弾のように飛んでくる(おまけに期日は明日とか無茶を言ってくる……)。そんなとき本書を開けば、せめて新規追加する部分だけでもテストで保護するための手法が書いてあります。既に動いているレガシーコードは残念ながらテストコードを書きません。その代わり「とにかく何も触らない」という古くさくはありますがそこそこ実績のある手法によって(当面の)保護をするわけです。こういった現実解を提供してくれるというのも本書の大きな魅力です。

数百行もあり、グローバル変数、あちこちのリソースへの依存、無茶苦茶なインデントや変数名、コードのコピペなどで肥大化・複雑化したフライング・スパゲティ・モンスターメソッドがあったとしても、それを理解・分解するための手法が本書にはあります。これは非常に重要なポイントです。つまりこの本はコードリーディングの本、それも汚いコードに特化したコードリーディングの本でもあるということになるわけですから。「Code Reading」に書いてある手法やひらメソッドは確かにコードリーディングの勉強にはなるのですが、今思うとこれらはどちらもきれいなコードを読むための手法だったように思います。

Code Reading―オープンソースから学ぶソフトウェア開発技法

そしてこの本が与えてくれる最大の武器は「現実と戦うための勇気」です。

巨大なレガシーコードがあったとしても、一度に全部テストできるように変える必要はないんです。一つづつ、自分の見れる範囲からちょっとづつ変えていけばいいんです。たとえ味方が自分一人でも、今日から戦えるんです。

テストコードをコミットしなくてもいいんです。とりあえず目の前のクラスに放り込まれている getなんたらメソッドの仕様化テストを書いてみましょう。

最初にテスト環境を用意するのはちょっと大変かもしれませんが、テストコード自体は一瞬で書くことができるはずです。そしておそらくテストはあっさりと通るでしょう。これだけです。このコードはレガシーじゃなくなるんです。システム全体から見れば本の僅かかもしれませんが、それでも今確かに自分の手でレガシーコードの一つを潰したのです。この瞬間から、他のメソッドやクラスでこの get メソッドを見たとしても安心できるわけです。

「こいつは既にテストで保護されている、だから心配ない」

と。

世の中にはレガシーコードがあふれています。TDDの威力を知りながら、理想と現実は違う、自分一人じゃ何もできないと諦めているエンジニアはきっと私の他にもたくさんいるはずです。だから、一度でいいからこの本を読んでほしいんです。今、この瞬間から、自分だけで、戦えるんです。自分の力で変えられるんです。

要件追加やバグ報告があったら以下の呪文を唱えてみましょう。この記事書いているうちに私が思いついたものですが、わりと気に入っています。*1

assertEquals、assertTrue…落ち着くんだ…テストを書いて落ち着くんだ…テストはユーザに見えないがシステムの挙動を守ってくれる孤独なコード…わたしに勇気を与えてくれる…

最後に、参考リンクを紹介しておきます。この本を買おうかどうしようか迷った方は、まずこちらの2つのページをご覧になるといいでしょう。私も以下のページを見て購入を決めました。

まず一つ目は翻訳者の小堀さんが直々に書いた本書の紹介記事です。仕様化テスト、スプラウトメソッド、接合部の作成などを紹介しています。全体の概要をつかめば充分という方(管理職の方など)はこのページがおすすめです。

二つ目は原書の読書会wikiです。担当割当表というページには、名前に反して勉強会の内容をまとめたページが多数まとめられています。全ての章について紹介されているわけではありませんが、内容のレベルは先ほどの紹介記事よりも一歩踏み込んだものとなっています。特に序文の翻訳は必読です。内容は本書の序文そのままですが、私はこの序文に書かれた著者の熱い想いに心打たれて購入を決めました。

*1:元ネタが分からないという人は「プッチ神父　素数」でぐぐろう