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

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

増田さんが書いた「現場で役立つシステム設計の原則」を読んだので、感想を書いていきたいと思います。

読んだきっかけ

会社の新卒3～4年目を対象とした研修で、勧められたのが直接的なきっかけです。
技術力の低さが自身の一番大きな課題と捉えていることも、読んでみようという気持ちに拍車を掛けました。

この本を通して学べた知識

この本を通して学べたことについて、箇条書きで記載していきます。

• 業務の関心事を整理するコツ(業務で意思を持って行動するヒト/ヒトが業務を遂行していく上で関心を示す物理的・概念的なモノ/ヒトの意思決定や行動の結果を示す͡͡͡コトの3つを意識して整理する。整理の主軸にはコトを据える)
• 拡張用カラムの副作用(カラムの使用用途が分からず、様々な使い方がされて保守性を大きく損ねる)
• カラムにNULL値やNULL逃れ値(unknown, 9999, dummy...)が入ってはいけない理由(業務のコトを管理するのに、起きた事実が記録されていないのはおかしい)
• タスクベースのユーザインタフェースの長所(必要な時に必要な情報だけを操作できる、ユーザの関心事を分析することができる)
• アプリケーション連携を非同期メッセージングで行うメリット(アプリケーションの独立性を高められる、通信先のアプリケーションの状態への依存度を下げられる、メッセージング基盤にデータ加工の責任を担わせることでアプリケーションの構造を単純化できる、実世界のメッセージング(例えばLINEのグループと電話の関係など)と概念が近いので直感的に修正/拡張ができる)

また、既に他書籍だったり先輩からの指導で知っていたものの、本書で改めて有用性を確認できた知識についても箇条書きで記載していきます。

• 値オブジェクトの有用性
• コレクションオブジェクトの有用性
• 区分ごとのロジックを分かりやすくする工夫(ガード節、ポリモーフィズム、列挙型の活用)
• データクラス(DTO、Entityクラス)の危険性
• 業務ルールを考える時は、起きていいことだけではなく起きてはいけないことも考慮する
• 変更を楽で安全にするために、業務知識はソースコードで表現する
• 一度に完璧な設計を求めずに繰り返し設計をする
• サービスクラスに業務ロジックを書かないようにする
• データ操作を隠蔽するメリット
• 分析工程と設計工程を分割するデメリット

感想

全体的に解説が丁寧でした。
コードの例も多く、レイアウトや本の構成も含め、とにかく読みやすかった印象です。
第十章(最後の章)でオブジェクト指向に対する理解を今後深めていったりチームに広めていくための参考文献や具体的な行動例が、他の書籍と比べても充実した分量で言及されているのも好印象でした。
オブジェクト指向の入門書としては勿論、ある程度年次を重ねている人でも、実際に現場でレガシーコードにぶちあたり苦労している自分のようなエンジニアが読むと刺さる内容が多いのかな、と思いました。
個人的には、データベース設計とUIデザインに関する基礎知識が足りないことを痛感したので、他の書籍で改めて学習を進めていこうと反省しました。