ごみため(ー日ー膳！)

  

 

  

まぁいいじゃないですか、ちょうど品質月間ですし。

    

先日、モンキーによる間抜けな話を書きました。

    

モンキーパッチャーが自動プログラミングを生みだす ごみため(ー日ー膳！)

    

   

・・・

     

ifの分岐条件を総当りで変更して、バグ票に書かれた現象が起きなくなる組み合わせを見つける。

     

・・・

     

試す組み合わせ数は順列組み合わせなので、膨大です。彼らを殺すのに銃もナイフも必要ありません。ifの条件節が10個ほどあればよいのです。すべてを試し終わるころにはプロジェクトが終了しているどころか人類の歴史も終わっているかもしれません・・・

    

上記で、「総当り」「順列組み合わせ」にひっかかった人は、すぐさま、

    

   

そりゃ直交表を使えば総当りでなくて済むはずだぜぇ～（byスギ薬局)

    

と反応したはずです。反応できなかった人は、品質工学をワクワクドナルド(統計入門)からやりなおしですね。

    

古典的な統計をまじめに学んだ人ほど、タグチ先生のバラツキの定義にかみついてくることでしょう。

    

しかしながら、統計学をかじりもしていない人は、ロバスト設計の何がすばらしいのかに気づくことができないでしょう。

    

    

 

    

この「馬鹿には見えない服」はなかなか厄介です。

    

 

    

さて、理論的裏づけや原理はどうでもよいのです。みなさんんもブール代数やチューリングの論文を読みもしないでノイマン型コンピュータのプログラムを書いておらっしゃる（つもりになっているだけかもしれませんが）。

    

 

    

さて、先日紹介したモンキー手法について、

    

   

阿呆なプログラマが

     

バグを取るのに四苦八苦している

     

（のを横で見てせせら嗤っている）

    

まじめにごみためをよんでいる奇特な皆様なら、ピーンときたはずです。

    

   

ソフトウェアテストに置き換えて

     

総当りでなく実験計画法を用いれば

     

至極全うな手順である

     

おや？

    

と。そうなのです。ごみためまんは先の記事を真ん中まで書いたところで、それを思いつき、あえて「総当り」を強調したくなったのです。

    

 

    

実験においてたくさんのパラメータまたは条件があるとき、総当りにしないで済ませる方法は実験計画法の入門編にもかいてあります。たいていは化学の物質のモル量や濃度のパラメータであったり、電子回路の定数であったりするわけですが、ソフトウェアへの応用も説明されています。

     

    

たとえばこの本にも最後のほうにも例があります。

    

 

    

ソフトウェアテストを効率化する際の根本問題は、

    

   

状態空間が広すぎる

    

ことだと思います。しかも疎です。

    

メモリだけを考えても、使うかどうか分からないメモリ空間が何GBもあります。そしてそのうちたった1バイトが0か1かの違いだけでシステムがクラッシュするのです。

    

そのアドレスすらわからないメモリの状態をテストや設計に含めないなら、ロバストなシステムは名ばかりになりますよね。

    

# もしそれがなんとかなってもHDDやクラウド上のデータはどうなります？

    

計算機の歴史の中でなんどかブームになった関数型言語は、その状態空間の問題を多少解決できるような気がしないでもありません。ですが、

    

   

手続き方言語の利点を取り入れた

    

とかいう多くの機構がすべてをだめにします。あらゆるユニットテストは、状態空間を都合よく切り取った

    

   

オレオレ条件下のみ

    

でのテストになるのです。そして設定ファイルがたった一行変更されただけでテストはパスしなくなるわけです。それからテストケースが1ダースほど増える、と。

    

 

    

さて、テスト工程で直交表を用いたまっとうな手法である手法が、プログラマがバグ追跡に用いるとモンキー手法に見えるのはどうしてでしょうか。

    

 

    

優秀なモンキーは直交表を知らずとも、総当りの組み合わせを直感的に効率的に間引いて実施します。

    

自称優秀なプログラマ達が

    

   

そんなの定義域や値域を全部チェックしなくていいよ

     

境界値と異常値、それから代表値だけで充分さ。

     

「テストは期待を裏切ったときだけ意味があるのさ」(byケントベック)

    

と嘯くのを許す一方、モンキーの間引きに後ろ指をさすのです。

    

 

    

そもそも田口博士にソフトウェアの検証手法を問うた人々は、大きな誤りを犯しています。

    

   

どうやったらソフトウェアの設計に

     

品質工学的アプローチを活用できますか

    

    

と問うべきだったのです。作ってしまったソフトウェアの検証作業の効率をいくら向上させても、ソフトウェアの品質が向上することはないからです。

（非連続都市伝説シリーズ：テストを増やせば品質は上がる ごみため(ー日ー膳！)）

 

確かにソフトウェアの実装の妥当性検証は重要なテーマです。ですが、そんな無駄な検証のいらない設計手法を考えたほうがよほど未来のためになると思います。

    

 

    

モンキー手法の間抜けな点の2つ目はそこにあるのです。モンキーがモンキー手法でしかバグを取れないような実装、設計、アーキテクチャにこそ問題があるのです。

    

 

    

まずはバグを設計しましょう。アナログ回路のノイズのように。

    

自動プログラミングの話はそれからです。ノイズがゼロの回路を設計する馬鹿はいません。許容されるノイズレベルを決めてそれを越えないように設計するのです。そのレベルは回路の性能をだめにしないレベルで規定されます。

    

バグも同じです。仕様を満たさなくなるバグは出ないように。仕様に関係のないバグは潜在してもかまわないのです。

    

# 何を当たり前のことをえらそうに書いているのでしょうか（笑

    

それを個数だけで計る馬鹿が多すぎるのが次の問題です。問題はバグの個数ではありません。バグを設計していないことが問題なのです。

    

（つづく）

  

 

  

先日の記事を投稿してから知ったのですが、

  

   

Monkey patch

  

というのはすでに広まった定義があるようです。

  

まつもと直伝プログラミングのオキテ 第４１回 モンキーパッチングの基礎から功罪まで  日経Linux  日経BP記事検索サービス

  

The End of Monkeypatching

  

 

  

ちなみにこちらはモンキーパンチ先生の公式サイトです。

  

モンキー・パンチ公式WEBサイト

  

それにしてもまったく無関係なRuby本を読んでいて、数日前に書いたネタが赤恥ネタだったことに自分で気づく気恥ずかしさ。

  

なんともいえませんな。にひにひ。