ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

ルール10複雑性を局所化せよ

　複雑性は、スケールの敵である。

　ルール1によれば、「できるだけ単純であるべきだが、単純化してはいけない」ってことで、コードは単純な方が優れているのはご存知の通り。でも、プロジェクトのスケールが大きくなると、そういうルールに従うことは難しくなる。単純な問題ならコードを単純に保つことは簡単だが、コードが成長し成熟してくると、当然ながら複雑になってくる。そして、複雑になればなるほど、コードは作業しづらいものになり、全ての詳細を頭の中に入れておくことができなくなる。バグを修正したり、新機能を追加しようとするたびに、予測できない副作用につまずくことになる。前に一歩踏み出すたびに、予期しなかった後退の一歩が付き物になるってわけだ。

　複雑な問題に対しては、物事を単純に保つ、あるいは単純にする機会を探すという、部分的な解法がある。それがルール1だ。でも、複雑性を完全に排除することはできない。まあまあ機能していて長く存在しているソフトウェアであればどんなものでも、そのソフトウェアが解決する問題に内在する複雑性を耐えて切り抜けなきゃいけないだろう。でも複雑性は、管理することならできる。

　スポーツでの常套句を借りれば、「複雑性を止めることはできず、できるのは抑え込めるよう期待することくらいだ†1」。

†1　訳注：アメリカ合衆国のTV／ラジオ出演者で政治家のDan Patrick（1950-）がスポーツ実況者時代に好んで使ったフレーズ「（選手名）を止めることはできず、できるのは抑え込めるよう期待することくらいだ」に基づく。

　こういう場合、排除できない複雑性を全て分離することが有効な戦略となる。あるコードの内部にある詳細が複雑でも、外部インターフェイスが単純であれば、その複雑性はあまり問題にならない。そのコードの内部にいる時は、その内部の複雑性に対処しなきゃいけないけれど、コードの外部では気にしないでいい。 ...