問題の多いソースコードは縦に延びる

ソフトウェアの問題点を調査していたら、一つの関数で1000行を超えるものに出くわしたことがある。そんな長い関数を作るからバグが生まれるのだよと思いつつ処理内容をチェックしてみるが、24インチのモニタに表示させても全体像がサッパリ分からない。仕方ないのでプリントアウトした13枚のA4ペーパーを床に並べ「このif文がここまで延びて...」等と赤ペンを片手に構成を解きほぐしていく。同レベルの処理が並んでいるだけならあまり問題ないのだけど、本来異なるレイヤーで行うべき処理を1箇所に無理矢理押し込んでいるので解読する方も大変だ。

開発者は本当にこの長い長い処理を理解してコードの改変を行っているのだろうか？という疑問はあるが、その前にそもそも何故こんな巨大なコードになっているのだろうか？Subversionのリポジトリから変更履歴を参照してみると、長年に渡って多くの人がコードの改変を行っており、誰か特定の一人が主犯というわけでもないようだ。特に意図が有ってそのような作りになっているのではなく、機能追加を重ねるうちにいつの間にか長大なコードが出来上がってしまったらしい。

問題が多いコードには共通の特徴が備わっていることが多いが、典型的な例として下記がある。

時間の経過と共に縦に延びる（長いコードになる）
共同所有という名の下に、誰もメンテナンスの責務を取らない
品質を維持するための継続的な努力が行われていない

長い処理を分割するとか、クラスを追加して役割分担する等の作業が行われると、構成が横方向に広がる（ファイルが増える等）ものだが、そんな手間のかかることは誰もやりたくないし、自分に割り当てられたタスクさえ終えれば、他のところまで手を伸ばす必要なんか無い。という訳で、メンテナンスが行われないコードはひたすら縦に延びることになる。気の利いた管理者なら、号令をかけて定期的にリファクタリングを行うものだが、そんな出来の悪いコードを管理する人も（コードに勝るとも劣らず）問題が多く、しかもテストコードの欠片も存在しないので、デグレードが怖くて下手に手を入れられない状態になる。

この事例を教訓として、定期的にソースコード量の変化を監視し、右肩上がりでコードが増え続けるファイル（クラス、関数）は要注意項目としてチェックするようにした。問題が発生していていない状態でアレコレと口出しすると嫌われることが多いけど、障害の未然予防としては欠かせない作業なのだ。