エンジニア組織を強くするための本を出版しました
Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。
エンジニアリング組織論への招待
～不確実性に向き合う思考と組織のリファクタリング
この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。
デメテルの法則
別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。
基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。
単純化して説明すると、オブジェクトの"メンバーのプロパティ/メソッド"を直接触らないようにするということ。
// デメテルの法則に違反している
console.log(aStudent.class.grade)
// デメテルの法則に違反していない
console.log(aStudent.getGrade())
できる限り、サブコンポーネントに関する知識を持たずにすむように実装するための原則。
ヴィルトの法則
「ソフトウェアは、ハードウェアが高速化するより急速に低速化する」という経験則。
http://ja.wikipedia.org/wiki/%E3%83%B4%E3%82%A3%E3%83%AB%E3%83%88%E3%81%AE%E6%B3%95%E5%89%87
計算資源が豊富になると富豪的プログラミングで、生産性に寄与するようにフレームワーク等が進化するので、ハードウェアが進歩しても、ソフトウェアの速度は変わらないように感じるということだろう。
ブルックスの法則
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけだ」という経験則。
これの言い換えである「9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない」はとてもわかりやすい。
これが成り立つ背景としては、「プロジェクトへの習熟までに時間がかかること」「コミュニケーションコストが増大すること」が挙げられている。
http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87
コンウェイの法則
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
—M. Conway[2]
http://en.wikipedia.org/wiki/Conway%27s_Law
「システムを設計する組織は、自分たちの組織のコミュニケーション構造をそっくりそのままコピーした設計を生み出してしまう」という原則。
事実近年の研究では、組織構造がバグの再現率に最も寄与するという研究結果も出ている。
http://research.microsoft.com/apps/pubs/default.aspx?id=70535
ホフスタッターの法則
「いつでも予測以上の時間がかかるものである — ホフスタッターの法則を計算に入れても。」
という自己言及的な見積もりに関する法則。
http://ja.wikipedia.org/wiki/%E3%83%80%E3%82%B0%E3%83%A9%E3%82%B9%E3%83%BB%E3%83%9B%E3%83%95%E3%82%B9%E3%82%BF%E3%83%83%E3%82%BF%E3%83%BC#.E3.83.9B.E3.83.95.E3.82.B9.E3.82.BF.E3.83.83.E3.82.BF.E3.83.BC.E3.81.AE.E6.B3.95.E5.89.87
驚き最小の原則
インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。
http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87
インタフェース設計のユーザビリティに関する原則。
ボーイスカウトの規則
ボーイスカウトが、来る前よりも帰った後の方が山をきれいにしておくことにちなんだ規則。
ソフトウェア開発においては「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」ことを意味する。
YAGNI
"You ain't gonna need it"の略。「そりゃ必要にならんよ」てな意味。XPに関する格言で、必要になるまで実装するなという意味。
http://ja.wikipedia.org/wiki/YAGNI
DRY
"Don't Repeat Yourself"の略。「同じことを繰り返すな」という意味。
DRY 原則がうまく適用されたとき、システムに対するいかなる要素の変更も、論理的に関連のない他の要素の変更にはつながらない。さらに、論理的に関連した要素は予測できる形で統一的に変更され、したがってそれらの変更は同期が取れたものとなる。
http://ja.wikipedia.org/wiki/DRY
KISS
"Keep it simple, stupid" の略。「シンプルにしておけバカ」という意味。
この原則の起源と思われる似た概念がいくつかある。たとえば「オッカムの剃刀」。アルバート・アインシュタインの格言「何事もできるだけ単純な方がいい。ただし単純にしすぎてはならない」。レオナルド・ダ・ヴィンチの「単純であることは究極の洗練だ」の言葉。アントワーヌ・ド・サン＝テグジュペリの「完璧とは、これ以上加えられないときではなく、これ以上削りとれないときに達成されるようだ」。
SOLID
オブジェクト指向設計に関する原則の頭文字をとって「SOLID」とまとめられた原則集。
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
| 頭文字 | 略語 | コンセプト |
|--------|------|----------------------------------------------------------------------------------------------------------------------------------------------------------------| |
| S | SRP | Single Responsibility Principle（単一責務の原則） |
| | | 「クラスを変更する理由は１つでなければならない」 |
| O | OCP | Open/closed principle（開放閉鎖の原則） |
| | | 「クラスは拡張に対して開き、修正に対して閉じていなければならない」 |
| L | LSP | Liskov substitution principle（リスコフの置換原則） |
| | | 「派生型はその基本型と置換可能でなければならない」 |
| I | ISP | Interface segregation principle（インターフェース分離の原則） |
| | | 「クライアントが利用しないメソッドへの依存を強制してはならない」 |
| D | DIP | Dependency inversion principle（依存性逆転の原則） |
| | | 「上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。」|