記事を書く目的
情報をインプットしてアウトプットする練習のため、毎週本を読み理解したことや気になったことをまとめてみようと思い、投稿します。
以下記載する内容は個人の見解であり、内容が正しいかどうかは保証できないことをご理解ください。
進め方
私は新しい本を読む時、その本の目次を先に読み気になることを質問にまとめています。
以下では、その質問に回答する方針で進めたいと思います。
Q. 良い設計とは？
良い設計とは、ETC原則が守られている設計である。
ETC原則とは「Easier To Change」の略語で、つまり「変更がしやすい」という意味である。
ソフトウェア開発において変更がしやすい設計が良いと考えられている背景には、
ソフトウェアが常に変わりゆくものであり、開発者は常にソースコードを修正し続ける必要があるという考えがある。
つまり、開発者にとってソースコードに修正を加えやすい設計が、良い設計であると考えているということである。
さて次に、ETC原則を具体的に噛み砕いた原則をいくつか紹介したい。
DRY原則
DRY(Don’t Repeat Yourself)原則とは文字通り「繰り返しを避けよ」という原則である。
少し意訳すれば、「重複を排除せよ」となる。
なぜDRY原則がETC原則に通ずるのか、具体的にソースコードを修正する場面を考えてみる。
例えば、仕様の変更に伴いソースコードを修正する場面に遭遇したとする。
同じ修正内容を複数箇所で行わないといけないとなると、
修正することへのコストが増えまた、修正をし忘れるということのリスクにもつながってしまう。
つまりDRY原則とは、同内容の修正は一つに集約しメンテナンスを行う際の容易性を上げようということなのだ。
直交しているシステム
直交性とは、片方を変更しても他方に影響を与えない特徴のことである。
直交しているシステムとは、片方を変更しても他方に影響を与えない特徴を持つシステムということである。
例えば、直交していないシステムの場合にどのような弊害があるか考えてみる。
ある機能Aについての仕様変更があり、機能Aについてのソースコードを修正した。
その結果、仕様通り機能していた別の機能Bで不具合が出てきてしまった。
このような設計になっていると、機能Aだけの仕様変更のために機能Bが今までの仕様要求を満たしているかどうかを常に気にしながら実装しなくてはいけなくなってしまうだろう。
加えて、実際の開発の現場では機能が2個しかないシステムなど無く、その他数十~数百の全ての機能を気にしながら開発するのはとても開発効率が悪い。
つまり、直交しているシステムを作る原則とは、ソースコードを修正する際に関心を一つにとどめれるような（別のことを気にしなくても良いような）設計にしようということである。
また、表現を変えて、凝集度の高いコンポーネントを設計するべきであるとも主張している。
凝集度が高いとは、自己完結（独立）して、他のコンポーネントに依存していないという意味である。
コンポーネントが独立していることで（ほとんど直交していると近い考えであると理解しているが）、他の部分を気にせず変更することができるのだ。
感想
- 本書の中で、偶発的プログラミングをアンチパターンとして取り上げていた。
偶発的プログラミングとはなぜ動くか説明できないコードを実装することである。私は偶発的なプログラミングをしがちだなので、耳がとても痛い話でした。。 - 直交性の話の中で、目の前のシステムが直交的かどうか判断するには、
「特定コンポーネントの要求が大きく変化した場合、どれだけ多くのモジュールに影響が及ぶか」という質問を投げかけると良いと書いてあった。例えば、私（あなた）がフロントエンドの開発の責任者で顧客に、Webページからスマホのアプリケーションにしてくれと急遽言われたとする。その時、私（あなた）は、変更のしやすい設計にしているだろうか。例えば、ロジックとUIが分離されていてUI部分だけ差し替えれば良い設計になっているだろうか。データアクセスする処理を修正したら、ボタンの色が変わることはないか（そんなことはないと思うが。。笑）、など思考実験をしてみると良いのかなと思いました。
来週読む予定の本
おしまい。