プログラムに完成がないこと

まつもとゆきひろの『コードの未来』をたまに書店で立ち読む。前回はデザインパターンの章について読んだ。言語機能の説明がほんとピカイチだと思う。

そのなかで、オブジェクト指向に基づいたプログラミングとは、現実をモデリングするとかそういう話ではなく、OCP(Open-Close-Principle)に基づき単にプログラマが拡張・修正しやすいものだという話があった。プログラマの生産性を上げることが主眼に置かれてオブジェクト指向に辿り着いただけであって、別に現実の再現に対して思想的な何かがあったわけではないということだと思う。

　言われてみれば思い当たる節はあって、Listenerクラスなんてものは現実をまったくモデリングしていないし、拡張性を追求してデザインパターンを適切に使ったプログラムはむしろ現実から離れる傾向にある。それはただプログラマの生産性を上げるための道具に過ぎなかった、ということで。

　そうすると、プログラムには完成がない。納期があるから開発は終了しても、そのプログラムはまだ拡張できる。ユニットテストができるようにしたり、動的にメソッドを変更できるようにして簡単に新機能を追加できるようにしたり、そういう開かれた状態が模範なのだと思う。

　これは僕の状況に対して言えば、一日わずか１時間程度のコーディングしかできなかったとしても、その途中途中やほんのすこし先に設定した中間目標地点において、自分の次の日の開発がしやすいように書けているかが大事だということになる。完成がなく、しかしその代わりに、どの開発途上においても、拡張しやすく修正しやすい性質を持ったコードが存在するように作っていく。これは完成している訳ではないが、非常に優れた状態であるように思う。ズタボロの状態で表面上動くより、よっぽど。

　具体的にはヘルパ関数の設定や、各種assertの適切な配置が初心者の僕向けなのだと思う。初心者向けだと言っても、比較的簡単に解らしきものが見つかるというだけで、達成できるそれ（拡張性の高さ、修正の行いやすさ）は中級上級のそれと変わらないのだろうから、手を抜く必要はない。

　そう思うと、すこし自分のコーディングに自信が持てた。駄目を数えるとか、盤を文字列にして表示するとか、いま作っている関数がどれもこれも、あまりに初歩的なもので、いつまで経っても前に進んでいないんじゃないかと焦っていた。

　真相は、開発初期、中期、後期、どの一歩にも同じだけの質を求められていた、ということだったみたいだ。