著者： Bram Cohen
日本語訳： yomoyomo
以下の文章は、Bram Cohen による How to Write Maintainable Code の日本語訳である。
本翻訳文書については、福盛秀雄さんと竹中明夫さんから誤訳の訂正を頂きました。ありがとうございました。
ソフトウェア技術者は、自分が書くコードがどのようにあるべきか分からず悩んでいる。よく知られたエッセイ「悪い方がよい」（訳注：日本語訳）がその良い例である――どうして悪いほうがより良くなれるの？ やっぱり悪いほうが悪いんじゃないの？ さらにややこしいことに、「悪い方がよい」の話は、それが主張しようとしている内容とは正反対の議論の中で引き合いに出されることが多い。
問題は、みんながコードの「美しさ」を判断するのに非常に多様な、また往々にして相反する基準を採用していることだ。美的感覚よりも客観的な、コード品質に対する基準が明らかに必要である。
僕としては、メンテナンス性に基づいてコードを判断することを提案したい。
真にメンテナンス可能なコードは順応性があり、多くの用途に採用できる。たくさんの機能を盛り込んだからというだけで、コードのメンテナンス性が高くなるわけではない――現状使っていない機能を呼び出すのはメンテナンスではなく、それは単なる機能の利用である。メンテナンスとは、新機能を追加したり、既存の機能を変更する場合を指す。元のコードが書かれてからずっと後になって、それもまったく予想できなかった形で行われることが多い。
予想できないことを考慮するというのは矛盾した考え方である――それが何なのか分からないのに、どうやってそれを考慮しろっての？ ありがたいことに、役に立つ具体的なテクニックが多くある。
コードが短ければ短いほど、メンテナンスの手間は小さくなる。ひたすらプログラムのコードの文字数や行数を数え、何が何でもそれを減らせというのではないが、一般的に言って、短いほうがよい。使用しない関数やテスト文を除去すること――それらは苦労して読むにはゴミに過ぎない。
当然ながら、ライブラリを利用すれば、コードは短くなる。実際には、ライブラリには質がとても悪いため、書き直したほうが良いのも多いが、そうでないライブラリも多いので、可能な場合はライブラリを利用すべきである。
狭い橋しか接続手段のない明確な境界を作れば、近隣には何も知らせることなく街全体を再構成できる。あまりに交通量が多いと、一つ道をなくすだけで広範囲にパニックを引き起こしかねない。
どのように呼ばれるかとても分かりにくいコードがあると、他のすべてのコードについてもメンテナンスがより大変になる。例を挙げると、メソッド群が特定の順序でコールされないといけなかったり、特定のメソッドが一度だけコールされないといけない場合がある。こういうのは避けるようにしよう。
メンテナンス性の面で僕が気に入っている言語は Python だ。シンプルできれいな構文、オブジェクトのカプセル化、充実したライブラリのサポート、そしてオプションの名前付きパラメータがある。メンテナンス性が悪い言語の一例は Perl である。うん、僕は確かにそう言ったよ。撤回するつもりはない。
新規に書いたコードには何か壊してしまう危険が常にある。走らせるのが簡単で、「全部テストを通った」か「これらのテストに失敗した」か返すテストスイートがあれば、リグレッションの検出と修正がとても容易になる。実装よりもインタフェースをテストするようにすれば、テストコードの変更が必要となる頻度はずっと少なくなる。例えば、オブジェクトを文字列に変換し、それを復元する（「ピクル処理」（pickling）として知られる）コードならば、あるオブジェクトをピクルしてアンピクルし、その結果を元のと比較することでテスト可能である。こうしたテストは、たとえ文字列のフォーマットがまったく変わってしまっても継続して使える。
納屋を建てるには二つやり方がある――ひとつは自分でハンマーを作り、それを納屋を釘付けするのに使うやり方、もう一つは手で納屋を釘付けするやり方である。かかる時間は同じかもしれないが、ハンマーがあれば、将来もう一つ作るときに役に立つ。
ほぼあらゆる環境においてよりメンテナンス性の高いコードにつながる技術がいくつか存在する。ガーベッジ・コレクションはメモリ割り当てに関するあらゆる頭痛の種をてきめんに取り除いてくれる。単一スレッド化は、スレッドの安全に関するあらゆる頭痛の種を取り除いてくれる。また、インターネットアプリケーションを書く際の第一法則を忘れちゃいけない――「TCP/IP を再実装するなかれ」
これまで幾度となく、自分は何か「正しく」やろうとして欲求不満を感じ、「そいつをやっつけたい」と思い、より簡潔で適切な対処をしてきた。それがハック止まりなこともあるが、多くの場合それが、自分が欲求不満を感じた正にその問題に対するより柔軟な解決法につながっている。
コードの 1% が、全体の動作時間の x% を占め、近年ではその x が劇的に増加しつつあるという経験則がある。高速なマシンが開発時間よりずっと安価になっていることとあわせると、これは性能が、以前より大きな問題でなくなっているということを示している。より良い性能を目指して努力するのが当然な場合もあるが、性能は他の要素と同じように一つの特徴として見るべきで、ソフトウェアを構築するのに最優先すべきものではない。メンテナンス性のほうがずっと重要なのだ。