38-余分なコードは書かない

「プログラマが知るべき97のこと」の38個目のエピソードは、シンプルさに関する話です。「より少ないことは、豊かなこと（Less is More）」は、YAGNIと並んで最も重要な考え方です。仕様など設計にも言えることですが、より少ない仕様・コードで同じだけの価値をユーザに提供できるのであれば、それが最良な方法です。不足していては意味がありませんが、必要以上の仕様を提供しようとすれば、コードベースが肥大化します。コードベースが肥大化すれば、必要なテストも多くなりますし、潜在的な不具合も多くなるでしょう。同じだけの仕様を満たすソフトウェアをコードに落とし込むときに、コード量・クラス数などが多ければ多いほど、ユニットテストを多くやる必要があるでしょう。メンテナンスコストも高くなりますし、潜在的な不具合も多くなると言えます。同じだけの品質を担保するために、多くのテストを行うことについては問題がないようにも思えます。しかし、本当に細かく通常は起こりえないようなケース、例えば猫がコンセントを引っこ抜いたときなどまでテストすることは過剰と言えます。要求されている品質を満たすだけの必要最低限のテストをする方が効果的です。
しかし、今日のソフトウェア開発は無駄に満ちあふれています。Excelに代表される無駄なドキュメント、コード量を減らすことが許されないステップ数による見積、人を増やすことで売上が確保できる人月システムなど、余分なことを行う事が仕事となっています。ITバブルは過ぎました。これからは無駄に仕事を作るようなやり方は淘汰されていくと思います。そんな流れが加速してきたならば、如何に無駄を省き効率良く必要最低限のことを遂行できる人材に価値が生まれるでしょう。
また、本文にもありますが、プログラマは知的欲求を満たすために、余分な機能を作ってしまう悪い傾向があります。「必要になるかもしれない」ではなく「たぶん必要ないだろう」と考えるようにしないといけません。勿論、やっつけ過ぎる酷い実装にユニットテスト無しというレガシーコードを生産していいという訳でもありません。シンプルに、でもバランス良く、本質を見抜いて、不要なところはやらない、これを実践できるようになることは大きな目標です。それが達成できてきたならば、結果的に、スピードもスキルも品質も今より格段にあがっていると思います。
ということで、このエントリーもシンプルにまとめてみました。

プログラマが知るべき97のこと