プログラミングに関する原理原則

Once And Only Onceの略。 コードの重複は避けるべきという考え方。

Don’t Repeat Yourself.の略。 システム開発において、情報の重複は避けるべきという考え方。

OAOOの原則とよく似た概念。

Keep it simple, stupid.の略。不必要な複雑性は避けるべきという考え方。

separation of concerns.の略。異なる関心事は異なる部分に分離すべきという考え方。

You Ain't Gonna Need It.の略。余計な機能は本当に必要になるまで追加するべきでないという考え方。

Program Intently and Expressively.の略。コード自体がドキュメントとしてコードの意図を表現するように記載するべきであるという考え方。

Single Level of Abstraction Principle.の略。コードは複雑さに応じて多階層に構造化し、各階層での抽象化レベルを揃えるべきであるという考え方。

「SOLID」はオブジェクト指向プログラミングにおけるソフトウェア設計原則の頭文字をとったもの。

SOLIDの原則の詳細については以下を参照されたい。

「CLEAN」は以下に示す5つのコード品質評価尺度の頭文字をとったもの。多面的な観点からコードを評価することでコード品質を向上できる。

「CLEAN」コードの詳細については以下を参照されたい。

失敗する余地があるなら必ず失敗するいう法則。何かが発生するリスクがあるならば、 それは遅かれ早かれ必ず発生するため、設計上の課題が存在することを示唆する。

組織の中で、人は自身の能力の極限まで昇進する。昇進した人は、より高い能力あるいは異なる能力を求められる仕事に従事することで無能化していく。最終的には、組織全体の人材が無能化してしまう。

チームにおいてもピーターの法則と同様の現象が起こりうる。優秀なチームを解体してチームメンバーを再分配することで、優秀なチームを量産しようとすると、組織全体のチームが無能化してしまう。

遅延しているプロジェクトへの要員の追加は、さらにプロジェクトを遅延させるという法則。さらなる遅延につながる要因として、以下があげられる。

プロジェクトが遅延している場合、安易に人員を追加するのではなく、リスケジュール、遅延原因の特定、原因に応じた適切な対処が必要である。

ソフトウェアの構造（アーキテクチャ）は組織の構造を反映するという法則。組織の構造に従ってコミュニケーションが構築され、コミュニケーションに添ってアーキテクチャが構築されていく。

良いアーキテクチャを設計するためには、まずアーキテクチャを構築して、その後そのアーキテクチャに沿った組織を構築する必要がある。

1枚の割れた窓でも、放置しておくと次第に街全体が荒廃してしまうという理論。ソフトウェアの設計においても、悪いコードを放置しておくと次第にソフトウェア全体が腐敗してしまう。