激辛テクノロジ批評(1)

[↑一覧] [新着] [ホームページ]

　そこで、実にタイムリーなことに、インターフェースという雑誌の9月号を見 ていると、「辛口テクノロジ批評」と題して、「ソフトウェア製造現場の教育性 を高めよう」というコラムが載っている。書いているのは Robert T. Myers 氏。 内容をまとめると、「ソフトウェア技術者の生産性を高めるような教育をして、 ソフトウェア危機を乗り切ろう」という感じになるだろうか。

　以前にも何度か書いたような気がするが、「新入社員を採用する時にどのよう なプログラマーを求めるか」と問われれば、私は「プログラミングの教育ができ る人」と答える。既にプログラミングできる人を必死で探すより、素質のある人 を採用して社内教育した方が気が利いているし、妙な癖のあるプログラムを作ら れて、保守に四苦hack するよりは絶対効率的だと思うのだが。

　さて、そのコラムの内容だが、学校教育等に比べて現場教育における有用性を 説いている点で高く評価したい。組織的な問題にまで考察している点もすばらし いと思う。

ただ、学校へのコンピュータ導入について、小学校、中学校の時代からのほう がよいと書いてあるが、私はこれでは遅すぎると思う。少なくとも、言葉を喋れ ない時代からキーボードに慣れさせておいて、「ママ」という言葉より先に dir a: を覚えた…などというのは流石に冗談がすぎるが、違和感を持たせないために は幼児教育がよろしい。となると、学校はもちろんだが、もっと家庭、または妥 協するにしても幼稚園・保育園の段階で既にコンピュータに触らせてみたい。

    *

　この記事に、「生産性を考えるための例題と解答例」という項目があった。こ れに対しては久々に面白いと思ったので、詳しく紹介したい。例題がとにかくす ごいのである。次の通り。(p.284)

問：文字列を逆さまにする

　では、先に私の解答を書いておく。別に模範解答ではないが、本人は真剣に解 答したつもりである。「最初に昼寝をする。やや疲れがとれたら、「こんな内容 の仕様ではプログラムが作れる訳がない、具体的な仕様書を送れ」という内容の 報告書を作成して、暫く自分の作業ファイルの整理やメールの返事の作成を行う。」

　こんな仕様でプログラムを作れという方が悪いことは明白ではないか。「動か ないコンピュータ」の例にたよるまでもなく、いいかげんな仕様が現場でどれ程 悪影響を及ぼし、いくつのシステムを廃棄するしかない状態に追い込んでいるこ とを、ちらっと頭に思い浮かべただけでも、「きちんとした仕様書」がどれほど 重要か理解できるというものだ。また、「きちんとした仕様書」は、ソフトウェ アの生産性を（現在の）何倍にも高めるのではないだろうか。

　プログラマーの悲惨な苦労が身にしみる、という訳ではないが、これに対する 解答例が４件ある。このあたり、「インターフェース」を参照してください。

　プログラムが今後の論旨に重要なので、引用しておく。

    ［図１］Ａ君の解答

char b[100];
strrev(a)
char *a;
{
    int i, j;

    j = strlen(a);
    for (i = 0; i < j; i++) {
        b[99 - i] = a[i];
        b[100] = '¥0';
        strcpy(a, &b[99 - i]);
    }
}

    ［図２］Ｂ君の解答

strrev(a)
char *a;
{
    int i, j, len;
    char temp;

    len = strlen(a);
    i = len - 1;
    for (j = 0; j <= len / 2; j++, i--) {
        temp = a[j];
        a[j] = a[i];
        a[i] = temp;
    }
}

    ［図３］Ｄ君の解答

char *strrev(a)
char *a;
{
    register char *up, *down, t;

    for (up = a, down = a + strlen(a); up < down; up++, down--) {
        t = *up;
        *up = *down;
        *down = t;
    }
    return a;
}

　　　　a[j] ^= a[i];
        a[i] ^= a[j];
        a[j] ^= a[i];

これに対して、Ａ、Ｄ君は１時間、Ｂ、Ｃ君は徹底的にテストしたために２時 間かかったという設定である。Myers 氏の評価は、Ａ君は失格で 20 点、Ｂ君 80 点、Ｃ君 75 点、Ｄ君 90 点である。

　Ｃ君の点数が低いのは、「十分なコメントをいれないかぎり、後からきた人は さっぱりわからない」のが理由となっているが、しかし、私は異論あり。少なく ともFPRG の会員の皆さんなら、さっぱりわからない訳がない、こんなのは初歩の 初歩だ。それにコメントを付ければすむ話ではないか。ま、ここはコメントがな かったという事にして妥協しておこう。

　Ａ君の評価が低いのは、「バッファが固定サイズなのでプログラムがいつパン クするかわからない、また、スタック上でなくプログラム外にバッファが存在し ているのでサイズが不利」という理由らしい。これは私はいちゃもんを付けたい。 もともと仕様らしい仕様もないのである。

　「文字列の長さはどれだけサポートすればよいのか」「値はどうやって返すの か」「与えられた文字列は上書きできるのか（ＲＯＭの文字列を逆転したいのか もしれない）」「漢字コードはどうするのか」「引数が文字列へのポインタだと すれば、それが NULL である場合はあるのか」、このような状況程度は仕様とし て渡してくれないと、プログラマーがかわいそうというものである。仕様作成が 誰の責任かしらないが、仮に担当ＳＥが張り付いていたとすれば、これはＳＥの 責任とすべきである。

　Ｂ君の評価がＤ君より低いのは、ポインタではなく配列を使っているから、ら しい。また、「１文字だけの文字列でもその１文字を自分に上書きする。バグと まではいえないが、きれいでもない」と書いてある。

「Ｄ君作は完全とはいえないが、ほかよりは間違いなくベター」だそうだ。ど こが完全といえないのか、説明はないようだ。さらに、生産性を点数／消費時間 で計算して、次のような評になっている。

            点数    生産性
    Ａ      20      20
    Ｂ      80      40
    Ｃ      75      37.5
    Ｄ      90      90

さて、私が最初の方に書いたような解答だと、はたして Myers 氏はどのような 評価をするだろうか。:-)

これで話が終わるかというと、FPRG の SYSOP はそんなに甘くない。私の評価 はこうである。解説は次の「廃墟にて」に書く。

            点数    生産性
    Ａ      0       -
    Ｂ      10      0
    Ｃ      10      0
    Ｄ      0       -

    COMPUTING AT CHAOS RUINS -76-
    1989-08-24, NIFTY-Serve FPROG mes(4)-002
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1989, 1996