Magnolia Tech

いつもコードのことばかり考えている人のために。

「現場で役立つシステム設計の原則」を読んだ

細々と書き直したので、最初の公開の時とちょっと変わっています。


最近ようやくこの手の「良い設計」をちゃんと解説してくれる書籍が出版されるようになってきて、良い時代になったなぁ。データベースであればドメインを定義したり、正規化といった、ある程度定型的な観点が有る手法が有るので割と以前から良い設計に対するアプローチが明確だった気がするけど、アプリケーションになるとなぜか、あまり見かけなかった。

今までコードを書いたことが無い人が読んでも、今一つ納得感が無いような気がするけど、一度でも他人のコードの改修に苦労したことが有れば、発見が有る本。

全編に渡って素晴らしい知見が多いのだけど、まずはChapter1の「小さくまとめてわかりやすくする」だけでもしっかり読んだ方がいい。特に値オブジェクト重要。

値オブジェクトを使ったリファクタリングと機能追加を体験するだけでも、ソフトウェアの複雑さのコントロールについての一番大事なポイントが理解できるんじゃないかと。ソフトウェアの機能追加を安定的に行っていくためには、影響範囲をどうやって正しく特定するか?ということに尽きるんだけど、それが型レベルで追跡し易くなるだけで格段に楽になるし、想定外の値が混入していないことも保証されるので、安心できる。

複雑なソフトウェアに対するリファクタリングと機能追加をみっちりやる体験講座が有れば良いのに!

Chapter2以降も良い話が満載だけど、まずはChapter1を腹落ちするまでコードを書いた方がいいんじゃないかと。

良い設計を行うために

設計の話ということで、先日のBuildersconでしんぺいさんが発表された「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」というトーク本編とQAの中でとても良い言葉が有ったので、その話とリンクするのですが…

techblog.reraku.co.jp

スライドに出てくる「設計に正解は無い」という言葉と、QAの中で出てきた「良い設計か否かは機能追加するまで分からない」という言葉は大事だな、と。○○すればOKなんてことは無くて、未来にどんなことが起きる得るか、それをしっかり考えて(かつ、考えすぎず)その環境においてベストな設計を自らの意思で選択することが大事なんじゃないかと思うわけです。

あと「機能追加するまで良い設計か分からない」ということは裏を返せば、過去の機能追加で苦労した所をしっかり振り返っておけば、自分たちに必要な保守性や、拡張性はおのずと分かるハズです。