しっかりテストされリファクタリングされた長く使われるコードがある一方で、数日で捨てられることを前提にして書かれるコードもある。そしてこの両極の間に巨大なグレーゾーンが横たわっている。このグレーゾーンに属するコードはいつか削除されるという想定の元に書かれているが、決して消されることがない。
William Pietri氏は開発者とビジネスパーソンの視点からコードに関連するコストを分析した。氏によれば、コードは大まかに3つのカテゴリに分類できる。
- 一時的 - 短期間だけ利用して捨てることを想定したコード。
- 持続的 - 長く使うコード。しっかりリファクタリングされている。チームのメンバにもよく読まれている。強力な自動テストがある。メンテナンスが難しくない。
- いいかげん - 一時的と持続的の中間にあるすべてのコード。その場しのぎのコードの恒久的な蓄積。やっつけ仕事。
氏はこの分類の仕方に興味深い点を見つけている。それはコードに関連するコストに対するビジネスパーソンと開発者の感じ方の違いだ。氏はコードに関連するコストについて下記のような表を作成して比較している。
| ビジネスパーソン | 開発者 | |
|
一時的 |
低 |
低 |
|
持続的 |
高 |
中 |
|
いいかげん |
中 |
高 |
つまり、ステークホルダーはいいかげんなコードでも大抵は満足してしまう。いいかげんなコードはコストがかからず、望んでいる価値を生み出すからだ。しかし、この考えは巨大な過ちを生み出す。氏の考えでは、コードを比較するよい方法は開発者やビジネスパーソンといった役割は無視して、短期的なコストと長期的なコストを比べることだ。氏によれば、
| 短期的なコスト | 長期的なコスト | |
| 一時的 |
低 |
低 |
|
持続的 |
高 |
中 |
|
いいかげん |
中 |
高 |
いいかげんなコードは最終的には大きなコストを生み出す、ビジネスにとって有害なものだ。一方で持続的なコードははじめは高くつくように思えるが、長期的な視点に立てば最終的にはそれほどコストはかからない。
もちろん、いいかげんなコードは開発者にとってだけ有害なのではありません。企業全体にとっても有害です。ある企業のソフトウエア開発のコストが継続的に増加すれば、ソフトウエア開発に対してもっとしっかりと考え規律をもって取り組んでいる競合相手の企業がとても有利になります。
この3つのカテゴリに対して、Alex Chaffee氏がコメントをしている。氏の見方では持続的なコード = テスト + いいかげんなコード + リファクタリングだ。同様にChris Sterling氏もこのカテゴリに賛成して下記のようにコメントしている。
ビジネス上の大きな期待 + 開発上の少ない抵抗 = 高度に技術的な負債 という関係が成り立つと思います。この負債が原因で開発パフォーマンスは低減します。
Alberto Gutierrez氏は同じような分析をするために、別のコード診断方法を提案している。氏はコードの平易さと拡張性を考慮した指標をつかって、コードをAからFの6段階に分類している。平易さはコードの理解しやすさや読みやすさを定義する。拡張性はそのコードに対する機能追加のしやすさを定義する。A-Fの範囲は、すばらしいコードとまったくはじめから書き直す必要のあるコードの2つの両極端の間の程度を段階的に表している。
この分析でも平易さと拡張性を備えているのがもっとも優れたコードだという事実を指摘している。そしてこのようなコードは、William Pietri氏のが提案する持続的なコードという分類に属するだろう。
ではどのようにしてグレーなコードになってしまうのを防げばいいのか。
William氏によれば、ステークホルダーがコードの種類を長期的な意味で理解できるようになれば、開発チームは価値を生み出しやすくなる。また、技術的負債の罠に陥りにくくなるだろう。一度理解してしまえば、中途半端なコードを持続的なコードを簡単に区別できるようになる。
私の見てきたほとんどのプロジェクトでは、いいかげんなコードが凝固してしまってそれを何とか維持していました。危険なのは火事場を収めにやってきたカウボーイコーダーがいいかげんなコードを書き散らしたまま去ってしまい、そのほかの人々が後始末をしなければならない状況です。