モノーキ

デバッグパターン

デザインパターンを勉強していて、ふとデバッグにもパターンがあるよな。
と思って作ってみました。

これって、どこかに協力を仰ぎたいけど、誰に頼むんだ？
（結果的に協力してもらいました。thanks XPMLの皆さん、lemonさん）
何かおもいついた方はこちらへメールか、掲示板へ

プログラマ用セキュリティホールパターンってのが欲しいな
例えばSQL injectionとかいうセキュリティホール。
こんなの知らないと絶対やってしまう。
OSとかの設定ではなく、プログラマの設計において注意するセキュリティホールのパターンが欲しい。
集計などはやってもいいので、どこかで有志を募って集めてくれませんかね？

○デバッグパターンについて
・デバッグパターンとはプログラマから観測できる現象とそれに対する原因と対策をパターンとして登録したものです。中にはアンチパターンという、やってはいけないパターンも存在しています。また、一般的なバグに対するデバッグの方法論に関してはデバッグパターンとして定義しています。
パターンとアンチパターンの境界線は難しいのですが、「やってもしかたないよね」に近いものをパターン、「これをやるようならプログラマ失格」に近いものをアンチパターンとしています。
・パターンは分類順に並べています。分類中は追加順に並べています。ただし言語、システム特有のパターンは分類の最後に並べてあります。
・最近追加更新されたパターンは<New>マークがつきます。
○使用方法
まずはデバッグパターン全体を読んでみましょう。「あいたたた・・・・」と感じられるところは対策をよく読んで、改善するようにしましょう。次にデバッグパターンの「パターンになるものはないか？」を意識しながら仕事をしてみましょう。そうすると、今まで見えてこなかった無駄が見えてくるかもしれません。こうやって少しずつ生産性をあげていきましょう。もちろん見つかったパターンは投稿しましょう。すると作者が喜びますし、他のプログラマの助けにもなるかもしれません。そうしたら他のプログラマも、新しいパターンを送ってくれるかもしれません。それを読んであなたはさらに生産性をあげることが出来るでしょう。
○パターンの見方

最近追加、更新されたパターン
9/3
情報無しアンチパターン
 切り分けミスアンチパターン
 NonRefactaring アンチパターン
（thanks lemon氏）

分類１デバッグ手法

名称：GiveUp アンチパターン
分類：１．デバッグ手法、３．プログラマのバグ
現象：バグの原因がさっぱりわからない｡
原因：業務・コーディングに対する思い込みにより、原因が見極められない｡
対策：同じ業務の順調に進んでいる人間に付き合ってもらえ。
補足：君の頭が堅いのなら、平身頭低頼み込め｡

名称：告白デバッグパターン
例：「こうして，ああして，こうなるでしょ，こうなるはずなのに，なんでかな～，．．．あ，そうか！」
分類：１．デバッグ手法
現象：複雑ないしは単純に見えるプログラムが一人では解決できない。
原因：自分で理解しているつもりが、理解しきってない。
対策：人に横についてもらい，説明する。

名称：机上デバッグパターン
現象：複雑ないしは単純に見えるプログラムが画面上でにらめっこしてても正しく見える。
分類：１．デバッグ手法
原因：自分で理解しているつもりが、理解しきってない。
対策：紙に印刷し，赤ペンを持ってソースを精読する。

名称：ステップデバッグパターン
分類：１．デバッグ手法
現象：複雑ないしは単純に見えるプログラムが画面上でにらめっこしてても正しく見える。
原因：自分で理解しているつもりが、理解しきってない。
対策：デバッガでステップ実行する。
補足：机上デバッグパターンの近代版とも言えるが。だからといって机上デバッグの重要性がいささかも薄れたわけではない。

名称：プリントデバッグパターン
分類：１．デバッグ手法
現象：複雑ないしは単純に見えるプログラムがおかしな値を吐き出す。
原因：プログラムの入力、あるいは計算過程に間違いが含まれている。
対策：プリント文を入れまくる。
補足：ステップデバッグパターンで、デバッガが利用できない環境に用いることが多い。

名称：バイナリサーチ・プリントデバッグパターン
分類：１．デバッグ手法
現象：複雑ないしは単純に見えるプログラムのバグのポイントが特定できない。
原因：プログラムの入力、あるいは計算過程に間違いが含まれている。
対策：デバッグプリントを入れる際に，バグがありそうな箇所の中間地点に入れる。そして前か後かを切り分ける．これを再帰的に繰り返す。
補足：プリントデバッグパターンの応用版

名称：assert デバッグパターン
分類：１．デバッグ手法
現象：よく、メソッド、変数に想定外の値が入ってくることがある。
原因：メソッド作成者間との連携が悪い。
対策：ここでは，こうなっているハズ，ここでは，こう，と，頭の中の仮定を assert 文で埋め込んで行く。
補足：マルチスレッドだと、これがないとキツイですよね。

名称：ユニットテストデバッグパターン
分類：１．デバッグ手法
現象：バグの存在を確認したい。
対策：バグを再現するユニットテストを書く。また、あらかじめユニットテストを書いておくことでバグを発見しやすくする。
補足：すべてのコードにユニットテストを書いておくことでコードの信頼性が上がる。

名称：アルキメデス型デバッグパターン
分類：１．デバッグ手法
現象：長時間バグを発見することができない
原因：原因がわからない
対策：入浴中に理由を思いつく。
例外：歩きながらというパターンもある
補足：できれば街中に走り出した方が良い。

