WEB+DB PRESSは毎号買っているが、今月は特に気になるトピックが多かった。
特に特集1の『実践リファクタリング 凝集度と結合度を学び，保守性と生産性を高める』の2〜4章が印象に残ったため感想を書いていく。
凝集度と結合度の由来解説ありがたい
凝集度と結合度、名前と詳細な考え方は聞いたことあるけど…というレベルの理解だった。第1章で「構造化プログラミングにおける設計理論」であることが説明されており、由来を初めて知った。また、構造化プログラミングという単語は恥ずかしながら「基本情報技術者試験の参考書で出てきた…？」レベルの理解だったので、なぜ必要なのか・目的が解説されていたのが大変ありがたった。
定期的に「goto（コードジャンプ）は良くない/必要に応じて使うのはいい」みたいな話でTwitterが燃える気がするが、擬似コードとフローチャートでgotoが複雑になることを示されると「そりゃ読むの嫌だよね」と感じることができた。
returnやbreakもコードジャンプの一種というのを初めて知った。自由にコードジャンプできてしまうと飛び先が無限大となり、保守できないコードになるが、制約があれば飛び先が推測できる。なので全部が悪いわけじゃないよね。という考えなのかなと思った。
論理的凝集はやりがちなので気をつけたい
時間的凝集は関数使いまわせた方が良いから分けておこう、と実感できる。ただ、引数のフラグで処理を分岐させる論理的凝集はよかれと思ってやりがちだなと思った。自分も「関数・コンポーネントが乱立すると辛いからフラグやpropsで内部分岐すればいいか」と考えてしまうことが多かった。処理を細かく分け、それを集約する方が再利用性が高いので今後は可能な限り避ける設計にしたい。
ただ、APIレスポンスパラメータなど外部から受け取ったデータに応じて処理を分岐する必要がある場合、どのように論理的凝集を避けるべきなのだろうという点は疑問に思った。フラグに応じて変わる処理の変わる処理の部分を関数化しておく。フラグによる分岐はパラメータを受け取る関数で実施し、その関数から変わる処理の関数を呼び出すとかなんだろうか。
印象に残った文章
すべての状況で凝集度と結合度の観点だけで問題を解決できるわけではありません。（p15）
銀の弾丸はないよという話。何か新しい知識や技術を知ると、それを"ありとあらゆる全て"に適用してさらにメチャクチャになる…っていうのが良くある。強制的に進めると周りの人が疲弊してさらに辛くなるやつなので、本当に気をつけないとな〜と思った。ドメイン駆動設計とかもこの類な印象がある。色々な観点を知り、状況に応じてメリット・デメリットを比較して適用するか決めるのが重要なんだよな。
クライアントサイドの論理的凝集のリファクタリング（p31〜32）
文章ではなく節のタイトルだけど、設計の話をするときの具体例はアプリケーションロジックなど、バックエンド領域のコードがほとんどなので印象に残った。React.jsのコンポーネントが例になっていて、コンポーネントの分割にも凝集度の観点が取り入れられるんだなと感じられるし、フロントエンドも仲間に入れてもらえて嬉しかった。
凝集度と結合度は次のリンクでも言及があった話だけど、WEB+DB PRESSはさらに詳細やコード例も記載されている。合わせて読むと理解が深まってよかった。
WEB+DB PRESSは紙本を定期購読してるんだけど、fujisanで定期購読できる雑誌はどれも面白そうだよな。家が無限に広かったら全部買ってそう。
