ごみため(ー日ー膳！)

 

で、動かないとQ&Aサイトで質問。

 

それでも動かないと、もう1回ググって別のソースをコピペ。

 

動くまで繰り返す。

 

 

 

そういう手合いをモンキーパッチャと呼ぶそうです。

 

中身を理解しないでコピペするので、タチが悪い、ということらしいです。

 

 

 

＊＊＊

 

さて多くの大部屋開発では、モンキーパッチャが大活躍しています。

 

ごみためが目撃した中でもっとも驚嘆したのは以下のようなモンキーです。もはやパッチャーですらありません。

 

   

モンキーサンプル

   

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

 

具体的な例が必要でしょう。たとえば

 

   

if( a == 0x23 & ( ( b < 127 ) || ( c > 100 ) ){

   

   log_printf( “this means a bug.” ); ★

   

}

 

というようなコードがあり、バグを示すログ★が出るという状況です。

 

モンキー連中は、とにかくまず、以下を試します。(試行1-1)

 

   

if( a != 0x23 & ( ( b < 127 ) || ( c > 100 ) ){

   

if( a == 0x23 & ( ( b = 127 ) || ( c > 100 ) ){

   

if( a == 0x23 & ( ( b < 127 ) || ( c < 100 ) ){

   

・・・

 

それから次のようなことを試します。(試行1-2)

 

   

if( a == 0x24 & ( ( b < 127 ) || ( c > 100 ) ){

   

if( a == 0x23 & ( ( b < 128 ) || ( c > 100 ) ){

   

if( a == 0x23 & ( ( b < 127 ) || ( c > 101 ) ){

   

・・・

   

※少し利口なモンキーは各変数をログに出力します(笑

 

ちなみに試行とはもちろんコンパイル～動作確認～ログ取得のサイクルを一通りこなすことです。 組み込み現場なら、いわゆるROMイメージ作って～実機にデバッガで転送して～みたいな作業もすべて含みます。TAT(ターンアラウンドタイム)はデスクトップアプリなら数分～組み込みなら数十分もありえます。試す組み合わせ数は順列組み合わせなので、膨大です。彼らを殺すのに銃もナイフも必要ありません。ifの条件節が10個ほどあればよいのです。すべてを試し終わるころにはプロジェクトが終了しているどころか人類の歴史も終わっているかもしれません・・・

 

この辺までやると、

 

   

理由は分からないが、”★を出なくする修正候補”

 

がいくつか見つかります。それをリストとして保存します。(リスト1)

 

 

 

低レベルのモンキーはこのリストに従って修正を実施し、修正としてリリースしてしまいます。まともな再帰試験が実施される組織なら修正箇所の周辺でバグが発生し、修正リリースは巻き戻されることになるでしょう。

 

そうするとモンキーはリストの順に修正とリリースを繰り返すのです。2回目以降の修正は即座に実行できます。調査は1回目のときに終わっていますからね(笑

 

 

 

もう少し利口なモンキーはリスト作成をすべての担当バグについて繰り返します。

 

つまりリストの作成をバグ2・・・nまで繰り返してから、修正リリースをおこないます。

 

この際、賢明なることに、

 

   

複数の修正候補の中から同じ修正箇所を含むものがあったら、

   

修正内容が矛盾しないように

 

リストを統合するのです。

 

このモンキーは統合をおこなわないモンキーよりも作業の進捗がおよそ5倍早いのでスーパーモンキーズとして重宝されます。

 

 

 

モンキー連中の強みは、

 

・常に同じ手法を用いるので、

 

・プログラミング言語にかかわらず同じ修正スピードを実現する

 

・(一般的に妄信されている)バグの難易度にかかわらず同じ修正スピードを実現する

 

となります。

 

 

 

この特徴は阿呆な口入屋にとっては、この上のない管理のしやすさです。

 

 

 

さて、クチばかり達者な似非技術者ほど、

 

   

このバグはプログラムの構造上の問題なので、簡単には直せない

 

とか

 

   

前任者の意図が分からないので安易に修正することは危険

 

あるいは、

 

   

これはバグではなくて仕様の不備かもしれないので、顧客との打ち合わせが必要かもしれない

 

などと言い訳ばかり吐いて、さっぱりバグ票を処理しません。

 

 

 

モンキー手法なら、最低の最低レベルのプログラミング知識しか必要ありません。

 

ありませんが、一定の速度でバグ票を”処理”することができます。

 

 

 

ごみためまんは、このモンキー手法で、

 

   

不等号の向きの意味が分からない人

   

“以下”と”未満”の違いの分からない人

 

が「立派に客先の要望に応えている」と高く評価されている現場をこの目でみました。

 

 

 

バグの処理スピードだけで評価してはいけないことは、最低限度まともな仕事をしたことのある人ならわかると思います。

 

ですが、その最低限度のまともさを備えていない現場しか経験していないひとが、何年も仕事をこなして、リーダになったり、部長になったり、したらどうなるでしょうか。

 

 

 

考えてみてください。

 

モンキーパッチャーが善で、モンキーパッチャーを非難して、小ばかにしている我々こそが悪なのかもしれないということを。

 

 

 

彼らは、

 

なんら技術的指導も受けられず

計算機の基礎知識も学ばないまま

作業効率と稼働時間ばかりを要求され

      

結果だけを求められ続けてきたのです。

 

そんななかで編み出された彼らの”技”はいずれ自動プログラミングの実用的な礎となるかもしれません。

 

彼らが一切のバックボーンなしでバグを修正しているのに、知ったかぶりのプログラミング技術をひけらかしてばかりで、さっぱりバグを修正できない連中のイカに多いことか。

 

 

 

ごみためではこのパラダイムシフトに大いに着目しています。

（つづきがありま～す）

故・田口玄一博士を偲んで：モンキーにも言い分はある