構造化プログラミングに喧嘩を売っているようなタイトルになってしまいました。
よりよいソフトウェアを作るためには何が必要か、とたびたび考えます。特に「堅い」ソフトウェアを作ることに興味があります。わたしが考える「堅い」とは、堅牢という意味で、変化に強く、保守がしやすく、変更しやすく、意図が明快、そんなソフトウェアです。
そう考えるうちに思い至ったのが、タイトルに挙げた３つです。
繰り返すからミスが起こります。本来の必要な処理に加えて、「繰り返し」の構造を作らなければなりません。for文の「for(...) {?}」のうち、本当にやりたいことは「?」の部分で、その前後で「繰り返し」の構造を作っています。
「始まり」を間違えることもあります。「終わり」はもっと間違えやすいです。だったら、最初から繰り返しを避けるようにするのがよいような気がしてきます。
分岐してもミスが起こります。処理の流れを追っていくとき、分岐があると、まずこっちの場合を考えて、次に、こっちの場合を気にしつつも脇において、あっちの場合を考えなければなりません。分岐が４つ組合わさると、流れを追うのを放棄したくなります。コードレビューでそういったコードを見つけると、まず最初に書き直しを勧めます。
そもそも処理を書くからミスが起こります。もっとも堅牢なプログラムを作る方法は、コードを書かないこと、という話があります。ただの冗談話かもしれませんが。ただ、書いたコードの量が多いほど、欠陥も多くなることは、よく知られたことだと思います。
処理を書かないでどうするのか？
ソフトウェアの開発は、最初、要求仕様の定義から始まると思います。この「定義」というのがポイントになるのではないか、と最近考えています。仕様の定義をどんどんどんどん詳細にしていきます。それこそ、ひとつの変数の取りうる値の範囲まで。そうすれば、処理を書かずに、定義をもってしてソフトウエアにならないか。
自分では、いい考えじゃないか、と思っていますが、もっとよく考えてみる必要がありそうです。
