良い設計習慣をクイズで身につける！
第5章：習慣 要約＆クイズ

要旨

理由

結論

その他（詳細）

• 怠惰

  全体の作業量を減らすためなら、最初に手間をかけることをいとわない性格。
  • 毎回くり返す作業をマクロ化（自動操作）・生成（自動で作ること）・ツール化（専用の道具にすること）して、自動化／仕組み化する。

• 短気

  コンピュータがゆっくり動いたりサボったりするのがガマンできない性格＝コンピュータをできるだけ効率よく使おうとする姿勢。
  • 仕事を小さな単位に分けて同時実行し、CPUやサーバーなどの計算資源をフル活用してスループットを上げる。

• 傲慢

  高いプライドで美しく分かりやすいコードや設計を求める性格。
  • プロ意識を持ち、「他の人に見られても恥ずかしくない」成果物を作ろうとする。

• 注意

  「根性」や外からのプレッシャーだけでは、思考のスピードは上がらない。→ 長時間労働に頼らず、しくみや自動化で問題を解決することを目指す。

要旨

理由

結論

その他（指針）

• 急がば回れ
  • ユニットテスト（小さなテスト）を省略するのは避ける：その場は早く見えても、あとで手動テストが増えたり、変更が怖くなって結果的に遅くなる。
  • 目的に合わない既存システムのムリな流用は避ける：使い方が合っていないと、後で破綻（立ち行かなくなること）しやすい。
  • 不適切なライブラリ（用途が合わない部品）の放置は避ける：コードが複雑になり保守も難しくなって、どこかで破綻する。
• 小さな改善例：分かりやすい命名に変える／同じ処理の重複を減らす／関数として切り出す／コメントを整える／テストを1つ足す、など。
• 効果：保守しやすさと信頼性の向上、バグの再発（デグレード）のリスク低減、チーム全体の学びやすさの促進。

要旨

理由

結論

その他（範囲・手順・手段）

• 最適化の弊害
  • 可読性の低下：最適化後のコードは、最適化前より読みづらくなりやすい。
  • 品質の低下：読みづらいコードはバグを生みやすく、品質を下げる。
  • 複雑性の増大：処理のつながりが複雑になり、結合度が上がって移植性（他環境への持ち運びやすさ）も落ちる。
  • 保守の阻害：前提条件や「お約束」が増え、汎用性や拡張性が下がる。
  • 環境間の競合：ある環境では速いけれど、別の環境では逆に遅くなる、ということが起きる。
  • 作業量の増大：準備や検証が増え、結局は自分たちの仕事を増やしがち。
• まずは良いコード：情報隠蔽（内部の細かい部分を外から見せないこと）などの原則に沿って変更箇所を局所化しておけば、他の部分に影響を出さずに後から修正しやすくなる。
• コード以外の改善点：
  • 実行環境（サーバー・OSなど）
  • デプロイ／インストール設定
  • ミドルウェア（データベースやWebサーバーなど）
  • ライブラリ
  • 連携している他のシステム
  • アーキテクチャ（全体の構造・設計方針）
• 鉄則（手順）
  • ① 必要性を証明する（ユーザーからの指摘や、SLO（サービスの目標値）からのズレなど）。
  • ② 実際に計測してボトルネックを特定する（「推測するな、計測せよ」）。
  • ③ 見つけたボトルネックを最適化する（狭い範囲の修正にとどめる）。
  • ④ 再計測して、本当に改善されたか確認する。
  • ⑤ テストで、機能が壊れていないか（デグレードがないか）検証する。
• 手段：プロファイラ（どこに時間がかかっているかを調べるツール）を使う。例：Chrome のネットワーク/パフォーマンスタブなど。

要旨

理由

結論

その他（十戒）

• 自分も間違えることがあると素直に認める。
• 自分の書いたコード＝自分そのものではないと理解する。
• 自分より上手（うわて）が必ずいることを受け入れる。
• 相談なしの全面書き直しはしない（相手の意図を聞いてから進める）。
• 自分より経験の少ない人にも敬意と忍耐を持って接する。
• 唯一変わらないのは変化そのものだと理解する。
• 本当の権威（信頼される存在）は、地位や役職ではなく知識と実績から生まれる。
• 大事だと思う点ではきちんと自分の意見を主張するが、議論に負けたときは潔く結果を受け入れる。
• 一人で部屋にこもりきりにならず、チームとコミュニケーションを取る。
• 人にはやさしく、コードにはきびしく。批評の対象は人ではなくコードであることを忘れない。

要旨

理由

結論

その他（思考のコツ）

• いきなり正解を瞬時に出そうとしない。分からなくても、焦らず考え続ける。
• すぐに1つの結論へ飛びつかない。一度その結論を疑って、他の可能性も検討する。
• すでに考えたことをメモして覚えておく（同じところをぐるぐる考え続けない）。
• 書きながら考える（紙やホワイトボードなどに書き出すと、頭の中が整理される）。
• 直感もヒントとして使い、まず試してみる。ただし直感だけで決めず、あとで論理的にチェックする。

要旨

理由

結論

その他（指針・効果）

• まず、制約や評価基準（性能／可読性／保守性／コストなど）をはっきりさせてから、複数の案を比較する。
• プロトタイピング（試作）やスパイク（短時間の実験的実装）で、リスクの確認と学びを前倒しにする。
• その結果として、より適切で、長く使い続けられる解決策を選びやすくなる。