名称：ミニマライゼーション型デバッグパターン
分類：１．デバッグ手法
原因：配列の領域外書き込みとか、ダングリングポインタへの書き込みとかの、メモリ関係である場合が多い。
対策：事象を再現させる形で、不要なコードを削ぎ落としていく。

名称：長いす名探偵型デバッグパターン
分類：１．デバッグ手法
現象：遠隔地の運用環境などで「３日走らせると落ちる」ような場合に用いる。
対策：
*STEP1-とにかくログに情報を吐かせるようにして落ちるまで走らせ、ログをもらい、何が起きているかを推理する。
*STEP2-(*STEP1繰り返す)
補足：暖炉の前とかに座って行うのが良い。

名称：スタブデバッグパターン
分類：１．デバッグ手法
現象：ある程度、原因はつかめた。
対策：原因箇所の特定の為に，原因になっていそうなソースコードをすっぱりコメントアウト(又はスタブに取り替えて) してテストし，確かに其処が原因であることを確認する．

名称：バクさんのプレゼントパターン
分類：１．デバッグ手法
現象：バグに悩んだ後の睡眠中
対策：夢の中でデバッグすることがある。（ラッキー）
例外：その内容が駄目なこともある。
補足：再現性が低い

名称：ワザト虫デバッグパターン
分類：１．デバッグ手法
現象：バグの抽出個数を検出したい。
対策：わざとバグを入れて（もしくは残して）デバッグさせる。
個別のバグに対して行うデバッグではない。
少なくとも1個以上のバグがあることがわかっているので、
レビューなどでの無意識的な手抜きが防げる。
補足：（出典:「プログラミングの心理学」）
補足2：このソトウェアの古典に出てくる手法だけど実際に使った例を聞いたことがない。

名称：ctrace デバッグパターン(C)
分類：１．デバッグ手法
対策： C 言語コードなら，ctrace 通して，全ステートメントをプリントしながら走らせる．

名称：truss デバッグパターン(UNIX)
分類：１．デバッグ手法
対策： UNIX で truss を使って走らせる．システムコールに入るところでログが取れる．

名称：lint デバッグパターン(C)
分類：１．デバッグ手法
対策： C言語なら，まずは static な lint チェックをする．gcc なら -Wall する, -ecpp (Effective C++ rule check)する．

名称：メモリ関係デバッグパターン(C/C++)
分類：１．デバッグ手法
現象： mallpc/newと、free/deleteの関係がうまくいかない。
原因：明瞭に1対１で対応されたmalloc/new、free/deleteを書いていない。
対策1： C/C++ なら，デバッグ用 malloc/new を使う．free/delete 後にポインタに 0 を代入する．
対策2：お金があるなら，purify を使う．

分類2 コードのバグ

名称：1hour パターン
現象：一時間以上バグの原因がわからず悩む。
分類：２．コードのバグ
原因1：言語に潜む深刻な問題の可能性がある。
原因2：サーバが立ち上がってないなどの、環境的な問題。
対策1：発生しているバグと同じことを悩んでいる人がいないか、FAQを調べよ。存在するのならば、メーリングリストの過去ログを調べるのが良。
対策2：ちょっと視野を広げて、前提条件としているサーバが起動してるか？などを確認してみよう。
補足：悩む前にFAQを調べること。FAQで解決できる問題であればアンチパターンに含まれてもおかしくはない。

名称：1day パターン
分類：２．コードのバグ
例：（いずれも原因3）
i, j の for ループで，j++ を i++ に間違えていた．
全角文字を使っていた。
COBOLのピリオドの位置が間違えていた。
実行されなければならないコードを assert してしまう(例 assert(o.create());)
現象：一日以上悩む。
原因1：データの寿命がやたら長いときにどこで何が起こったか捜索が困難。
対策1：リファクタリングをしてソースをきれいにしながらデバッグする。それ以前にそうならないようにする。
原因2：自分がタッチできないライブラリ等のバグ
対策2：ライブラリの直前のインターフェースまで正しい値が入っているかログを都って確認する。
原因3：単純なタイプミスやうち間違いによるくだらないミス
対策3：恥ずかしくとも他人にちょっとだけ見てもらうと気がつきやすい。とくに頼もうとして声をかけた瞬間。

名称：コンパイラ君頼むよパターン
分類：２．コードのバグ
例：
○case ラベルの default: の綴り間違い．(C/C++/Java)
○if (bRet = TRUE) の比較間違い(C/C++)
○dowhileのミス(C/C++)
   do {
      ;
    } while (condition);
と書くべきところを、不注意で
    {
      ;
    } while (condition);
と書いてしまう
○単に member 変数の更新をしているつもりがlocal 変数の宣言と初期化になっている。
特に、大丈夫なはずの refactoring でおかしくなり、悩むケースが多い。(C/C++/Java)
   class A {
        private int _size;
        resize(int newSize) {
             int _size = newSize;
          // ^^^ この "int" が余計。
        }
    }
○for文のミス(C/C++/Java)
for(i=0;i<10;i++);
{
...
}
*注：for文末尾の「；」で空ループになってしまい、｛～｝間は一回しか実行されない
現象：アルゴリズム的にどう考えても正しいし、システムの変なところいじってるわけじゃないから、バグるわけはない。
原因：本当は文法的にコンパイラはじいて欲しいエラーを、コンパイラが正しいと認識してしまう。
対策：仕様です。

名称：2回目から動きますパターン
分類：２．コードのバグ
現象：起動時に必ず、エラーが出るがその後は、正常に動く。
原因：一回目は、変数の初期値にゴミが入っているが、2回目から、ちゃんとした値が入って、うまく動いてしまう。変数の初期化忘れ。
対策：変数の初期化しましょう。

