🎢

プログラミングのアンチパターン要点（ざっくり）

2024/03/02に公開

読書メモ

プリンシプルプログラミング

idea

プリンシプルオブプログラミング―３年目までに身につけたい一生役立つ１０１の原理原則

上記の本を読んだので、
7章「プログラミングのアンチパターン」部分の要点をまとめました。

１．ブルックスの法則

遅延している開発プロジェクト人員を追加する！
- 余計に遅延が悪化してしまうこと😓

✖「人」と「月」は交換不可能

新しい参画メンバーの教育時間が必要。
- 戦力になるまで、チーム全体の進捗率も落ちてしまう。
コミュニケーションパスの増加。
- タスクを分割・担当分けすると、依存関係が生まれることからコミュニケーションパスが増える。

👉解決策：リスケジュールせよ！

無条件に進捗遅れを人員確保で解決しようとせず、ユーザと調整する
- 機能に優先度をつけて、段階的にリリース
「人」と「人」も交換不可能で、プログラマによって質の差がどうしても発生してしまう

参考：IT用語辞典 - ブルックスの法則によると、
名前の由来は、米コンピュータ科学者フレデリック・ブルックス詩の提唱より。（1975年と古い）

２．コンウェイの法則

チームを組織やスキルによって分断するよ➰
- ソフトウェアも組織のコミュニケーション構造を反映させた内容になっちゃうこと
組織都合で出来たアーキテクチャは、品質に影響する恐れあり
- アーキテクチャ側だけ最適化しても、組織間のコミュニケーションパスにズレが生じてしまう…💦

名前の由来

1967年にメルヴィン・コンウェイ氏が書いた記事が元となっている。
- 「コンウェイの原則」と呼ばれることもある。

👉解決策：アーキテクチャ設計後に組織編成

アーキテクチャに沿った組織に変更する
- 組織を隔てたコミュニケーションパスなども減り、結果的に障害やバグも減少する
早急に作成されるアーキテクチャは、不安定であるため組織編成に注意が必要
- 十分なアーキテクチャの検証を行った後、組織を構築する

❓ 逆コンウェイの法則とは？

本書には記載していないが、調べて出てきたのでまとめメモ。

最適な設計に合わせて、最初から組織デザインを行うこと。
実現したいソフトウェアの構造に合うように組織を編成する。
- コンウェイの法則を逆手に取った手法。

３．割れた窓の法則

ビルなど建物に小さく割れた窓が一つある
- 放置していると誰も気付かず、そのままとなる…。
- 結果、他の窓も割れてゴミも散乱💥し、建物全体に影響を及ぼしてしまう😱
別名・割れ窓理論とも呼ばれる。

なにが問題なのか？

ソフトウェアの小さな悪い部分（※）を放置すると、全体に影響を及ぼす。
- ※「悪い設計」「間違った意思決定」「悪いコード」など
コードの悪い部分がたまると、保守がしづらくなり、再設計のコストが増大する。

👉解決策：コードを清潔に保つ🧹

コードのよくない部分を発見したら、発見と同時に修復する。
すぐにコードを直せない場合は、IDEのタグ付コメントに明示しておく。
人のコードを安易に真似しない（疑問を持つようにする）

４．エントロピーの法則

「エントロピー」とは物理学の用語で、「無秩序な度合い」。
- エントロピーが増えた状態は、それだけ無秩序になる。
コードは自然に任せると、エントロピーが増える＝「腐ったコード」。
- コードも、時間が経つと自然の法則と同じで腐敗がひどくなる😈
- コード内に無秩序なコードが溜まり、保守性が低下。再設計も大変。

👉解決策：コードの腐敗の兆候を予測せよ！

コードが腐敗する傾向は、大きく7つあるので、見逃さないようにする🔍

硬さ
- 変更が難しくなっている。
脆さ
- たった1つを変更すると、全体のコードが壊れる。
移植性のなさ
― 環境依存のため、他の環境への移行が困難。
コードと環境の扱いにくさ
- コード：設計構造と柔軟性がない。
- 環境：開発環境が遅くて非効率的。
複雑さ
- 将来の変更を見越して設計・プログラミングされていない。
繰り返し
- 同じようなコードが複数存在している。
不透明さ
- 読み手のことを考えないコード内容となっている。

５．80-10-10の法則(80-10-10 rule)

ソフトウェアを開発していく中での法則。

80％：ユーザの求めること（短時間で実現可能）
10％：実現可能だが相当な工数が発生
10％：完全が実現不可能❌

ユーザから100％を求められると、泥臭い開発を強いられるハメに😢
単独ツールで解決する万能薬はないので、複数ツールを使う。

