このあと追記していきます…。
期待していること
- よくない設計やコードのパターンを知り、本業の開発に活かしたいです。
- 仲間と読むことで、同じ目線を持てればなおいい感じです。
はじめに
- 設計や実装上の問題を「悪魔」にたとえ
- わかりやすいけど、そのまま職場で使うと軋轢を生みそう…。
- ただパターンに名前をつけて、チーム内で議論しやすくする効果もあると思うので…。
- 実世界では気をつけて使いたいです。
8 密結合 ―絡まって解きほぐせない構造―
8.1 密結合と責務
Column クソコード動画「共通化の罠」
8.2 密結合の各種事例と対処方法
Column クソコード動画「継承」
9 設計の健全性をそこなうさまざまな悪魔たち
9.1 デッドコード
9.2 YAGNI原則
9.3 マジックナンバー
9.4 文字列型執着
9.5 グローバル変数
9.6 null問題
9.7 例外の握り潰し
9.8 設計秩序を破壊するメタプログラミング
9.9 技術駆動パッケージング
9.10 サンプルコードのコピペ
9.11 銀の弾丸
10 名前設計 ―あるべき構造を見破る名前―
10.1 悪魔を呼び寄せる名前
10.2 名前を設計する―目的駆動名前設計
10.3 設計時の注意すべきリスク
10.4 意図がわからない名前
Column 技術駆動命名を用いる分野もある
10.5 構造を大きく歪ませてしまう名前
Column クソコード動画「Managerクラス」
10.6 名前的に居場所が不自然なメソッド
10.7 名前の省略
11 コメント ―保守と変更の正確性を高める書き方―
11.1 退化コメント
11.2 コメントで命名をごまかす
11.3 意図や仕様変更時の注意点を読み手に伝えること
11.4 コメントのルール まとめ
11.5 ドキュメントコメント
12 メソッド（関数） ―良きクラスには良きメソッドあり―
12.1 必ず自身のクラスのインスタンス変数を使うこと
12.2 不変をベースに予期せぬ動作を防ぐ関数にすること
12.3 尋ねるな，命じろ
Column クソコード動画「カプセル化」
12.4 コマンド・クエリ分離
12.5 引数
12.6 戻り値
Column メソッドの名前設計
Column staticメソッドの扱いに注意
13 モデリング ―クラス設計の土台―
13.1 邪悪な構造に陥りがちなUserクラス
13.2 モデリングの考え方とあるべき構造
13.3 良くないモデルの問題点と解決方法
Column クソコード動画「Userクラス」
13.4 機能性を左右するモデリング
14 リファクタリング ―既存コードを成長に導く技―
14.1 リファクタリングの流れ
14.2 ユニットテストでリファクタリングのミスを防ぐ
14.3 あやふやな仕様を理解するための分析方法
14.4 IDEのリファクタリング機能
14.5 リファクタリングで注意すべきこと
Column Railsアプリのリファクタリング
15 設計の意義と設計への向き合い方
15.1 本書はなんの設計について書いたものなのか
15.2 設計しないと開発生産性が低下する
15.3 ソフトウェアとエンジニアの成長性
15.4 課題を解決する
15.5 コードの良し悪しを判断する指標
Column クラスを分割すると読みにくくなる？
15.6 コード分析をサポートする各種ツール
Column シンタックスハイライトを品質可視化に利用する
15.7 設計対象と費用対効果
15.8 時間を操る超能力者になろう
16 設計を妨げる開発プロセスとの戦い
16.1 コミュニケーション
16.2 設計
16.3 実装
16.4 レビュー
16.5 チームの設計力を高める
17 設計技術の理解の深め方
17.1 さらにステップアップするための設計技術書紹介
Column バグ退治RPG『バグハンター2 REBOOT』
17.2 設計スキルを高める学び方
Column C#と長き旅，そして設計への道
全体を通して
- 「悪しきコード」「クソコード」…こういった言葉はあんまり好きじゃないです…。
- 安易に使うと、人を傷つけそう…。
- …とはいえ、言い換える言葉を思いつかないです…。
各章のつながりが強くなく、かつ、ちょっと違う切り口で何度か出てきます。じっくり読んでだんだんと知識を積み上げる形より、思いついたときにつまみ食いして、「せやったせやった」としてもいいかもしれません。
- 会社やチームで1〜2ヶ月くらいごとに1章分くらいをネタに議論するとかいう使い方もいいかも…？
全体的によい本だと思いました。
