この記事は次のリンク先のスライドに大きな影響を受けています。
質とスピード / Quality and Speed – Speaker Deck
この記事でいうきれいなコードはテスト容易性、理解容易性、変更容易性を十分に持っているコードのことを言います。
しばしば「きれいなコードは後からコードを読む人、使う人が困るから必要」といわれる時があります。これを更に大きくして「きれいなコードは保守運用のために必要」といわれる時もあります。しかしながら実際の業務における開発では開発の時点できれいなコードでないと時間をはじめとして色々と損が起きます。
業務におけるシステム開発ではおおよそ次の守るべき最低限の目標があります。この辺りがあまりにも守られていない場合、納品拒否やプロジェクト立ち消えもあります。
- 品質
- 顧客の目的に沿った製品か
- バグが含まれていないか
- 速度
- 納期は守られたか
この目標において無視できない点は、品質を高める際にはコードの変更が不可欠という点です。
顧客の目的に沿った製品を作るためにはある程度、完成品に近づいた製品を見せてより精度の高い目的を引き出すことが必要です。これが必要な理由は抽象的には、顧客自身が何が必要かわかりきっていない、開発者が顧客が何を欲しているかわからないのが理由です。具体的なモノを用意することによってより精度の高い要件が露になります。この話は「顧客が本当に必要だったもの」あたりでググるとより詳しい話がでてきます。より顧客が本当に必要な製品を作るためには、古い情報を元に作られた既存のコードを変える必要があります。
「バグが含まれていないか」はシンプルです。そもそも動かないようなものは論外でセキュリティホールが空いている様なものもかなりよろしくないです。また顧客が「なんか思っていた動作と違う動作をしている」と思ったらバグの範囲です。そういった既存のコードの問題を修正するためには既存のコードを変える必要があります。
十分な品質を達成するにはコードの変更が必要不可欠だという話をしました。そしてきれいなコードでなければコードの変更を円滑に進めるのは困難です。コードの変更にのみ着目して話をしましたが、コードの変更があったならば変更に関するテストを行う必要があります、手が空いていたり現作業者では解決困難であったりする場合は元のコードを書いた人とは異なる人が該当コード部に投入されコードを理解する必要が出てきます。そんなわけで業務における開発においては品質を高めるためにテスト容易性、理解容易性、変更容易性が役立ちます。
最後に残された守るべき最低限の目標に「納期は守られたか」があります。要するに十分な品質を持つ製品を指定の期日までに完成させなければなりません。早く十分な品質を達成するためには先に述べた通りテスト容易性、理解容易性、変更容易性がいくらか必要になります。規模と期日によっては必要不可欠になります。
余談ですが冒頭に挙げたスライドで引用されているマーティン・ファウラー（ソフトウェア工学辺りの分野で長らく現役で活躍しているすごい人。ソフトウェア工学の本を読むとふらっと出てきたりする）の言によるとコードの品質を意識した時の損益分岐点は一か月辺りとのことです。人や会社にもよるでしょうがほぼ全ての案件でコードの品質を意識した方がお得ですね。
Is High Quality Software Worth the Cost?
