Clean Coder の感想
eggchicken
プロのプログラマ、あるいはプロのソフトウェア開発者とは何だろう。漠然と思い浮かぶのは、よく仕事ができるとか、綺麗なコードを素早く書くとか、そんな人だ。だけど、Clean Coder では、もっと現実的な人の姿が描かれていた。
始まりは、チャレンジャー号の打ち上げ失敗のエピソード。チャレンジャー号の技術者は、ロケット打ち上げ時のリスクを発見し、データを揃えて上層部に訴える。しかし、上層部の判断で打ち上げは強行され、そして事故が起こる。彼らはそのことをどう考えているか。嘆いているのか、それとも、もっと改めるべきことがあると燃え上がったのか。いずれにしても、プロの話をしようじゃないか、という話題の前振りとしては、意味深なところがとても気に入った。
ここでは、Clean Coder で描かれていたプロのやり方の中で、自分で取り入れたいと思う事柄について、書いていきたいと思う。
第一に「危害を加えてはならない」という原則を採用したい。意味は、可能な限りバグを出さないようにすること。そして、構造を犠牲にした機能追加を行わないこと。人である以上、完璧にそれをするのは無理なのだけれど、目指すことはできる。手を抜こうとする自分を思い留めるには、こういった気高い言葉を片隅においておくのが良い。
第二には「試しにやってみます」と言わないこと。もう少し詳しく言うと、十中八九できないとわかっている要求に対して、その場しのぎで「試しにやってみます」と答えないこと。この言葉には、責任感がない。「それじゃあ、試しに空中に浮かんでみます。試しに鉛を金に変えてみます。試しに大西洋を泳いでわたってみます。私にできると思いますか？」これは作中に出てくる言葉だが、実にもっともだ。やってできないことがわかっていることを、試すのは無意味だ。この言葉を使わないなら、できるかできないのか、自分の判断に対して責任をもつことになるだろう。特定の言葉だけにとらわれるのは良いことではないが、責任を考える、という意味では価値があるのではないかと思う。
第三にはテスト駆動開発を試すこと。テスト駆動開発のやり方は実に簡単で「小さなテストを書く」「実装する」の２ステップの繰り返しをするだけだ。テスト駆動開発のメリットは、だいたい次のようなことが言われている。バグが含まれにくいこと、リファクタリングがしやすいこと、ドキュメントとして役立つこと。実のところ、このあたりのメリットは、テストを後で書いても変わらない。テスト駆動開発のもう一つのメリットは「テストしやすい設計を考えることを強制される」ということだ。こういうことを考えると、テスト駆動開発というやりかたは、やりづらいことを習慣づけるための方法ではないかと思う。たとえば、下のような文章を考えてみる。
「運動習慣がないことは、良くないことだと誰もが知っている。しかし、自分から進んで運動するというのは、なかなかうまくいかない人が多い。そこで○○ダイエット法を取り入れてみたら、運動習慣がついた」
文中の「運動習慣」を「テスト」に置き換えて、「○○ダイエット法」を「テスト駆動開発」に置き換えてみれば、まさにぴったりくるじゃないか。そんな思いつきに満足しつつ、ダイエットよろしくテスト駆動開発を試してみようかと思った。
最後に受け入れテストを書くこと。言い換えると、Cucumber のようなシナリオベースの機械的なテストを書くこと。今まで普通のユニットテストはそれなりにやってきていたのだが、各機能の結合テストはすべて手作業でやっていた。だから、ひとつの変更が他へ悪い影響を与えていないかを検証するコストは、かなり高かった。そういうところを機械的に行えるのであれば、これを採用しない理由はない。一度も試していないので、悪いところも見えない。そういうわけで、次のプロジェクトでは、受け入れテストを書くことにしたい。
さて。これで少しはプロのプログラマに近づけるだろうか。いや、そもそもプロになりたかったっけ？ …考えてみると、また別の話になりそうだ。ともかく、こうして取り入れようと決めたことが、何かよい結果につながることを祈ろう。