👉解決策：ツールの使用は適材適所

ソフトウェアにおいて万能薬はない。
複数ツールを導入する場合、適材適所で利用し、最大限に効果を発揮できるようにする。
- 事前にプロトタイプ開発するのも良い⭕

似たような単語：パレートの法則(80:20の法則)❓

⚠名前は似ているが、法則内容はまったく異なる。

全体の数値の8割は、全体を構成する内の2割の要素が生み出している。
- 障害の8割は、2割のコードに集中している。
- 処理にかかる時間の8割は、2割のコードが締めている。

コードには品質やパフォーマンスの「ホットスポット🔥」がある。
障害が発生しているホットスポットがあれば、横展開テストなどで集中的に対策する❗

６．ジョシュアツリーの法則

「名前」を知っていると、人は物事や概念を認知すること🧐
逆に「名前」が付いていないと、認知しづらい。

由来

ある人が、植物図鑑を見ている時に、「ジョシュアツリー」という木があることを知る。
今まで見たことなかったが、帰り道にいたるところに「ジョシュアツリー」を発見したことから。
（ノンデザイナーズ・デザインブックより出典している）

👉解決策：名前を付けて、チームで共有する

「ユビキタス言語」と呼ばれるチーム共通言語を作成して利用する。
チームでバラバラの用語を使用していると、コミュニケーションパスに影響する。
業務的な用語だけではなく、コードの変数名にも使用する。

７．セカンドシステム症候群

ソフトウェアの2番目のバージョンは、もっとも危険なバージョン⚠
最初のバージョンからの保留分や、ユーザの要望も含めて機能が盛りだくさんに…
- 品質や使い勝手が悪くなる傾向になる😱

👉解決策：ユーザを第一に考える

ユーザを考え、本当に今必要としている機能なのかを考える。
「多機能主義」にならないように自制を持つ。

セカンドシステム以降症候群ってなに❓

セカンドバージョン以降も、バージョンアップするごとに「無駄に」多機能となっていく。
- 一度リリースした機能は削れないので、保守性も悪くなっていく…。
案外ユーザは新機能よりも、基本機能の安定や使い勝手向上を望んでいる😇

フィーチャー・クリープってなに❓

ユーザからの要望を無秩序に導入して、過度に新機能を追加していくこと。
- ソフトウェアの用語ではなく、商品開発でも使われる。
機能が膨大になると、保守がしづらいソフトウェアになる。
- ユーザからの要望には、時に「NO」と言える勇気を😧
- 難しければ、コードをシンプルに保つことを意識する。

８．車輪の再発明

既に存在している機能を新しく再発明（プログラミング）してしまうこと。
プログラミングしてしまう理由は2つある。
- プログラマの知識・勉強不足で、そもそも機能自体を知らなかった。
- 機能を作りたい欲求
  - 技術的興味や自分自身で作ってみたいというプライドから。
  - ➡ これはプログラマのエゴ😈

👉解決策：車輪以外の本来やるべきことに注力する

コードを書く前に、同じ機能が標準ライブラリやプロトコルにないかチェック☑
チームメンバーにも同じ機能がないか確認する。
ソフトウェアの目的は「ユーザーの欲求を満たすこと」❗
- ユーザーのために、「工数」「品質」など意識すること。

🔋 あえて再発明する！？

ビジネス目的
- 既存のものを流用することは、致命的な問題があった場合リスクになる
- ビジネス上、コアな部分は自前で作成した方が技術の蓄積も可能。
学習目的
- 優れたプログラマになるには、ゼロからの経験が不可欠。
  - この経験アップ⬆ために再作成するケースもある。

９．ヤクの毛刈り

ヤク（牛の一種）の毛は大量にあって、本体に到達するまで沢山の毛刈りが必要💦
問題に取り組む時、ヤクの毛のように別の問題に遭遇し～が永遠と続く…。
- この状態が長く続くと、元の問題が何だったのか忘れてしまう😱

トラブルは芋づる式

問題に取り組むと、永遠と芋づる式に別の問題が現れる。
トラブルに大きく時間が掛かる原因は、このヤクの毛を刈っている時間にある。
ヤクの毛を刈るのに、どれだけ時間が掛かるか見積もれず、ストレス負荷もアップ😵

👉解決策：早めに切り上げちゃおう！

「時間掛かってるな～」と思ったら、立ち止まって「何が目的だっけ？」を振り返る
目的からズレてたり、コストが見合ってない場合は、作業をストップ🛑
- 別の道を探したり、メンバーに相談する。
解決したら、次に他の人が困らないようにメモを残してあげよう📝
複雑なコードの読み書きも陥りやすいので、メモを取りながら作業するのがコツ！