はじめに
「良いコード/悪いコードで学ぶ設計入門」を読み終えたので、要点をまとめていきます。
具体的な設計テクニックは割愛しています。書籍を読んでみてください。
本書の特徴
「ソフトウェア開発に潜む悪魔を知覚し、退治できるようになるための設計技術書」となっており、
保守性に関係する設計、特に変更容易性の向上を目的にした設計手法を取り扱っている。
設計とは
設計とは、「課題を効率的に解決するしくみづくり」のこと。
画面設計書やビジネスロジック設計書といったドキュメントを作成することでもなく、
このテーブルからデータを取ってきて、あのテーブルへ登録して...といった処理の流れを定義することでもない点は注意。
経験上、大規模な業務システムに長年携わっていると、設計の定義を誤認すると感じた。
設計をないがしろにすると起こる弊害
- コードを読み解くのに時間がかかる
- バグを埋め込みやすくなる
- 悪しき構造がさらに悪しき構造を誘発する
弊害の代表例
意味不明な命名
技術駆動命名(Int, Memory, Flag...)や連番命名(001, 002, 003...)は意図がまったく読み取れない。
スプレッドシートなどを用いた対応表はメンテナンスされなくなっていく。
条件分岐のネスト
見通しが悪い
データクラス
データ(インスタンス変数)を保持するだけのクラスで、ロジックは別のクラスに実装されることが多い。
ゆえに、重複コード、修正漏れ、可読性低下、未初期化状態(生焼けオブジェクト)、不正値の混入が生じる。
設計パターン
| 設計パターン | 効果 |
|---|---|
| 完全コンストラクタ | 不正状態から防護する |
| 値オブジェクト | 特定の値に関するロジックを高凝集にする |
| ストラテジ | 条件分岐を削減し、ロジックを単純化する |
| ポリシー | 条件分岐を単純化したり、カスタマイズできるようにする |
| ファーストクラスコレクション | 値オブジェクトの亜種で、コレクションに関するロジックを高凝集にする |
| スプラウトクラス | 既存のロジックを変更せずに安全に新機能を追加する |
「値オブジェクト＋完全コンストラクタ」は、オブジェクト指向設計の最も基本形
エンジニアの資産とは
エンジニアにとっての本質的な資産とは技術力にほかならない。
レガシーコード(変更が困難で壊れやすいコード)は資産の蓄積、すなわち技術力の成長を妨げてしまう。
主な理由は以下の通り。
- レガシーコードは、レガシーコードの書き手を育ててしまう。
- レガシーコードは、アンバランスでトリッキーな実装であることが多く、設計改善が非常に困難。
納期等の都合により、設計改善を諦めることになり、設計実装の経験を積めなくなる。 - レガシーコードは、理解に多大な時間を要する。
本来もっと価値の高い仕事に充てられるべき時間が目減りする。
設計スキルを高める学び方
インプットは２、アウトプットは８
設計効果を必ず意識すること
悪魔退治の旅に出かけよう
弊害を知る
↓
「何か対処しなければ」という意思が生まれる
↓
意思が、設計を良くするためのすべてのはじまり