書籍 プリンシプルオブプログラミング 第7章 まとめ
7章
法則 〜プログラミングのアンチパターン〜
7.1 ブルックスの法則
要員追加は火に油
スケジュールより遅れている案件に対し、単純に人を追加すると「依存関係によるオーバーヘッド」「教育に時間が取られる」といった要因から、さらなるスケジュールの遅延を招いてしまう。
プログラマは等価交換できない
一人のプログラマを別のプログラマに交換したところで、質や経験の差から必ず同じ生産能力になるとは限らない。 同様に急に人数を追加しても、それに比例してチームの生産能力が上がるわけではない。
リスケジュールをする
無条件に人員を投入するのではなく、リスケジュールが最も効果的である。その際は、クライアントと相談しながら各機能に優先度を付けて、段階的にリリースしていく。
7.2 コンウェイの法則
アーキテクチャは、それを作った「組織」のコミュニケーション構造を反映するが、組織の都合で出来たアーキテクチャは最適でない可能性が高い。
そのため、まずアーキテクチャを先に設計し、十分な検証の後、組織編成するのが最も効率的である。
7.3 割れた窓の法則
悪いコードは邪心を引き出す
コードに一箇所でも悪い部分があると、それを見た他のプログラマも適当なコードを書こうとしてしまう。
コードは清潔に保つ
悪い部分があったら放置せずにすぐ修正する。 万が一すぐの修正が難しい場合は、悪い部分を明示して、コードの管理が適切に行われていることのアピールをしておく。
7.4 エントロピーの法則
コードは無秩序へ向かう
仮に良いスタートを切ったとしても、徐々にコードの腐敗が進み、どんどん保守が難しくなっていく。
コード腐敗の兆候を掴む
硬さ
- 変更の難しさ
- 一つの変更で、それと依存関係のあるモジュールを連鎖的に変更しなければならないようなコード
- 対策:モジュール間の無駄な依存関係を排除する
脆さ
- たった一つの変更だけで他の部分が壊れてしまう度合い
- 破損と修正を繰り返し続けるようなコード
- 対策:
移植性のなさ
- 他の環境への移植がしにくいこと
- 「環境に依存している部分」を全体から切り離すのが難しい場合、移植性がないと言える
- 対策:特定環境への依存性
扱いにくさ
コード
- 設計構造に柔軟性がないこと
- 設計を保持したまま、容易に機能の変更を行なうことが出来ない
- 対策:設計に柔軟性を持たせる
環境
複雑さ
- 不要な要素の存在
- 「後で必要になりそうだから入れておく」→「結局使わない」という流れの中で、コードに無駄な構造が散乱し、理解しにくくなる
- 対策: 不要な要素を記述しない
繰り返し
- 同じ記述が何度も記述されていること
- 変更時に複数の箇所に修正をしなければならない
- 見落としから不具合の発生を招く可能性がある
- 対策:関数化するなどして、一箇所の記述を使いまわす
- 僅かに処理が違う場合は、抽象化してなるべく共通の部分だけを使いまわすこと
不透明さ
- 分かりにくく処理が複雑なコードは、コードを書いた本人以外には理解し難いモノになりがち
- 対策:読み手に理解してもらえるよう最大限配慮したコードにする、コードレビューをもらう
アジャイルで腐敗を許さない
アジャイル型の開発では、変化に柔軟に対応できる。
また、変化に適応できない初期設計にほとんど時間を割かないため、時間効率も良い。
チーム文化で腐敗を許さない
「常にシンプルに保つ」「過剰な設計をしない」などといったチームの行動指針で、腐敗を発見次第リファクタリングしていく。
7.5 80-10-10の法則
プログラミングに万能薬は無い
一つのツールでユーザーの要求を満たそうとすると、以下のようになる。
- 80%:実現可能
- 10%:実現は可能だが、相当な努力が必要
- 10%:実現不可能
適材適所
ソフトウェア開発において、どんな場所にも適用できる万能なツールは存在しない。
そのため、ソフトウェアの仕様に最も適合しているツールを使用することが効果的。
7.6 ジョシュアツリーの法則
名前を知ることで存在を知る
物事や概念があっても、名前を知らなければ活用できない。そのため、まず名前を知ることが大事。
ユビキタス言語
チーム内で利用する独自の言語を作成し、認識を共有させる。
7.7 セカンドシステム症候群
2番目のリリースは機能過多
2番目にリリースするバージョンは、機能を盛り込み過ぎていて、プログラマの設計する最も危険なバージョンになる傾向がある。
慣れると「多機能主義」へ
最初のリリースでは、未知のことが多く、リスクの高さから慎重な設計をする。
しかし、2回目のリリースとなってくると、慣れや知識が増えたことによって、無駄に機能を盛り込み過ぎてしまいがち。
ユーザーを考える
- ユーザーは誰なのか
- 何を必要としているのか
- 何を必要だと考えているのか
- 何を望んでいるのか
以上を考えた上で、必要な機能だけを実装する。
また、これは2回目だけに限った話ではない。
7.8 車輪の再発明
既にあるのに作る
作りたいものを実現しているコードやライブラリが既に存在しているにもかかわらず、自分でコードを作成するのは工数的にも非効率である。
主な原因
知らない
- 使用できるリソースの存在を知らないため、新しくコードを記述してしまう
- 対策:チーム内で既に求めている機能を持ったコードが存在しているか確認する
作りたい
- 自分で開発したいという、プログラマのエゴ
- 対策:ユーザーの要求を満たすことを最優先に考えること
再発明が必要なとき
ビジネス目的
- 外部のコードを利用すると、その部分に依存性が発生してしまい、内部のコードの修正も難しくなってくるため
学習目的
- ソフトウェアについての知識を習得するため -ブラックボックス化を防ぐ
7.9ヤクの 毛刈り
本当の問題に辿り着けない
問題を一つずつ解決している間に、本来自分の求めていた問題を忘れてしまうこと
早々に切り上げる
なかなか問題を解決できないときは、本来の目的から逸れていないか確認する。万が一逸れているようであれば、作業を取りやめて他のやり方を選択する。
問題整理
ヤクの毛刈りに対応しなければならないとき、問題をメモなどに書き留めながら1つずつ丁寧に解決していくようにするのが良い。