名称：ijk パターン
別名： nmlパターン（use COBOLer only）
分類：２．コードのバグ
例： i, j の for ループで，j++ を i++ に間違えていた．
現象：無限ループになり処理が終わらない、または、初期化が中途半端に終わっている。
原因：ループカウンタ変数にiやjやkを使ってしまう。
対策：ループカウンタ変数とはいえ、意味のある変数名を使う。
(というCode Conventionを作成しておく)

名称：似非再帰呼び出しパターン(VB)
分類：２．コードのバグ
現象：再帰呼び出しのプログラムなのに、まったく動作しない。
原因：クラスモジュールの中で
　　　　Public Function method() As String
　　　　　...
　　　　 method = method
　　　　End Function
　　　　と引数なしのメソッドを呼んでしまう。
対策： method = Me.method　とMeキーワードをつけて明示する。

名称：改行コード問題パターン(Windows and その他文字コード環境)
分類：２．コードのバグ
現象
　１：Windows上のgcc(cygwin)、VC++ではコンパイルできるが、
　　　他の環境(FreeBSD&BeOS)では複数行のマクロでエラーがでる。
　２：同じデータファイルを読み込ませても、環境によって挙動が変わる。
　３：automakeで作成されるmakeファイルがおかしい。
原因：改行コードが￥ｎの環境で￥r￥nのソースコード、データファイル、makefile.amなどのテキストファイルを処理しようとした。
対策：改行コードを直す。

名称：無意味なキャッチパターン（Java)
分類：２．コードのバグ
現象：共通LibでExceptionが発生する。スタックをおっかけると、以下のようなソースと遭遇する。
try
{

}
catch ( XXXXException e )
{
System.out.println("Error occured");
throw e;
}
原因：デバッグの為にこのようなロジックになっていると思われる。そして、おそらくこれをコードした人はANSI-C大好き人間だろう。
原因： e.toString()とか、e.printStackTrace()とか知ってます？
対策：速やかにこのCatchを削除するよう要請しよう。さもないと、StackTraceに無意味な物が突っ込まれる。
補足：これとAllExceptionCatchパターンがタッグを組んでいたら、今すぐ荷物を纏めて帰ったほうがいい。

名称：AllExceptionCatch パターン
分類：２．コードのバグ
現象：話を聞くと例外の特定が出来ずにズルズルテストが延びている。
原因：ソースを眺めると、全てExceptionでキャッチしており、何の例外が起きているのかさっぱり分からない。
原因2：さらによく見ると、stackTraceが下層のcatchから投げられたりする。
原因3：さらに、このExceptionをそのまま再送してたりする。
対策：これを書いたコーダに1時間ほど正座させてこってり説教しよう。
対策2：「これが会社の方針だ！」と逆切れしたら、受け元にチクリ入れてあげましょう。
例外:たまーにThrowableでキャッチしてたり・・・
補足：自分がやっていたらコッソリ修正しましょう。説教を食らわないようにするために。
補足：自分のプログラム内で処理できるのであればExceptionキャッチが有用である可能性もある。たとえば、JDBCブリッジで、呼び出し元は「接続できたかどうかのみを知りたい」というのであれば、ドライバマネージャが投げる3つの例外は意味をなさない。これらはExceptionでキャッチしてやり、「CreateFailurException」でも投げてやるのがいいだろう。そのときに、各種例外のtoString()のデータを埋め込んでやるのを忘れずに。

名称：オブジェクト思考アンチパターン
分類：２．コードのバグ
例：継承元のメソッドをオーバーライドして、継承元のメソッドを呼び出さず自分でメソッドを定義しなおしてたりする
現象：クラスのオーバーライドの仕方が間違っているとか、Interfaceの使い方が間違っている
原因：オブジェクト指向の考え方が違う。
対策： Java入門とかC++入門とか読むのはやめて、オブジェクト指向とは何かというもっと哲学的な本を読みましょう。または、JavaAPIなどがどういう風に実装されているのか少し頭の中にはりめぐらせてみましょう。きっとあなたの考えていることとは違います。
補足：参照オブジェクト嗜好アンチパターン、オブジェクト試行パターン、オブジェクト施工アンチパターン

名称：オブジェクト嗜好アンチパターン
分類：２．コードのバグ
現象：オブジェクト指向に乗っ取ったつくりをしました！と言っている割には、クラス間の結合が強すぎて、部品単位で使うことが絶望的。
原因：ただの新しい物好き
対策： Java入門とかC++入門とか読むのはやめて、オブジェクト指向とは何かというもっと哲学的な本を読みましょう。または、JavaAPIなどがどういう風に実装されているのか少し頭の中にはりめぐらせてみましょう。きっとあなたの考えていることとは違います。
補足：参照オブジェクト思考アンチパターン、オブジェクト試行パターン、オブジェクト施工アンチパターン

名称：オブジェクト試行パターン
分類：２．コードのバグ
現象：勉強し始めで、オブジェクト指向と、関数群の中途半端な状態でしっくりこない。
CからJavaに転向した人間に良く見られる。main関数以下の関数関係が、Cの其れとほぼ同じである。ちなみに、クラスはCで言うところのstructのようにしか使われない。
原因：経験不足
対策：勉強中なので仕方ないでしょう。しかし勉強を怠ると、オブジェクト思考アンチパターン、オブジェクト嗜好アンチパターンにおちいるので注意。
補足：参照オブジェクト思考アンチパターン、オブジェクト嗜好アンチパターン、オブジェクト施工アンチパターン

