仕様の詳細を詰めるのも仕事のうち

二昔前のプログラム仕様書といえば、1行ごとにどうプログラムを書くかまで詳細に記述されたもので、プログラミング言語への翻訳と入力だけがプログラミングだったこともありました(コーディングと呼ばれることもあります)。今でもそういう現場はあるでしょうが、全体的な傾向としては、プログラミングに前もって、あまりに詳細な設計を行うことは少なくなっています。

予め決められたことが少なくなるということは、細かいところは(もちろん人にも確認してもらいながら)自分で詰めていく必要があります。エラー系の処理や、内部の関数・メソッド分割など、細かいことですが、システム全体の品質に大きく影響を与える重要な仕様を設計することも、プログラミングという仕事の一環なのです。

ラフにでも、頭の中ででも、設計してから書き始めよう

そのような状況ですから、少なくとも経験の浅いうちは、資料を貰っていきなり開発環境に向かってプログラミングを始めることはお薦めしません。

資料を受け取って内容を理解したら、どのように実現するかをスケッチしましょう。なにを入力にしてなにを出力するのか、処理の流れはどうなるか、主要な変数にはどのようなものがあるか、発生しうるエラーはなにか。裏紙やホワイトボードにざっと書き出してみましょう。

そうすることで、考慮漏れを防ぐとともに、受け取った資料の不備に気づくこともできます。作るプログラムの全体が把握できますので、作業の段取りや時間配分もスムーズになります。

code a little, test a little.

さぁ、ではコードを書き始めることにしましょう……。いや、ちょっと待ってください。ここで身につけて欲しい習慣があります。プログラミングとセットで、そのプログラムのテストプログラムを書くことです。

どのようなプログラムでも、このような入力があればこう動く、この入力ならエラーになる、という仕様があります。先にスケッチした設計がそれに当たります。設計した仕様どおりに動かなければバグということになりますが、大掛かりなテスト工程はプログラミングの数週間から数ヶ月も先になることがあります。そんな先になってからバグが分かっても、どこをどう直せばいいのか、すぐには分からないものです。であれば、プログラミングと同時に、できる範囲のテストをしてしまいましょう。

まずはコンパイルが通る最小限、メソッドや関数のインタフェースだけを書きます。returnは仮の値を返すようにしておきましょう。

    public boolean isPositive(int arg) {
        return false;
    }

そうしておいて、そのプログラムを呼び出すテストプログラムを書きます。34

    public void testIsPositive() {
        if(Target.isPositive(1) != true) {
            // バグであるから、テストはエラー。
            System.out.println("failed.");
            System.exit(-1);
        }
    }

テストプログラムを実行すると当然エラーになりますから、テストが通るようにプログラムを実装していきます。

このように、少しずつコードを書いては少しずつテストをするのを繰り返していくやり方で、バグを最小限に防ぐことができます。こうした手法を実践することを助ける、JunitなどのTesting Frameworkと呼ばれるものもありますので、活用してください。