保守性とイマドキの開発

「ソースを綺麗にしてコードの保守性を高めよう」なんて事は誰もが言うし、「規約を作って静的チェックツールにかけよう」とか、「UnitTest を書いてリファクタリングも奨励しよう」なんて感じで話が進む事もあるけど、いざとなるとグズりだす怪しからんヤツらが実に多い。

スケジュールがきついからとか、コスト面の制約で人が足りないからとか言うのが、お約束のエクスキューズなんだけど、うーん、だからこそなんだがなあ・・・

で、ちょっとコードの保守性について、特に、それが大事なのは何故なのかという点を中心に考えてみる。

＝＝＝＝
実はまず、「保守性」ってネーミングが、そもそも良くなかったりする。語の使用の歴史的経緯から見ても、どうしても納品後の保守フェーズに係る品質要素という印象が拭えない。最も適切と思われる内部品質は意外と知られていないし、可読性だと読むだけみたいだし、「綺麗なソース」とか「健康なソース」では情緒的過ぎて説得力に欠ける。

ここで「保守性」を、開発者の素朴な観点から言い換えると、「保守作業の生産性」って事になる。ISO 9126の分類は、論点が違うのでここでは割愛

この生産性が低ければ、当該の保守作業にもその分だけ時間とお金が掛かったりするわけだけど、じゃあ、その保守作業とは何だっただろうか。

再び開発者観点で素朴に考えると、「既存ソースを読んで意図と構造を理解し、追加・書き換え・削除等の編集を施す」、さらに短くは「ソースを読んで編集する」という、それだけの事だとわかる。

で、これを踏まえて言い直すと、「保守作業の生産性」とは「ソースを読んで編集する作業の生産性」という事になる。…が、はて？こんなのは今時、保守フェーズに限定された作業なんかでは全然ない。

極論すれば、6ヶ月の開発期間における最初の10分くらいから、「ソースを読んで編集する作業」は早くも発生し始めるし、反復型の開発なら第二イテレーション以降は大部分がその意味で「保守作業」になる。

「動いてるコードはイジらない」的な昔の開発風景ならともかく、既存コードを編集しながら成長させる現代の開発では、「保守性」はプロジェクト全期間に渡る重大ファクターであり、開発初期から「実装生産性」そのものに漸近していく。

なわけだから、正しくは「スケジュールがキツいし人も足りない」-> 「ならば生産性を上げよう」-> 「つまりソースを改善して保守性を上げよう」と考えなければならない。これの逆をやってるから、各反復で負のスパイラルを誘発し、ドツボにハマっていく。

=＝＝＝
というのが、コード保守性に関する不見識への、差し当たりの抗議。

「そもそも保守性の高いコードとは何か」と、「保守性向上作業（リファクタ等）の工数はどうしてくれるんだ」という2つの事項についても説明が必要だが、別の機会にする。

まあ現場では、こうして理詰めで説明しても、心理的・組織的圧力で生産性を考慮しないままなし崩しに開発が進んでいってしまう事は往々にしてあるんだよなあ。