名称：オブジェクト施工アンチパターン
現象：ソースを眺めていると、なぜそんな事をする必要があるのかまったく分からないロジックにぶちあたる
原因１：新しく知った技術をとにかく使って見たい。
原因２：自分の技術に酔っている
対策１： SEとは何をするべき職業なのか、深く考え直す。
対策２：レビューでボコボコにたたいて、目を覚まさせる
補足：デザインパターンかじった人がやたらパターンを組み込むのも、このパターン。
補足：参照オブジェクト思考アンチパターン、オブジェクト嗜好アンチパターン、オブジェクト試行パターン

名称：効率を上げましょうアンチパターン
分類：２．コードのバグ
現象：メモリ効率やCPU効率を上げるために、設計を複雑にする。
当然、作業効率は大幅に落ちて保守性も下がり、システムは割高になる。
原因：ソフト開発のコストと、ソフトウェアの資源の効率の優先順位の計算を全く行っていない。
対策：まずすっきりとした設計をしましょう。そして、もしパフォーマンスが足りないなら、何が一番パフォーマンス低下の原因になっているかつかみましょう。すっきりした設計ならつかみやすいはずです。そしてそこを対策するようにすれば、最低限のコストでパフォーマンスのよいソフトが作れます。
補足1：複雑になりすぎて余計メモリやCPU時間を食う事に・・・
もちろん、設計者は気がつく事は永遠に無い。
補足2：昔の資源の少ないマシンをいじっていた人間はおちいりやすい。

名称：宙ぶらりん複合パターン
別名： Dangling Composite パターン
分類：２．コードのバグ
現象：再帰的に定義されたデータ型を使用するコードがヌル・ポインター例外を通知する。
原因：データ型を再帰的に定義する場合に、個々の基底ケースにそれぞれ独自のクラスが与えられていない。その代わりに、各種の複合データ型にヌル・ポインターが挿入されている。その場合に、クライアント・コードによる基底ケースの処理が一貫していないと、この症状が起こる。
対策：基底ケースの表現が一貫しているかどうかを確認する。基底ケースにそれぞれ独自のクラスを与える。
補足：宙ぶらりん複合バグパターンからの丸々引用です。

名称：ヌル・フラグアンチパターン
分類：２．コードのバグ
現象：例外条件を表すためにヌル・ポインターを使用しているコード・ブロックが NullPointerException を通知する。
原因：メソッドを呼び出した側のコードで、戻り値がヌル・ポインターであるケースをチェックしていない。
対策：例外状況を通知するために例外を発生させる。
補足：ヌル・フラグバグパターンからの丸々引用です。

名称：二段たどりパターン
分類：２．コードのバグ
現象：データ構造を再帰的にたどるプログラムからクラス・キャスト例外が発生する。
原因：コード内のどこかで、1回のメソッド呼び出しについて2レベル下へたどることが行われており、その2回目の「たどり」で処理が正しく行われていない。
対策：キャストを実施しているコードを、クラスごとに別々のメソッドとして抜き出す。あるいは、不変条件を調べて、キャストが正しく実施されるようにする。
補足：二段たどりバグパターンからの丸々引用です

名称：うそつきビューパターン
分類：２．コードのバグ
現象： GUIプログラムが、一連のテストにパスしたにもかかわらず、それらのテストで除外されたはずの振る舞いを示す。
原因：テストが、ビューではなくモデルについて検査を行っている。
対策：ビューについて検査を行う。
補足：うそつきビューバグパターンからの丸々引用です

名称：破壊工作データパターン
分類：２．コードのバグ
現象：複雑な入力データを保管および操作するプログラムが、問題の原因とならない他のタスクと類似したタスクを実行しているときに、思いがけなくクラッシュする。
原因：内部データの一部が、構文的にまたは意味的に破壊されている。
対策：入力データについて、できるだけ多くの完全性検査をできるだけ早く実施する。すでに破壊されてしまった永続データは使わずに、完全性を検査する。
補足：破壊工作データバグパターンからの丸々引用です

名称：破綻したディスパッチパターン
分類：２．コードのバグ
現象：別のメソッドをオーバーロードした直後に、変更を加えていないコードが突然停止します。
原因：オーバーロードによって、変更されていないメソッドが、目的とするメソッドとは別のメソッドを呼び出すことが原因です。
対策：明示的アップ・キャスト (upcast) を実行するか、あるいは、さまざまなクラスで使用するメソッドの見なおしを行います。
補足：破綻したディスパッチバグパターンからの丸々引用です

<New>名称：切り分けミスアンチパターン
分類：２．コードのバグ
現象：Servletを用いたサーバ側の開発なのに、JSPしかない。よく見るとJSPからコミットしたり、メールを送信してたりする。
原因：1・Javaの書き方だけ知っているCerしかいない。もちろんJSPはCチックにincludeされている。
　　　2・packageがぜんぜん使われていない。ClassPathのRootにダーーーーーっとclassファイルが・・・
例：1・JSPファイルに一つだけのメソッド[sendMail( from , to , subject , body )]だけが・・・(include専門)
対策：1・基本的に諦める。JSPには一切タッチしないようにする。その際に「Javaで構造化プログラムはできませんので」とか「オブジェクト指向じゃないと、体が拒絶反応を起こします。」等と言っておこう。
　　　2・そのクラスは捨てて新しく一から同じクラスを作ったほうが早い。なぜならそのクラスは絶対バグ若しくは不具合を含んでいるからだ。
補足：1・ヘッダーファイルすらないので、チェイスするのは不可能。しかもコメントも無いと来たもんだ！！！！！！！
補足：2・このような状況はしばしば存在するので、一から作ったクラスは家に持って帰えろう。いつの日か再び使うときが来るだろう。（ただし契約違反になるかも）

