よいコードは何のためか

TL;DR

書かれたあとも継続的に成長が続くコードにおいて、変更への強さを維持するため。

よいコード・よい設計

ソフトウェア開発においては、よい設計をしてよいコードを書くための原理原則やプラクティスが多く知られている。例えば重複を避け、凝集度の高い単位へ分割して疎結合なモジュールによって機能を実現し簡潔さを保ち変化に強いコードがよしとされる。開発手法によってニュアンスが異なる事もあるが、いずれにしてもコードやその設計には良し悪しという尺度がある。

「良さ」は何のためのか

プログラミングを学び初めの頃、自分はそういう教科書的な原理原則を「良さ」として学んで分かったつもりになっていた。が、ある時コードレビューで「よいコードでなくても動くのだから別に構わない」という同僚をうまく説得できない事があった。個別の書き方を取り上げて「重複があるとメンテナンスのコストが増える」といった説明はしたが、納期に合わせて書き上げるのを急いでいた同僚を説得できなかった。なんのための「良さ」なのかを共通のビジョンとして共有できず、優先順位の議論がうまくいかなかった。

次のゲームを有利にする

「納期とコードの良さとどちらがより大事なのか」という問題に対する歯切れのよい回答がアジャイル開発の本に書いてあることを最近知った。Alistair Cockburnの"Agile Software Development : The Cooperative Game"に下記の記述がある。

The project has two goals: to deliver the software and to create an advantageous position for the next game, which is either altering or replacing the system or creating a neghboring system.

つまり、プロジェクトで達成すべきは「ソフトを正しく動かすこと」と「次のゲーム(システムの更新・改善や拡張)において有利なポジションを占めること」の2つがあるということだ。同僚は前者に注力していたが、後者も重要なファクタであり、特にライフサイクルが長いコードにおいてはより重要になる。

拡張性・保守性を越えて

ソフトウェア開発でアジャイルが主流になる以前から、拡張性や保守性といった性質はソフトウェア品質特性としてあげられており、変化に対応可能であることはよしとされてきた。しかしそれらは多くある品質特性の一部であり主役ではなかった。アジャイル開発においては変化に強いということが特別に重要な性質となり「開発を支える前提」と言えるくらいの共通認識を得たように思う。われわれ職業プログラマが書くコードは一回きりであることは稀で、一度動き出した後も成長させていく事が多い。動くコードを書くのは当たり前で、次のゲームを有利にするために労力をかけるべき、その判断のためにコードや設計の良し悪しがあると考えるのがよいと思う。