書籍 プリンシプルオブプログラミング 第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つずつ丁寧に解決していくようにするのが良い。