分類3 プログラマのバグ

名称：OverLook アンチパターン
別名：自意識過剰アンチパターン
分類：３．プログラマのバグ
現象：バグはない
原因1：テストを行っていない。
対策1：とりあえず、プログラムを他人に叩いてもらえ。できればSの気がある人に
原因2：再現性が低いバグなのでなかったことにした。
対策2：穴があくほどソースとFAQを眺めて、駄目だったら神に祈る。

名称：PhenomenonDebug アンチパターン
別名：対処療法アンチパターン、もぐら叩きアンチパターン
例：「ここの関数に来る値がときどき一文字欠けているんだ。欠けている文字が何か推測するプログラムを書くのに苦労したよ。」
分類：３．プログラマのバグ
現象：プログラムの現象に対する修正を行う。
原因：現象はなぜ起こったのかという原因を修正せずに、その現象に対する修正を行ってしまう。
対策：原因に対する修正を行う。ある関数に必ず2倍の値が入ってくるのならば、入ってきた値を1/2にするのではなく、2倍の値が入ってくる原因を修正する。
例外：原因を自分が触れることができない場合はその限りではない。が、後の人のために必ずコメントを入れておかねばならない。
補足：このアンチパターンを行うプログラマは転職を真剣に考えるべき。というか消えてください。

名称：SameRepair アンチパターン
別名： COBOLerパターン、不良タイルパターン
分類：３．プログラマのバグ
例：ベテラン「これらのプログラムのAという部分を全部Bという風に変換するんだ。簡単でしょ？」
現象：同じ修正をあちこちで行う。
原因：プログラミングに対する技術の欠如
対策：せめて、同じ処理は一つの関数にまとめるくらいはしましょう。プロならば、オブジェクト指向の一つや二つ勉強しておきましょう。といってもいきなりは無理でしょうから、一つの関数は24行以内だけは厳守するようにしてみましょう。そうすれば自然に同じ処理は一つにまとまるはずです。
補足：もうすでにそういうプログラムの場合は、新しい修正部分は新しい関数を作ってそこを呼び出すようにしましょう。そうすれば次の変更のときに楽になります。

名称：比較パターン
分類：３．プログラマのバグ
現象：変更前には存在しなかったバグが発生した。
原因：変更したこと
対策：バグが出る前のソースコードとひたすら見比べる．
補足：大抵の場合、泣きながら

名称：休憩パターン
別名：思い込みパターン
分類：３．プログラマのバグ
現象：バグの原因がどうしても見付けられない．
原因：ソースコードに対する先入観によりバグの原因に気付くことが出来ない．
対策：休憩して気分を変える．全然関係ない他のことをやる．いっそのこと帰宅する．

名称：迫り来る納期アンチパターン
分類：３．プログラマのバグ
現象：バグはないはずだ．
原因：納期が迫っていてテストをやる暇がない．
対策：無茶だ．仕様を削ってもらうか納期を延ばしてもらうよう泣いて頼んでデバッグを優先しなさい．

名称：悪いのは俺じゃないパターン
分類：３．プログラマのバグ
現象：適切にバグの原因を見付けられない．
原因1：直ぐにライブラリや OS 等のバグじゃないかと疑う．
対策1：九割方あなたの書いたコードが原因です．先ず自分のコードを疑いなさい．
原因2：自分のコードだけを疑う。
対策2：英語を嫌わずに BugParade を検索しましょう。
補足：耳が痛い。特にMS製品に無力アンチパターンを受け続けるととにかくマイクロソフトが悪いことにしておこうアンチパターンに陥ることになる。

名称：さっきまで動いていたのにアンチパターン
分類：３．プログラマのバグ
現象：頭がパニックしている．
原因：同じことをしたら同じ現象となるはずなのに，何かが違うハズ．
対策：メモリのバグも多いが，そうでなければ何らかの「入力」か「環境」が違うハズ．そこを手がかりにしよう．

名称：動いているんだから触るなパターン
分類：３．プログラマのバグ
現象：プログラムが正常に動いている。
原因：これから、変更を行おうとしている。
対策：回帰テストもないのに，動いているコードをわざわざ触ってはいけない．
例外：リファクタリング時はその限りではない。

名称：狭すぎるスコープパターン
分類：３．プログラマのバグ
例：メール送信プログラムを書いていたら本文にTOと書くと、なぜか>TOになってしまう。原因はメールを転送してたサーバーのsendmailが古かった、、等。
現象：適切にバグの原因を見つけられない。
原因：プログラムを直している途中は自分のプログラムばっかり悪いと思ってしまい、他に原因が有るかもしれないという思考がぶっ飛ぶ。
対策：プログラムの動作する課程をもう一度整理しましょう。
補足：悪いのは俺じゃないアンチパターンの逆

名称：恥ずかしくて人に言えないアンチパターン
分類：３．プログラマのバグ
現象：バグがでてもなぜかその人が原因を言えない。
原因：バグと疑って何時間も格闘した結果、実はケーブルが抜けてた、ＤＢが上がってなかった。など。
対策：狭すぎるスコープデバッグパターンと同じ、起こってしまった場合は、開き直って報告する。人間に欠陥は付き物であると納得？する。

