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

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

電車の中で読んでました。本書でのレガシーコードの定義は単にテストがないコードと断言していますが、人が書いたドキュメントもテストもなんもない動いてるコードを修正したりするのってすごい大変よねぇと思います。てか、恐いという表現が近い。理想は今から変更を加えようとしているコードにテストが書いてあればどんだけ心強いことかという話で、そのためには変更箇所だけでもよいからテストコードを書いてから、テスト駆動で修正を加えようというのが本書の目標なんだけど、大抵のクラスはテスト用にインスタンス化しようと思ったら、コンストラクタで別のクラスのインスタンスが必要になって、、、と簡単にテストが書けないことが大半。そういう場合にモックを作ったり、部分的にリファクタリングしたりとか色々な案を提供してくれます。

ここで重要なのは、完璧な機能の仕様をテストするわけではなくて、今から加える変更によって、どのように振る舞いが変わるかまたは変わらないかを確認するために最小限のテストを書くということ。この考え方を使うと、テストを書くためのリファクタリングのためのテストを書くと言う際限ない事態に対して、リスクを抑えつつ、最小限の確認だけを行って、少しずつテストできる範囲を広げて行くということができるようになる。そこのさじ加減は慣れで完璧を保証するものではないのだけど、まぁ単純に編集して成功を祈るよりも、精神衛生上何かしら積み上げていった方が気分的にラクなのでよいんじゃないかという程度かもしれない。

本書はオブジェクト指向なC++やJavaの話題が大半で、抽象化もへったくれもない手続きオンリーのbashのシェルを扱うにはどうすればよいかとか、個人的にはそーゆーところも教えて欲しかったけど、ちょっとだけ出てくるCの話題では、プリプロセッサとリンカで誤魔化すぐらいしかできることは殆どない著者もゆってるので、贅沢というか、どうしょうもないというのが結論かもしれない。

本書の主題ではないけれど、他人の書いたコードを理解するための方法として、試行リファクタリングという手法がちょこっとだけ紹介されてたのが個人的にはおもしろいと思う。やり方は簡単で、リポジトリからローカルにコピーしたコードを捨てることを前提に好きなようにお試しでリファクタリングしてみる。この設計に対して、自分ならどう書き直すかというのは思考実験としてやってみるだけで、コードの構造と処理内容の理解が進むらしい。

確かに言われてみれば心当たりがあると思うけど、ググってWeb上から拝借した人のサンプルコードをコピペして変数名や関数名変えるだけでも立派なリファクタリングだと思う。なぜなら、最もふさわしいと思う命名は処理内容がわからないと付けられないから。名前から受けるコードの印象はかなり大きいし、うまいこと名づけられたらそれだけで理解しやすくなる。さらに自分なりのスタイルに整形して適当にメソッド分解して、しっくり来るようにクラスで切り出してとかやると、それはもはや自分の手の中にあるコードとして、血肉の一部になるんじゃないかと。コード書くためにWebからコピペして直すのと同じように、意味不明な黒魔術のコードでも似たようなことをすればよいだけではないかということに気づいた。動くものを作るためか、理解するためか、目的が違うだけ。