私家版マーフィーの法則 - rabbit2goのブログ

バグのないソフトは無い。
開発工程は必ず遅れる。
工程通りに進行している開発は、何か重要な項目を忘れている。
仕様書通りに作られたソフトには問題がある。
仕様を追加すればするほど、工程は指数関数的に遅れる。
テスト項目に入っている不具合を「バグ」と呼び、テスト項目に入っていない不具合を「仕様」と呼ぶ。
開発者のマシンでは不具合が再現しない。
重大な不具合に関するテストは、チェック項目に入っていない。
開発に必要な情報は仕様書に記載されていない。
昨日書いたばかりのソースコードは既に理解不可能である。
開発者はテスターによる完璧なチェックを期待し、テスターは開発者による完璧なソフトを期待する。
優秀な開発者は必要な仕様と不必要な仕様を取捨選択する。
深刻なバグほど直しやすく、簡単なバグほど直しにくい。
優れたソフトと出来の悪いソフトの違いは、バグの有無ではなくバグをいかにうまく隠すかという点にある。
何気なく変更した1行が命取りになる。
不具合のある箇所に限って、ソースにコメントが書かれていない。
自分のTipsは他の人の役には立たないが、何気なくやっている工夫が他人に取ってオドロキのテクニックである。
工程通りに作られたソフトはメンテナンス不可能なシロモノである。
メンテナンスがやっかいなソースに限って不具合が多い。
読みにくいソースのソフトに限って不具合が多い。
コメントのないソフトに限って不具合が多い。
グローバル変数を多用するソフトに限って不具合が多い。
ドキュメントが整備されていないソフトに限って不具合が多い。
不具合の多いソフトに限って、メンテナンス性が悪く、ソースが読みにくく、コメントが無く、グローバル変数を多用し、ドキュメントが存在しない。
不具合の多いソフトを作った本人に限って、ソフト開発上の問題が分かっていない。
過去のテクニックにこだわる開発者は、新しい技術を習得できない。
二流プログラマは力仕事に走り、一流プログラマは頭脳プレイに走る。
素人プログラマはユーザーインターフェースにこだわり、優れたプログラマは処理の根本動作にこだわる。
前近代的なプログラマは3年前の知識でプログラミングを行い、進歩的なプログラマは3年先を見越した知識でプログラミングを行う。
設計が優れたソフトのソースは読みやすく、設計が悪いソフトのソースは解読が不可能である。
優れたソフトの修正は容易であるが、出来の悪いソフトの修正は泥沼作業になる。
ベテランプログラマはエラーが起こった場合の事を考え、素人プログラマは処理がうまく動作した時の事を考える。
プロは不具合を前提とした工程を組み立てるが、アマチュアは不具合が皆無であることを前提に工程を作る。
出来の悪いソースコードは、それ自身が暗号化されており作者以外には誰も理解できない。
1つの不具合を修正すると、新たな3つの不具合が発生する。
優れたソースコードの再利用は容易であるが、出来の悪いソースコードは再利用は困難である。
ソースコードの読みやすさとソフトの出来は正比例する。
スパゲッティコードを吐き出す開発者は、構造化プログラミングもオブジェクト指向も知らず、その必要性も理解できない。
小手先のテクニックに走るプログラマほど、全体を見通した最適化処理を組み立てられない。
優れたソースコードは読めば読むほど勉強になるが、出来の悪いソースコードは読めば読むほどドツボにはまる。
良くできたソースコードには必要なことしか記載されていないが、出来の悪いソースコードには余計なことしか書かれていない。
仕様変更を数多く言い出す人ほど、仕様の意味が分かっていない。
細かい不具合を指摘するテスターに限って、本質的な問題を指摘できない。
他人が作ったソフトの不具合はすぐに指摘できるが、自分のソフトの不具合にはなかなか気がつかない。
単純なバグはソフトリリース後、30秒で発見される。
重大なバグはテストの最終段階で発見される。
最も深刻なバグはソフトのリリース後に発見される。
プログラマは他人の作ったソフトを信用しない。