余分なコードは決して書かない

「より少ないことは、より豊かなこと(Less is more)」。言い古された格言ですが、確かに真実です。

たとえば、一部のコードを削ることで、かえってコードベースの質が向上するということもあります。私も実際にコードベースをそういう方法で改良したことがあります。

今日のソフトウェア開発は、YAGNI (You Ain’t Gonna Need It :それは多分、必要ない)をはじめとするXP (eXtreme Programming) のプラクティスに従って行われることが増えています。ただ、人間のすることなので、どうしても時々は、プラクティスに従わずに作業をしてしまうことがあるのです。

以前、ある製品を開発した時、一部のタスクの実行に時間がかかりすぎるという問題が起きたことがありました。本来は、ほぼ瞬時に完了するはずの簡単なタスクです。原因は、実装をやりすぎていたことにありました。ベルやホイッスルなどといった余分な付属機能を加えすぎていたのです。作った時にはステキなアイデアに思えたのですが、結局は無駄でした。

この時は、不要と思われるコードを削ることで、実行速度を上げることに成功しました。余分な機能をなくすことで、コードベース全体の「エントロピー」を下げた、と言うこともできます。作業の間に何も壊していないことは、ユニットテストが教えてくれました。

これは、コードをシンプルにすることの効用が実によくわかる例だと言えます。

しかし、そもそもなぜ、不要なはずのコードが書かれたのでしょうか? あとで余分と判断されたとはいえ、プログラマはその時必要だと思ったからそのコードを書いたわけですが、なぜそう思ったのでしょうか。またレビューやペア作業で見過ごされたのはなぜでしょうか?それはおそらく、次のような理由ではないかと考えられます。

• 余計かもしれないが、面白そうだと思えた(ヒント:「面白い」というのはコードを書く理由にはならない。コードベースに新たな価値を加え得るコードのみを書くこと)
• 将来必要になるかもしれないと思った。そのためにはいま書くのがベストだと思った(ヒント:これはYAGNIに反していることになる。いま不要なら、いま書くべきではない)
• 必裂かどうか判断に迷った。顧客に判断を仰ぐべきだったが、それよよりも実装してしまう方が簡単たと思った(ヒント:余計なコードを書くにはその分、手間と時間を要し、また保守にも手間と時間を要することになる。実際には顧客に確認をとった方が簡単なはず。余分なコードを加えてしまえば、保守にかかる手間と時間は「雪だるま式」に増えることになる)
• 余分な機能を正当化するため、議論を経ておらず、ドキュメントにも書かれていない要件をプログラマがでっちあげた(ヒント:要件を決めるのは顧客であってプログラマが要件を決めてはいけない)

常に考える必要があるのです。いま自分が書いているコードは本当に必要なものなのか、と。