プログラミング・プロジェクトマネジメントに関する著名な原理・原則の一覧
プログラミングやエンジニアリング、プロジェクトマネジメントに関する、著名な原理・原則をまとめる。
個人の思い付きで掲げた標語ではなく、世間的に知られているベストプラクティスなら、色んな人に従ってもらいやすいかな？という考え。
プログラミング関連
- デルメルの法則 : 最小知識の原則 : Principle of Least Knowledge
- 意味 : あるオブジェクトが自分以外の構造やプロパティに対して持っている「仮定」を最小限にすべき、という考え
- 例示 : 自分以外のクラスのメンバフィールド
nameを直接触っているのは、「そのクラスにnameプロパティが存在する」という仮定に依存している。コレをgetName()経由にしておけば、対象クラスにnameプロパティがあるかどうか、という構造の影響を受けなくなる - 出自 : 1987年の末にかけてノースイースタン大学で作成された
- 参考 : Wikipedia - デルメルの法則
- 驚き最小の法則 : Principle of least astonishment : Rule of least surprise
- 意味 : UI や設計において、あるインターフェースと別のインターフェースとが矛盾していたりする時、ユーザやプログラマが自然に思える動作を選択すべき、という考え方
- 例示 : 相手の驚きが少ない行動を選ぼう、ということ
- 出自 : (誰が最初に提唱したのかは不明)
- 参考 : Wikipedia - 驚き最小の原則
- ムーアの法則 : Moore's law
- 意味 : 集積回路上のトランジスタ数は「18ヶ月 (=1.5年) ごとに倍になる」
- 例示 : 平易に派生して、「コンピュータの性能は18ヶ月で倍になる」などと言われたりする
- 出自 : 米インテル社の創業者の Gordon E. Moore が1965年に自らの論文上に示したのが最初
- 参考 : Wikipedia - ムーアの法則
- ヴィルトの法則 : Wirth's law
- 意味 : ソフトウェアは、ハードウェアが高速化するより急速に低速化する
- 例示 : ハードウェアの進歩に応じてソフトウェアは富豪的プログラミングになり、フレームワーク等も増えてくるから、結果的にソフトウェアの動作速度が速く感じない、ということ
- 出自 : Niklaus Wirth による1995年に発表された記事「A Plea for Lean Software」における議論に由来
- 参考 : Wikipedia - ヴィルトの法則
- コンウェイの法則 : Conway's law
- 意味 : システムを設計する組織は、自分たちの組織のコミュニケーション構造をそっくりそのままコピーした設計を生み出してしまう
- 例示 : 組織構造がバグの再現率に寄与する。組織自体のコミュニケーションが大事
- 出自 : コンピュータ科学者、プログラマである Melvin Conway が1967年に提唱
- 参考 :
- ボーイスカウト原則
- 意味 : モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする
- 例示 : ボーイスカウトが訪れた山を綺麗にして帰ることから。改修のために触ったコードは、既存のコードを綺麗にする
- 現場によっては「関係ないコードを触るな」なんて言われたりするが、単体テスト自動化、CI 環境が整備できていれば問題ないレベルの「改善」をしよう
- 出自 : 書籍「プログラマが知るべき97のこと」内、Robert C. Martin
- 参考 : プログラマが知るべき97のこと - ボーイスカウト・ルール
- YAGNI (ヤグニ・ヤーグニ)
- 意味 : 「それはきっと必要にならない」
- 例示 : 本当にそれが必要になるまでは、余計なモノは実装しない (その時間が無駄)。XP の原則
- 出自 : 1999年の書籍「Extreme Programming」の著者の一人、Ron Jeffries が主に発言
- 参考 :
- DRY
- 意味 : 同じことを繰り返すな
- 例示 : 同じような処理を何度も書いているならメソッド化する。DB の正規化
- 出自 : Andy Hunt・Dave Thomas の著書「The Pragmatic Programmer (達人プログラマー)」で提唱。「プログラマが知るべき97のこと」でも言及されている
- 参考 :
- KISS
- 意味 : シンプルにしておけバカ。「Keep It Short and Simple (簡潔・単純にしておけ)」とも
- 例示 : 設計や実装手法を単純なモノにブレイクダウンしておくこと。不必要に複雑にしないこと
- 出自 : ロッキード・スカンクワークスの技術者ケリー・ジョンソンが作った
- 参考 : Wikipedia - KISS の原則
- SOLID
- 意味 : オブジェクト指向設計に関する以下の5つの原則の頭文字
- SRP (単一責務の原則) : クラスを変更する理由は1つにする。
- OCP (開放 / 閉鎖原則) : クラスは拡張に対して開き、修正に対して閉じておく。
- LSP (リスコフの置換原則) : 派生型 (継承する子クラス) はその基本型 (親クラス) と置換可能にする。
- ISP (インターフェース分離の原則) : クライアントが利用しないメソッドへの依存を強制しない。
- DIP (依存性逆転の原則) : 上位のモジュールは下位のモジュールに依存しない。どちらも「抽象」に依存するべき。
- 例示 : (それぞれの原則の項で個別に触れる)
- 出自 : XP の提唱者ロバート・C・マーチンが2005年に書いた「The Principles of OOD」という記事で SOLID という5つにまとめたとされる
- 参考 :
- 意味 : オブジェクト指向設計に関する以下の5つの原則の頭文字
- 単一責務の原則 : SRP
- 意味 : 一つのモノの責務・役割は一つにする。一つのモノに変更が入る理由は一つにする。「単一責任の原則」とも
- 例示 : 1つのクラスやメソッドにに複数の処理を詰め込まない
- 出自 : XP の提唱者ロバート・C・マーチンが2005年に書いた「The Principles of OOD」という記事がほぼ初出
- 参考 :
- 開放 / 閉鎖原則 : OCP : オープン・クローズドの原則
- 意味 : 拡張に対して開いていて、修正に対して閉じていること
- 例示 : 機能の追加や変更がしやすい作りであり、かつ、既存の実装を修正した時の影響範囲が少なくなる作りが良い、ということ。一度作ったクラスは原則変更せず、継承によって機能を追加したり、ポリモーフィズムを利用したりして、拡張に対して開く。また、グローバル変数を利用しないようにしたり、インスタンス変数を
privateで扱ったりすることで、修正時の影響を小さくする - 出自 : Bertrand Meyerの1988年の著書「Object Oriented Software Construction (オブジェクト指向ソフトウェアの構築)」
- 参考 : Wikipedia - 開放 / 閉鎖原則
- リスコフの置換原則 : LSP
- 意味 : 派生型 (継承する子クラス) はその基本型 (親クラス) と置換可能になっていないといけない
- 例示 : 基本クラスを使っている場所で、その基本クラスの代わりにサブクラスを用いたとしても、正しく動作すること
- 出自 : Barbara Liskov・Jeannette Wing の1993年の論文「Family Values: A Behavioral Notion of Subtyping」で示された
- 参考 :
- インターフェース分離の原則 : ISP
- 意味 : クライアントは自分が使わないメソッドに依存することを強制されない
- 例示 : クライアントが本当に使いたいメソッド (インターフェース) のみが提供されるべき。インターフェースや委譲による分離。「Listener (リスナー)」というインターフェース
- 出自 : 2002年、ロバート・C・マーチンの「Agile Software Development」にて提唱された
- 参考 :
- 依存性逆転の原則 : DIP
- 意味 : 上位のモジュールは下位のモジュールに依存してはならない。どちらも「抽象」に依存するべき
- 例示 : クラス同士を具象クラスで依存させるのではなく、抽象クラスかインターフェースを通じて関係を示す
- ある具象クラス「A クラス」が、別の具象クラス「B クラス」の処理を利用する場合、「B クラス」のインターフェースに依存することになる
- しかし、「B クラス」をそのまま呼ばず、「A クラス」側でインターフェースを宣言しておき、そこに「B クラス」を適用する (DI) ようにすると、「A クラス」が呼びたいインターフェースを自分で決めたことになり、インターフェースの所有権が「A クラス」に変えられる。コレが「逆転」ということ
- 出自 : ロバート・C・マーチンの1994年の論文「Object Oriented Design Quality Metrics: an analysis of dependencies」
- 参考 :
- 関心の分離 : SoC
- 意味 : それぞれのプログラムの関心事 (やりたいこと) を分けること
- 例示 : Web ページを構成する HTML・CSS・JavaScript は、それぞれ文書構造・見栄え・画面処理というそれぞれの関心事に分離されており、それぞれは疎結合になっている。MVC パターンなども「関心の分離」の一例
- 出自 : エドガー・W・ダイクストラの1974年の論文「On the role of scientific thought (科学思想の役割)」で初めて「Separation of Concerns」という言葉が使われた
- 参考 : Wikipedia - 関心の分離
- ジョシュア・ツリーの法則 : JTP
- 意味 : 名前を知った途端にそれが見えるようになること
- 例示 : デザインパターンを勉強しておくと、コードを見た時にデザインパターンに当てはめてより色々なことが理解・推測できるようになる
- 出自 : 作家 Robin Williams の1994年の著書「The Non Designer's Design Book (ノンデザイナーズ・デザインブック)」の冒頭。書籍「プリンシプル・オブ・プログラミング」にも登場
- 参考 : オブラブ - ソフトウェア原則 ちょっと横道 その1 JTP Joshua Tree Principle
- UNIX 哲学
- 意味 : UNIX OS の開発経験に基づく規範や哲学的なアプローチのまとまり。有名なものは以下
- 一つのことを行い、またそれをうまくやるプログラムを書け。(ダグラス・マキルロイ)
- 早すぎる最適化は諸悪の根源である。 (ドナルド・クヌース)
- 疑いがあるときは総当たり (Brute Force) を使え。 (ケン・トンプソン)
- スマートなデータを使うつまらないコードを書け。
- 小さいものは美しい。 (マイク・ガンカーズ)
- できる限り早くプロトタイプを作れ。 (マイク・ガンカーズ)
- 効率よりも移植しやすさ。 (マイク・ガンカーズ)
- 単純なテキストファイルにデータを格納せよ。 (マイク・ガンカーズ)
- 拘束的なユーザインタフェースは作るな。 (マイク・ガンカーズ)
- 全てのプログラムはフィルタとして振る舞うようにせよ。 (マイク・ガンカーズ)
- より悪いことは、より良いことだ。 (リチャード・P・ガブリエル) … (質と機能性は必ずしも比例しないことから。完全さよりもシンプルさ)
- 例示 : 全体的に、「シンプルが良いこと」という感じ「1つのプログラムは、1つのことを小さくやろう (単一責務の原則)」「完璧さを求めず、平易でシンプルにしよう (KISS 原則)」
- 出自 : UNIX 創始者の一人で、「パイプ」の技術を発明したプログラマ、ダグラス・マキルロイの2000年の著書「UNIX の四半世紀」や、1989年、ロブ・パイクの「Notes on Programming in C」など
- 参考 :
- 意味 : UNIX OS の開発経験に基づく規範や哲学的なアプローチのまとまり。有名なものは以下
- ポステルの法則 : Postel's Law
- 意味 : 送信するものに関しては厳密に、受信するものに関しては寛容に
- 例示 : 元はインターネット通信の原則だが、「受信」を「入力」、「送信」を「出力」と解釈して「入力は寛容に、出力は厳密に」と捉えると、メソッドの作りの原則としても応用できる
- 出自 : Jon Postel の1981年の RFC「RFC793」
- 参考 : RFC 793 - Transmission Control Protocol
- 銀の弾丸などない
- 意味 : 魔法のように、すぐに役に立ち、プログラマの生産性を倍増させるような技術や特効薬は存在しない
- 例示 :
- 何かをサクッと解決することはできない
- 複雑性の性質を区別する。本質的な複雑性 (解決したい問題自体の複雑さ) にのみフォーカスし、偶有的な複雑性 (開発者が発生させている、解決可能な問題) はできるだけ早く取り除く
- 出自 : フレデリック・ブルックスの1986年の書籍「銀の弾などない - ソフトウェアエンジニアリングの本質と偶有的事項」
- 参考 : Wikipedia - 銀の弾丸などない
- 金のハンマー : ゴールデン・ハンマー病 : ハンマー釘病
- 意味 : 気に入った方法があらゆるところで利用できると思い込む、アンチパターンの一種
- 例示 : 「銀の弾丸などない」のに、一度知ったやり方をあらゆるところで利用しようとし、「そのパターンならこっちの方が楽だよ」といった視点を欠いている
- 出自 : Abraham Harold Maslow の言葉「ハンマーを持つ人にはすべてが釘に見える」から
- 参考 : @ledsun blog - 優秀なプログラマになるために
- 神クラス : 神オブジェクト : God Object : Monster Object
- 意味 : 一つのクラスやオブジェクトに過剰に機能が集中すること。アンチパターンの一種
- 例示 : あるクラスが文字列変換も HTTP 通信も入力チェックも全部やっているような状態、もしくはそうした機能を盛り込まれた「汎用ユーティリティクラス」など。「単一責務の原則」に反する
- 出自 : Arthur J. Riel の1996年の書籍「Object-Oriented Design Heuristics」にて紹介された
- 参考 : Wikipedia - God object
- カーゴ・カルト・プログラミング
- 意味 : 実際には意味のないコードやプログラムが混ざっているにも関わらず、その仕組みや動きを理解していないために、「おまじない」的にコーディングしていること。アンチパターンの一種
- 例示 : 「誰かが1行目にコレを書けって言ってたから書いとこう」と書かれた間違った Shebang。意味を理解せずにコピペプログラミングしたために各所に見られる「不必要な
new」など - 出自 : リチャード・P・ファインマンが1974年にカリフォルニア工科大学の卒業式で発表した式辞「カーゴ・カルト・サイエンス」がオリジナルか
- 参考 : Wikipedia - カーゴ・カルト・プログラミング
- ハードコーディング
- 意味 : プログラムの動作環境などの「仮定」を実装に埋め込んでしまうこと。いわゆる「ベタ書き」。アンチパターンの一種
- 例示 : 対象のプログラムが動作するベース URL を設定ファイル等で差し替え可能な作りにせず、コード内の String 変数に直接書き込んでしまうような作り
- 出自 : (誰が言い出したかは不明)
- 参考 : Wikipedia - Hard coding
- マジックナンバー
- 意味 : 意味のある数値を何の説明もなく使用している状態。アンチパターンの一種
- 例示 : 税込金額の計算プログラムとして、
return price * 1.08;のように、税率 8% を前提とした1.08という数値をハードコーディングしていると、1.08はマジックナンバーと呼ばれる。taxRateといった変数名を付けるべき - 出自 : (誰が言い出したかは不明)
- 参考 : Wikipedia - マジックナンバー
- プログラマの三大美徳 : 怠惰・短期・傲慢
- 意味 : 効率・再利用性を重視すること、処理速度を追求すること、品質にかける自尊心を表現したもの
- 例示 : 横着するための労力を惜しんではいけない。ただし、「手段の目的化」に陥らないよう注意
- 出自 : Perl 言語を開発した Larry Wall の発言
- 参考 : Wikipedia - プログラマ
- Yak Shaving : ヤクの毛を刈る
- 意味 : 「真の問題を解くのに必要な問題」を解くのに必要な問題 (が何段階も続く)、を解くのに必要な活動…、という意味
- 例示 : 「○○を実装したい」という真の目的の前に、「SSL 認証が必要で、そのためには証明書の準備が必要で、そのために文字列変換が必要になって、その中で文字コード変換が必要になって…」といった状態
- 出自 : Jeremy H. Brown のメールが元らしい
- 参考 :
プロジェクトマネジメント関連
- ブルックスの法則
- 意味 : 遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである
- 例示 : 新たに参画した開発者が生産性向上に寄与できるまでには時間がかかり、人員が増えるとコミュニケーションコストが増加するため、遅延解消には繋がりにくい。また、タスクを分解するにも限度がある
- 出自 : 1975年に出版された Frederick Phillips Brooks, Jr. の著書「The Mythical Man-Month (人月の神話)」
- 参考 : Wikipedia - ブルックスの法則
- ホフスタッターの法則
- 意味 : いつでも予測以上の時間がかかるものである - ホフスタッターの法則を計算に入れても
- 例示 : 「予測以上に時間がかかる」と思って見積しても、やっぱりそれ以上に時間がかかる
- 出自 : Douglas Richard Hofstadter の1979年の著書「ゲーデル、エッシャー、バッハ - あるいは不思議の環」
- 参考 : Wikipedia - ダグラス・ホフスタッター
- パーキンソンの法則 : Parkinson's law
- 意味 : 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」「支出の額は、収入の額に達するまで膨張する」
- 例示 : 「データ量は与えられた記憶装置のスペースを満たすまで膨張する」「ある資源に対する需要は、その資源が入手可能な量まで膨張する」「どんなに大きな冷蔵庫を買っても、必ず満杯になる」
- 出自 : 1958年、イギリスの歴史学者・政治学者シリル・ノースコート・パーキンソンが著作「パーキンソンの法則：進歩の追求」で提唱
- 参考 : Wikipedia - パーキンソンの法則
- マーフィーの法則 : Murphy's law
- 意味 : 「不都合を生じる可能性があるものは、いずれ必ず不都合を生じる」など、経験則に基づく教訓集
- 例示 : 「起こる可能性があることは、いつか起こる」がベース。「洗車しはじめると雨が降る。雨が降って欲しくて洗車する場合を除いて」「落としたトーストがバターを塗った面を下にして着地する確率は、カーペットの値段に比例する」など。ほとんどはユーモア・ジョークの類なので、あまり盲信しないように
- 出自 : 1993年のアスキー出版「マーフィーの法則」がよく知られるが、大本は1949年頃、アメリカ空軍の研究に携わっていた Edward A. Murphy, Jr. 少佐の発言をベースにパロディなどが寄せ集められて生まれたもの
- 参考 : Wikipedia - マーフィーの法則
- ハインリッヒの法則 : Heinrich's law
- 意味 : 1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する
- 例示 : 些細なこと、ちょっとしたミスを軽視していると、その積み重ねでいつか重大な障害を起こしたりする。日頃から業務やマニュアルを見直したり、リファクタリングしたりすることが大事
- 出自 : この法則を生み出した Herbert William Heinrich の1929年の論文「Relation of Accident Statistics to Industrial Accident Prevention」
- 参考 : Wikipedia - ハインリッヒの法則
- 90対90の法則
- 意味 : 「コードの最初の 90% が開発時間の 90% を占め、残りの 10% がさらに 90% を占める」「プロジェクトの 90% は予算の 90% を使用し、残り 90% も予算の 90% を使う」
- 例示 : 最後の 10% と思っていたところが中々終わらないし、合計して想定の 180% の時間や予算がかかるもの。という皮肉・ユーモア
- 出自 : ベル研究所の Tom Cargill が考え出し、1985年9月のACM学会誌「Communications of the ACM」の Jon Bentley のコラム「Programming Pearls」で著名になった
- 参考 : Wikipedia - 90対90の法則
- パレートの法則 : 80対20の法則
- 意味 : 「成果の 80% は、作業の 20% から得られる」
- 例示 : ある事象・結果の8割の要因は、作業全体の2割の影響が大きい、ということ。作業全体からすると些細なことでも、結果の大部分に影響を与えたりする
- 働きアリの法則と同様に、「組織の2割の人が大部分の収益を上げていて、その2割の人が間引かれると残りの8割中の2割が大部分の利益をもたらすようになる」など
- プログラムの処理にかかる時間の 80% は、コード全体の 20% の部分が占める
- 全体の 20% が優れた設計ならば、実用上 80% の状況で優れた能力を発揮する
- 出自 : 20世紀初頭、イタリアの経済学者ヴィルフレド・パレートが発見
- 参考 : Wikipedia - パレートの法則
- NIH 症候群 : 独自技術症候群 : 自前主義
- 意味 : ある組織が、別の組織の製品やアイデアを採用したがらず、自前で再開発すること
- 例示 : 俗にいう「車輪の再発明」が起こる原因の一つ。「目的を容易に達成できる既存ツールの存在を知らずに、自前で作ってしまった」という場合ではなく、「アレはどこそこが作ったオープンソースだから使わない」などというそれ以外の理由で独自開発すること
- 出自 : 1982年の Katz, Ralph, and Thomas J. Allen の論文「Investigating the Not Invented Here (NIH) syndrome: A look at the performance, tenure, and communication patterns of 50 R & D Project Groups」が出典？
- 参考 :
- ピーターの法則 : Peter Principle
- 意味 :
- 人間は能力の極限まで出世する。したがって、有能だったヒラ社員は、無能な中間管理職になる。
- 時が経つにつれ、人間はみな出世していく。無能なヒラ社員は、そのままヒラ社員の地位に落ち着く。有能なヒラ社員は無能な中間管理職の地位に落ち着く。その結果、各階層は、無能な人間で埋め尽くされる。
- その組織の仕事は、まだ出世の余地のある人間によって遂行される。
- 例示 : ヒラ社員としては能力があるとして評価された人も、管理職になってより困難な問題を扱うようになると、段々と評価されにくくなっていく。「管理職としては無能」となった人はその地位に残り続ける。たとえ管理職として評価された人も、経営層に出世して同じように評価されるかというと難しく、「無能な経営者」に落ち着いてしまったりする。結果的に、どの層にも無能が溢れることになる。それでも仕事がなんとか進んでいるのは、その階層において出世の余地がある人の頑張りによってなされているから
- 「働きアリの法則」「パレートの法則」に類似するもので、「2割の勤勉者」が何故いるかというと、この「ピーターの法則」でいう「出世の余地がある人間」ということになる
- 優秀なヒラ社員が、優秀な管理職になるとは限らない。しかし人は「ある有効な手段を、別の困難な問題に応用したがる」ので、結果的に失敗する
- 出自 : アメリカの教育学者ローレンス・J・ピーターの1969年の著書「ピーターの法則 - 創造的無能のすすめ」の中で提唱
- 参考 : Wikipedia - ピーターの法則
- 意味 :
- 大きな泥だんご : Big ball of mud
- 意味 : 理解不能な構造がないシステムのこと。アンチパターンの一種
- 例示 : 機能追加、拡充を繰り返したことで、当初のシステム化の目的や、システム化対象範囲がよく分からなくなってしまうシステム。「一つのプログラムは一つのことだけ上手くやれ」という UNIX 哲学に反した作り、といえる
- 出自 : Brian Foote・Joseph Yoder の1997年の論文「Big Ball of Mud」によって普及
- 参考 : Wikipedia - 大きな泥だんご
- HRT
- 意味 : 謙虚・尊敬・信頼の3つの頭文字を取ったもの。「優れたチームが優れたソフトウェアを作るのに必要な三本柱」として提唱された、エンジニアが人に対して持つべきマインドセット
- 例示 : HRT はチームメンバに対して持つべきマインドセットで、コードに対しては適用すべきでない。コードに対してはどちらかというと「プログラマの三大美徳」で挑むべき
- 出自 : 書籍「Team Geek」
- 参考 : 「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」