名称：とにかくマイクロソフトが悪いことにしておこうアンチパターン
分類：３．プログラマのバグ
現象：１日やってもバグが見つかれない時、「windowsのバグだ、MFCのバグだ」と決め付けてバグから逃れる行動。
原因： windowsはそんなものだという風潮。そして、それに乗ると幸せになるときがある。
対策：プログラムの動作する課程をもう一度整理しましょう
補足：悪いのは俺じゃないアンチパターンのより限定されたパターン。某MS製品で無力アンチパターンを食らいまくると、こうなる。

名称：もう帰りたい アンチパターン
分類：３．プログラマのバグ
現象：対症療法でバグを隠蔽する。
原因： (疲れたから/金曜日だから/家内の誕生日だから)きちんと原因を究明している時間がない。
対策：自分の状況をスケジュール管理者に伝えて、バグを隠蔽しない。
補足：裏対策：(元気なときに/月曜日に/次の日に)再度自分が対処できるように、隠蔽したバグが顕在化できるようにしておく。（←おい）

名称：なにも変えてないのに… アンチパターン
別名：小人さんのいたずらアンチパターン
分類：３．プログラマのバグ
現象：デバッグしていくうちにどんどん悪い方向に行く。状況を聞くと
「何も変更してないのにここも動かなくなったんです」と報告する。
原因：自分は悪くないと思いたい深層心理に負けている。一度に２箇所以上の変更を行っている。
対策：論理的思考法のトレーニングを行う。どうしてもそれが出来ない人を使わざるを得ないときは、バグ原因の追及手順まで指示する。
例外：小人さんが助けてくれることもある。しかし小人さんの陰謀に注意しよう（ジョーク）
補足：気持ちはわかるんですがね… ^^;

名称：僕のマシンでは再現しませんアンチパターン
分類：３．プログラマのバグ
現象：他のマシンでは落ちるのに、自分のマシンではちゃんと動く。
「OS入れ替えたら？変なソフト入っているんじゃないの？」と環境の違いを疑う。
原因：だって、僕のマシンで落ちないもん。たまたま動いていることに気づいていない。
対策：ちゃんとプログラム見直しましょう。変数の初期化を忘れているケースが多いです。
例外：環境の違いによる場合もあります。例えば、IDEが入っている環境と入っていない環境とか。

名称：割れた窓アンチパターン
分類：３．プログラマのバグ
現象：汚いプログラムをやっつけ仕事で変更してさらに汚くする。
1枚の壊れた窓があると、その周囲の窓も壊されやすい。
対策：だからリファクタリングが必要。
補足：（出典:「達人プログラマー」）

名称：InstallFaild パターン
分類：３．プログラマのバグ
現象：デバグも終わり、実際の納品状態でインストールして動かそうとすると、なぜか動かない。もう一度テストをやり直せなど上司に言われ、顧客にも圧力がかけられる。
原因：よく見たらレジストリに登録するのを忘れていた。MFCを入れ忘れた。
対策：環境について勉強しましょう。
補足： COM関係でよく見られます。例外処理は適切に。

名称：任せたパターン
分類：３．プログラマのバグ
現象：質問されてきたことが良くわからない
原因：知識不足。しかし誰にでも知らないことはある。
対策：「任せた」は「おれは知らん」の丁寧語
補足：だからといって、任せた相手に責任をなすりつけるのはもってのほか。

名称：俺はプログラマアンチパターン
分類：３．プログラマのバグ
現象：自分は一人前のプログラマだと思っている。
原因：自分の技量に満足し、知識の吸収をやめる。ないしは吸収量を極めて減らす。
Ver1.COBLer
一応プログラムが組めて、SQLくらいは知っている。
別に言語はCOBOLに限ったわけではないが、
この人種はテストもろくに出来ず、存在するだけで迷惑な存在。
ソースはどんな言語でもスパゲティコード。
年をとっていると、地位がついている分なお厄介。若い奴はVBer。
Ver2.Cer
構造化は知っている。ちょっと難しいアルゴリズムも小技を用いてこなせる。
別に言語はCに限ったわけではないが、ちょっとしたピンチも小技で回避する。
ソースは最初はきれいだが、気がつくとコメントも少なく、理解しづらいコード。
しかもSameRepair アンチパターンを使うことが多い。
下手にプログラムが作れる分、この人種を成長させるのは非常にやっかい。
大体言語を一つ、多くても３つしか知らず、言語のTPOによる使い分けというのを知らないため、
どの言語が優れているかという無意味な論争に参加しがちである。
Ver3.Javer
COBLer、Cerを継承したクラス。
言語はJava、C++のオブジェクト指向言語を用いているが、
まったくオブジェクト指向していない。
継承などをただのプログラムテクニックの一つとしてしか見ていない。
本人はオブジェクト指向しているつもりである。
総評
大体においてプログラマ30歳定年説や、プログラマ5年間挫折説を信じている。
そりゃ、ある程度勉強すれば、後は何もしなくても仕事できるのなら、安い人材を投入した方がコストがよいのだから当然である。バイトを雇うのと一緒だ。
対策：初心忘れるべからず。少し広い視野でものを見れば自分がいかに技量の低いプログラマかはすぐわかる。
補足1：ただし、一部の人間を除いて永久に一人前になったと思えることはないだろう。要するに上を見る視点をもっているかいないかの差。
補足2：２ｃｈのプログラマ板あたりにいっぱい転がっている。

名称：英語が読めないパターン
分類：３．プログラマのバグ
現象：資料が英語だ！！
原因：英語が読めない。
対策：翻訳サイトなどを使って頑張って読む。
補足1：ついでに原文と比較しながら少しでも英語になれるようにしましょう。
補足2：偉そうなこと言ってますが、筆者は英語が読めません。

