ソフトウェア設計
ソフトウェアの設計手法に関わる記事につけるタグ
/icons/hr.icon
そもそも設計とは？
サンプルコードを設計原則に照らしつつ、設計/実装/検討のサイクルをまわしていくケーススタディ
統一した基準を使ってコードの品質を上げていくプロセスを追体験できる
self-containedで読みやすい。とりあえずこれを読むと「ソフトウェア設計」がどういう行為かわかるkadoyau.icon
以下は自分用のメモ
https://gyazo.com/33be3dd2074595a8bd911017ca84275d
ケースバイケースなのは当然。でも、どうやって個別のケースに対して適切な設計を判断すればいいのか？ Aパート：このコード、なにがあかんの？
武器
https://gyazo.com/88377625cc9fe1c211ab5b53eb8d907b
分割の選択肢を増やす
取りうる手法の引き出しを増やす
その分割が今扱っている問題に対して正しいかの大雑把な指針
「なんであかんのか」を言語化するための経験的な根拠
レビューに使う
設計原則でコードの良し悪しを判定する
凝集度は高く
結合度は低く
設計/レビューを繰り返して、自分たちの問題を解決するより良い構造を探り出すkadoyau.icon
Bパート：このあかんコード、どう修正するの？- 何度も繰り返し検討する
パターンを適用した後、上記3つの原則に照らしてみる
一見責務が多いが、コメントが変わるときはすべて変わる（つまり本質的に責務が大きい）という考察の結果導き出された前提があるので単一責任原則を満たすと考えているkadoyau.icon
この判断をどうするかは、ドメインの理解度に依存するkadoyau.icon
が、凝集度と結合度について考えると凝集度が低いと判断
「ビジネスロジックがどうかわるか予測」してみると無駄に分割されていると判断
「コメントに対して通知が変わらないことなんてない」と判断できるかどうかはケースバイケースkadoyau.icon 変更に対して無駄に強くなっているが、使われないだろうし、大幅な変更の際には見落とす可能性が高まる
さらに修正する：Observerパターンを捨てる
Cパート：問題が変われば、設計原則を使った結果は変わる
変更されやすい/にくい構造を見極めるのが大事
見極められないとこういう破綻が起きる
変更されないところを変更されると仮定したり
変更されやすいところを変更されないと仮定すると
見極められない場合はシンプルにしておく
問題を捉えそこねるとこうなる
https://gyazo.com/7d26279d38ec76bed49c378d6ea136ae
質疑