リファクタリング～動いているプログラムを触る

プログラミングの現場では、「書き直したほうが早い！」という悪態をよく耳にする。既存のプログラムに機能を追加したり変更したりするときに、ソースコードがあまりに「汚い」と、思わず口から出てしまうのだ。しかし、実際にコードを書き直すか、そうしないで追加・変更していくかは、十分に検討する必要がある。

★

システム開発業界には、「動いているプログラムは触るな」という標語のようなものがある。ソースコードを変更すれば、間違って壊してしまうというリスクがあるからだ。しかし、この主張も絶対的に正しいというわけでもない。

この「触るな」の原則に従ってプログラムを改変しようとすれば、どうしても「無理な増築」をせざるをえない。そうすると、ソースコードはどんどん不自然で複雑なものになってしまう。そして、そのような汚いコードは、非常にバグを生みやすいのだ。

つまり、短期的には不具合を避けられるかもしれないが、長期的には不具合を誘いこんでしまうという皮肉な結果になりかねないのである。

★

リファクタリングとは、この「触るな」の原則に対するアンチテーゼである。などというと難しそうに聞こえるが、要するに「汚いソースコードは綺麗に書き直しましょう」という、あたりまえの話である。プログラムの機能が同じなら、コードは綺麗な方がいいに決まっている。

では、プログラムを壊してしまうリスクはどうするのか？　その答えもあたりまえに考えればよい。テストを完璧に行えばよいだけのことだ。完成して動いているものをもう一度テストしなおすなんて、面倒だって？　だったら、テストを自動化すればよいではないか。

★

「テストファースト」とか「テスト駆動」と呼ばれるような開発手法では、テストは自動的かつ完璧に行える。

テストが自動化できるのは、プログラムをテストするためのプログラムを作るからだ（多くの場合、xUnit という仕組みを使って効率的に作成する）。

では、そのテストがどうして完璧だといえるのか。それは、テスト用のプログラムを製品のプログラムよりも先に作るからである。ある機能を作りたいとき、まず、その機能をテストするプログラムを作り、後からそのテストを通過するような機能を作る。

ここで、「必ずテストを先に作る」ということが重要だ。そのルールを破らない限り、テストケースが漏れることはない（もちろん、テストと機能の両方を作り忘れることはあるが、それは別の問題である）。

★

こうした開発手法によって、完璧な自動テストが作られていれば、以後のリファクタリングは安心して行える。ソースを修正しても、テストプログラムを実行するだけで、プログラムが壊れていないかかどうかがすぐに確認できるからだ。

問題は、既存のプログラムにそのようなテストが存在しない場合だ。自分でテストを作成してからリファクタリングしてもよいのだが、作ったテストに漏れがないと言い切れるだろうか。特に、複雑怪奇なコードに直面したときには、自信が持てないことも多いだろう。悩んだ挙句、結局は「動いているプログラムは触るな」という原則に立ち戻ることも多い。

テスト駆動開発が普及すれば、そのようなことも少なくなるだろう。しかし、現実には、まだまだといった感じだ。「触るな」の原則をとるか、リファクタリングするか、状況に応じた適切な判断が求められるところである。

クリックお願いします →