名称：英語はわかりませんアンチパターン
分類：３．プログラマのバグ
例：
MLにおいて
「そのURLは英語なのでわかりません。もっとわかりやすい資料を教えてください。」
現象：資料が英語なので、いきなり投げ出す。
原因：英語が読めない。
対策1：（悪い対策）部下に「おい、これ訳せ」
対策2：悔い改め、せめて自分が英語が読めないパターンにいるようにしましょう。

<New>名称：情報無しアンチパターン
分類：３．プログラマのバグ
現象：1・資料を請求すると「資料は一つも無い」と言われる。
　　　2・「じゃあ作ってください」と言うと「そんな暇は無い」と言われる
原因：1・時間が足らない。
　　　2・PLが無能で、資料の重要性を解ってない。
対策：1・納期を延ばすようにしましょう。もしくは突貫工事で作るだけ作って、そのProjectから逃げましょう。
　　　2・資料の重要性を真剣に語るとともに「資料が無いとできません」と言って、逃げ切りましょう。資料を用意してないほうがおかしいのです。
補足：　コレは現在経験中です。DBのカラムの意味やデータ区分もとーぜんなし。ソースはコメントがほとんどなし。（情報提供者lemon氏）

<New>名称：NonRefactaring アンチパターン
例：DBへのConnectionを管理するクラスがある。
static Connection db;
static Statement[] select = new Statement[64];
と宣言されている・・・一つのConnectionにStatementが64個もあるんすね。しかもRollbackとCommitは出来ないんですね。
現象：どー考えても納得いかない＆明らかに意味不明なロジックが存在する。PLに報告すると「それしか方法が無い」と言われる。もちろん他に方法はある。
原因：PLが無能。知識が無い。とにかく動けばいいと言う頭で、将来性とか汎用性とか仕様変更に耐えうる物を作る　なーんて事は綺麗サッパリ抜けている。
対策：そんなクラスは捨ててしまえ！個人でクラスをこっそり作成して、自分だけそのクラスを使おう。問題になったら、「フフン」と笑いながら、クラスを提示してやれ。

分類4 人間関係のバグ

名称：担当が替わりました・・・彼は退職しましたアンチパターン
分類：４．人間関係のバグ
現象：なかなかバグ対策版が来ないので、問い合わせをすると
「その人は退職しました」「担当が替わりました」言われてしまう。
原因：無茶な納期要求に耐え切れなくなった担当者が逃げてしまう。
対策：適正な工数と納期を割り当てること。

名称：だから俺が悪いんじゃないんだってば (泣) アンチパターン
分類：４．人間関係のバグ
現象：適切にバグの原因を見付けられない．
原因：コードを書いた奴がろくに引き継ぎもせずに退社してしまった．おまけに何なんだ．このスパゲッティコードは!
対策：なんとか連絡を付けて，せめてきちんと引継ぎをしてもらいましょう．

名称：それはバグではありませんアンチパターン
分類：４．人間関係のバグ
例：「顧客の要求には入っていません。」
「テスト仕様書には載っていません。」
などといいはる。
現象：明らかにバグと思われるのに担当が直そうとしない。
原因：責任転嫁、杓子定規
対策：ドキュメントを頻繁に更新する。
例外：逆に、最初からドキュメントが無いほうがいいかも。

名称：ごめんなさい気付きませんでしたアンチパターン
分類：４．人間関係のバグ
現象：新しい担当者が細かいミスを連発する
原因：引き継ぎがうまくいっていない。表面的なことしか知らない。なんでもできる人、特に１人でいくつも仕事を兼任しているような人の次の代で発生しやすい。
対策：仕事の責任分担をはっきりさせる。自分の責任範囲を他の人に知ってもらうのも重要。

名称：そこはどうにでもなるパターン
分類：４．人間関係のバグ
現象：役割分担を決めても、あまりそれが有効に働いていない
原因：マネージャに全体像が見えていない。細かいところばかり見てしまっている。
対策：チームの構成員の技能に合った、適切な責任分担を行う。細かい部分ばっかり気にするマネージャには「そこはどうにでもなる（他の人にまかせても大丈夫）」というツッコミが有効。

名称：それは他の人に聞いてアンチパターン
分類：４．人間関係のバグ
現象：権限、情報が分散してしまって組織運営がうまくいかない
原因：組織構成、役割分担に問題
対策：役職間の責任と関係を明らかにし、リファクタリングする。
　　　HRC(Human-Responsibility-Collaboration)カードを書いてみる。
　　　組織をUMLで書いてみる。

名称：そんなの今言われても困るアンチパターン
分類：４．人間関係のバグ
現象：変化に対応できない。アドバイスを受け入れない。
原因：ウォーターフォール型思考回路。
対策： embrace changeの意識を常に持とう。

名称：項目が足らないアンチパターン
分類：４．人間関係のバグ
現象：およそ流れの中で分岐するところを全て洗い出してテスト項目を作ったが、客に「項目が足らない！もくひょうはXXXX件だ！」と膨大な量を突きつけられる。
原因：よくよく聞いてみると、5stepに一件テストという方法でその目標を出していたりする。
対策1：「これ以上項目を増やすのは可能ですが、そのテストはまったく意味の無いものになりますよ」と言ってみる。
対策2：「しかも、テスト項目が増えるとこれだけ時間がかかります。経費や期間をさらにいただく事になりますがよろしいですか？」などといってみる。
対策3：ボタンをひとつ押せばテストが終わるようなものをテスト項目に上げる。相手はどうせ数字しか見ていない。
補足:客は金や時間のかかることをいやがる。客は子供だと思え。数字さえ提示すれば安心する。その数字のどれほどの意味があるか考える頭は持ち合わせていない。

