はじめに
最近、「良いコード／悪いコードで学ぶ設計入門」を読んでいるので、本書の中で自分が疑問に感じたポイントをQ&A形式で振り返ってみたいと思います。
この記事では、各セクションの簡単な説明の後に、[Q]で疑問に感じたこと、[A]で調べてわかったこと、そして[NOTE]で覚えておきたいことをまとめています。
なお、サンプルコードにJavaを使用していますが、言語を問わず広く有効な設計手法なので、他言語でも応用できる内容になっています。
第13～15章については、すでに別の記事にまとめているので、こちらもぜひご覧ください！
それでは、第16〜18章を振り返りながら、一緒に「良いコード／悪いコード」について学んでいきましょう！
設計しないと開発生産性が低下する
変更容易性の設計をしないと、開発生産性が低下します。
低下要因は、大きく分けて2つあります。
要因1：バグを埋め込みやすくなる
- 関係し合うロジックがあちこちに散在しているために、仕様変更時に修正漏れが起きやすくなり、バグになる
- コードの理解が難しいために、実装ミスが起こりやすく、バグになる
- 不正値が容易に混入する構造になりがちで、バグが起こりやすくなる
要因2：可読性が低下する
- コードの見通しが悪く、読み解くのに時間がかかる
- 関係し合うロジックがあちこちに散在しているために、仕様変更に関連するロジックをすべて探し回る手間が増える
- 不正値の混入でバグが発生した場合に、どこから不正値が混入したのか追跡が困難になる
[NOTE]
ところで、なんのためにコードを変更するのでしょうか。
その理由はシンプルで、ソフトウェアの価値や魅力をより高めるために仕様を追加・変更します。
コードの変更容易性が高いほど、ソフトウェアの価値をすばやく高められます。
つまり、変更容易性を高めることは、ソフトウェアの成長性を高めることなのです。
設計効果を意識する
設計の前後で必ず効果（設計効果）を確認しましょう。
たとえばストラテジパターンは条件分岐の重複コードを削減する効果があります。
ストラテジパターンを使うなら、適用するコードが抱える課題とストラテジパターンの効果が一致するかを確認します。
一番良くないのは、設計効果を大して意識せず、構造だけをまねて満足してしまうことです。
問題解決にならないばかりか、逆に構造を複雑にしてしまって、問題が深刻化する場合すらあります。
[NOTE]
原則やデザインパターンは、あくまで「課題を解決するための手段」です。
本当に大事なのは、「パターンを使うこと」そのものではなく、「課題を解決できるかどうか」です。
まずは、目の前の課題を正しく理解することから始めましょう。
設計の良し悪しを説明できることがスキルアップにつながる
設計スキルを高めるために、説明力を高めましょう。
人はあまり理解していないことを上手く説明できません。
「スキルがある」とは、そのスキルを何度でも再現できることを意味します。
つまり同じような問題、似たような問題に直面した際、同様に解決できることがスキルがあると言えます。
[NOTE]
説明をするときにありがちなのが、設計の原理原則に反しているかどうかでとどまっているケースです。
このコードは単一責任原則に反しています。
この説明では、反した結果どのような弊害が生じるのかまで言及していません。
よくよく確かめてみると、実は弊害がなかった、ということがあります。
設計の原理原則ではなく、弊害を中心に説明できるようになりましょう。
この割引計算は、別の種類の割引に使い回されています。どちらかの割引の仕様が変更されると、もう一方の割引を正しく計算できなくなります。単一責任原則に反しています。使い回さず別々のロジックに分けるべきです。
おわりに
今回は、「良いコード／悪いコードで学ぶ設計入門」の第16～18章を題材に、自分が疑問に感じたポイントを紹介しました。
原則やデザインパターンは目的ではなく、課題を解決するために使う道具であることを意識しながら開発していきたいですね！
なお、「オブジェクト設計スタイルガイド」の1～3章の記事も公開しているので、ぜひあわせてご覧ください！