原発づくりの、職人がいなくなっている。だから、素人がつくる。

設計は完璧だけど、施工が、いいかげんというのが、今の原発の状況らしい。
施工している人は、設計図どおり作っているつもりだけど、ちょっとしたミス、しかも、大事に至るようなミスをしても気づかないということ。

　原発にしろ、建設現場にしろ、作業者から検査官まで総素人によって造られているのが現実ですから、原発や新幹線、高速道路がいつ大事故を起こしても、不思議ではないのです。

　日本の原発の設計も優秀で、二重、三重に多重防護されていて、どこかで故障が起きるとちゃんと止まるようになっています。しかし、これは設計の段階までです。施工、造る段階でおかしくなってしまっているのです。

　仮に、自分の家を建てる時に、立派な一級建築士に設計をしてもらっても、大工や左官屋の腕が悪かったら、雨漏りはする、建具は合わなくなったりしますが、残念ながら、これが日本の原発なのです。

perlでもundefと0を区別する必要があるのに、それをごっちゃにしたような場合かな。

#!/usr/bin/perl -w
use strict;
use Test::More qw(no_plan);


#もともと、割り算の関数が提供されていたとする。
#第２引数がundefまたは0のときは、計算不能ということでundefを返す。
#それ以外は、商を返す。
sub warizan{
    my($a,$b) = @_;
    return undef unless ($b);
    return $a/$b;
}

#上記関数を使って計算不能のときは"ERROR"という文字列を返す
#実装を行ってみる

#
#誤
sub my_warizan_ng{
    my($a,$b) = @_;
    if (my $shou = warizan($a,$b)){
        return $shou;    
    }else{
        return  "ERROR";  
    }
}
#
#正しい実装
sub my_warizan_ok{
    my($a,$b) = @_;
    if (defined(my $shou = warizan($a,$b))){
        return $shou;    
    }else{
        return "ERROR";  
    }
}
                   
is my_warizan_ng(1,0),"ERROR","1/0の結果なのでエラーになる";
is my_warizan_ng(0,1),0,"0/1の結果なので答えは0";
is my_warizan_ng(0,0),"ERROR","0/0の結果なのでエラーになる";
is my_warizan_ng(4,2),2,"4/2の結果なので答えは0";

is my_warizan_ok(1,0),"ERROR","1/0の結果なのでエラーになる";
is my_warizan_ok(0,1),0,"0/1の結果なので答えは0";
is my_warizan_ok(0,0),"ERROR","0/0の結果なのでエラーになる";
is my_warizan_ok(4,2),2,"4/2の結果なので答えは0";

このコードを実行すると

[test perl_test]$ perl warizan.pl
ok 1 - 1/0の結果なのでエラーになる
not ok 2 - 0/1の結果なので答えは0
#   Failed test '0/1の結果なので答えは0'
#   at warizan.pl line 40.
#          got: 'ERROR'
#     expected: '0'
ok 3 - 0/0の結果なのでエラーになる
ok 4 - 4/2の結果なので答えは0
ok 5 - 1/0の結果なのでエラーになる
ok 6 - 0/1の結果なので答えは0
ok 7 - 0/0の結果なのでエラーになる
ok 8 - 4/2の結果なので答えは0

テストコード40行目

is my_warizan_ng(0,1),0,"0/1の結果なので答えは0";

がおかしい。
warizanからは、0が戻るが、これを、エラーと判断してしまったからだ。
ngの実装でもこの1つ以外は、問題なく、動いている。
すなわち、ちょっと、ミスをしても、ほとんどのケースでは問題が起こらないのである。
まあこれが問題。

で、どうやって発見するかというと、perlの場合はテストコードを書く。
テストコードがかけるということは、使用を理解していることが条件になる。

逆に、テストコードを書きながら、仕様が、決まっていないことに気づいたりする。

原発の話から、テストコードになちゃった。

このテストの発想、CPANにモジュールを登録するような人であれば、日常的にやっているかもしれないが、ほとんどの開発者は、業務アプリを作ってるような方でも、ほとんどできていないのが現実。
数年前、大きな業務アプリの開発をしたことがあるが、このときは、単体の自動テストとはまったくできてなくて、テストといえば、コンパイルしたアプリを、起動から初めて、テストコードを投入して、ということを延々と手動でやっていた。
テスト項目は、エクセルのシートに書かれていた。
やばい、とおもったが、すでに、おそし、最後は、会議室に数人が常駐し、このどうしようもない手動手テストを延々と続ける事態になった。
ただ、自分の担当部分は、unitテストを行っていたので、自分の部分は自身をもって、リリースできていたのだ。

全体のプロジェクトがどうしようもなくなっていたときに、この自動テストを、すこしづつ採用してもらって、なんとか、収拾できたりもした。
その後も、僕自身が参加するプロジェクトは、テストをコーディングするということを行っている。

原発もちゃんと、仕様を理解した、テストができているのだろうか？

原発はどうやら、設計はすばらしいらしい
でも、実装後のテストが、いい加減なのかもしれない。
放射線を浴びながらでないとテストできないと項目もあるという。
なんとも、せつない。

コーディングなら、寝不足になって、不機嫌になって、病気になるくらいで、ことはすむが（もちろん、それで済ましていいはずはないけど）原発は、大惨事を招きかねない。
やるなら、もっと、本気でやるべしなんだろうとおもう。

でも、やれている方は、一生懸命なのはよくわかります。
でも、一生懸命だから、許されるようなシステムでないのですよね、。原発は。