名称：バグが足らないアンチパターン
分類：４．人間関係のバグ
現象：テストが終わりバグ報告をすると「バグが少なすぎる！テストが不十分だ！」と追加テストを命じられる。
原因：テスト5件につき1件のバグがある。これは過去の統計から出した信用できる数字だ！とか、客が言い出す。
対策：テスト項目レビュー表を突きつけ、客がこのテストでよいと認めた事を表に出す。
対策：バグを捏造する。
補足：そもそも、この過去の統計っていうのはCOBOLerの統計だったり・・・鬱。
補足：もちろん、このバグ指標件数には、コーダのスキルなんて物はまったく考慮の余地は無い。

名称：BlameFailure アンチパターン
分類：４．人間関係のバグ
現象：バグはいけない物だと思い込み、バグの責任を擦り付け合う。
例： Aというメソッドを使用するBがあり、Bに仕様変更が発生。Bを使用するCを起動したところ、Aで例外が発生。stackTraceに応じて、Aに対策を求めたところ「仕様です」と突っぱねられる。
原因：よくみると、Aを呼び出すBが-1すべきところをしてなかったりする。
対策:StackTraceの最下層ではなくその上位からデータの流れを整理する。
補足1： Bを作っているのがAの上位会社だったりするとさらに話がこじれたりする。

名称：自己蟲アンチパターン
分類：４．人間関係のバグ
現象：何か問題があればすぐ相手のせいにする人。あまつさえ責任をお客にまでなすりつける。
原因：「自己蟲」と呼ばれる人格バグです。
成長過程でそうなったのか、俺はプログラマアンチパターンで知識、知能が発展途上のまま止まったせいで、こうしないと会社にいられないのかは判断が難しい。
対策：権限があるなら、解雇、もしくは隔離。権限がないなら、そもそもその人にできるだけ責任をもたせないようにお飾りにして放っておく。リーダーがこの人物だと悲惨。実質新しいリーダーを作ってその人中心に動くようにしよう。リーダーはただの連絡委員にしておく。それでも肝心なことを連絡しなかったりするから困ったものだ。
補足：傾向として
・すぐに暴走する
・反応が返ってこず、だんまりする
ということが多いです。

名称：無駄な残業アンチパターン
分類：４．人間関係のバグ
現象：どー考えても残業の必要の無い時期に毎日2時間ほど残業している奴が居る
原因1：ちょこっとAdminでパソコンに入って履歴を見ると、エロ・出会い系の山
原因2：回りが皆残業しているので、帰りづらい。
対策1：ブラウザのホームに「遊ぶなら残業せずに納期前に仕事上げろゴルァ！」と書いたHTMLを指定しよう。
対策2：自分の仕事が終わっているなら、どうどうと帰れ。自分に割り振られた仕事が少ないなら割り振った上司の責任。自分が効率よく仕事を仕上げたなら、会社にいることこそ無駄に会社にコスト使わせる罪悪だ。
補足：どんなに忙しい時でも、ヒストリーは刻々と更新される

分類5 その他

名称：無力アンチパターン
分類：５．その他
現象：バグのある箇所が判っているのに直せない．対症療法で対処せざるを得ない．
原因：他の人 (又は他社：特にマイクロソフト) の作ったライブラリの方に原因があるのだが，力が及ばず対処してもらえない．又は，バグと認めてくれず，「仕様です」と言い張っている．
対策：力のある人 (作成者の上司等) に頼んで圧力を掛けてもらう．無理なら，そのライブラリとはなるべく早いうちに手を切る．

名称：こまめにセーブしろパターン
分類：５．その他
現象：ソフトがハングアップして今までの作業がパァ！！
原因：ハングアップするソフト、ないしはOS。
対策：こまめにセーブ。一区切りついたらすぐセーブ。癖になるまで意識してやろう。
例外：セーブするときにハングアップすることもある。しかも、データ破損というサービス付きで。
補足：主に某MS製品に多い。

名称：CD1枚アンチパターン
分類：５．その他（会社のバグ）
現象： WindowsNTのCDが一枚しかないのに、全てのマシンにNTがインストールされてるぞ？？（実話）
原因：管理体制がなってない、社員全体のモラルの低さ。
対策：思い切ってMSにチクレ。ないしはばれる前に頭数を揃えておけ。

名称：汚染された窓パターン
分類：５．その他（コンピュータ使用者のバグ）
現象：デスクトップにファイル貼りまくって汚い
原因：デスクトップにベタベタ貼ると言う事は、各種ファイルを的確に整理して管理が出来ていないという事。これは管理能力が低い可能性が高い。
対策：一時ファイルなどはtempなどのフォルダを作って、そこで管理しましょう。
補足：筆者はデスクトップにべたべた張りまくってるのですが、限界超えたら整理するけどね。デスクトップの汚さは部屋の汚さと比例するかもしれない。

名称：夢の島アンチパターン
分類：５．その他（コンピュータ使用者のバグ）
現象：ゴミ箱に大切なファイルがあるかもしれないので空に出来ない
原因：後に必要になる可能性があるファイルまで捨てているので、ゴミ箱を永久に空に出来ない。まさに行き場を無くした夢の島。
対策：必要になるかもしれないけどいらないファイルは、それ専用のフォルダを作って、そこに捨てておきましょう。
補足：汚染された窓パターンも併発している可能性あり。

戻る
モノーキ

SEO		[PR] 爆速!無料ブログ無料ホームページ開設無料ライブ放送