以前から読もうと思っていましたがようやくレガシーコード改善ガイド (Object Oriented SELECTION)を読みました。読み始めて最初のうち、これは久しぶりに名著の予感と思いましたが、後半は自分の趣味と合わない部分が多々あったので、平均的には普通に良書という感想です。
ある意味、本書は奇書です。テストコードを書くためにコードの改悪も辞さない、という態度を貫きます。改悪は著者もわかっていて、次のように冒頭で断っています。
この仕事は外科手術のようなものです。切開し、内臓をかき分けていく間、美的判断は保留にしなければなりません。
小説には奇書と呼ばれる作品群があったりします(そして一部の熱狂的支持者がいます)。技術書で奇書と呼べるような本はあまりお目にかかりません。著者の技術レベルが低くて、内容がとんでもな意味での奇書は存在しますが、技術力のある著者があえて定石を外しまくる本書のようなのは初めてです。本格ならぬ破格な本です。
自分にとって、未だテスト駆動開発はユートピアです。
テスト駆動開発のどこに違和感を感じるかと言うと、単体テスト時に偽装コードに置き換える箇所ほどバグの温床なのではないかという疑念です。
たとえばネットワーク関係のコードがある時、単体テスト時のネットワークアクセスを避けるため、ネットワークアクセス部を偽装コードに置き換えます。本書もそれに類する技法をたびたび言及します。でも本当にバグが起きやすいのはネットワーク部分じゃないのかと思います。予期せぬエラーやタイミングの問題がバグを誘発します。システム境界ほどバグが起きやすいのは経験から明らかです。
こう書くと、そういうのはネットワークエラーを例外として抽出して、例外処理を単体テストすればいい、とその筋の人は言いそうです。たぶん教科書的にはそうなのでしょう。
ネットワークコードは一例です。単体テストの紹介を見るにつけ、偽装コードに置き換えたそのシステム境界こそがバグの要因なのに、と思うことがしばしばあります。ちなみにシステム境界の中でもバグの温床ナンバーワンは人間との境界です。単体テストの世界ではなかったことにされる領域です。
そんなわけでぼく自身はテスト駆動開発についていけていません。しかし、(方法論の名称は変わったとしても)これからのソフトウェア開発でもっとも重要になる方法論であると思っています。テスト駆動開発が常識になれば、オブジェクト指向とか関数型プログラミングとかどうでもいい話になるぐらい重要なパラダイムシフトです。そのシフトへは何かまだ足りない気がしますが、何が足りないのかはわかりません。
修正: 偽装コードを擬似コードと書き間違えていたので修正。
最近のコメント