釣りキチプログラマー翔平の備忘録 
はじめに
この記事では、
現場で役立つシステム設計の原則を読んで以下についてまとめました。
- 本を読んでから自分が設計やプログラムを書くの際に意識するようにしたこと
- 変更を安全に素早く行うための重要な考え方
- 意識が足りずに悲惨な目に遭った経験談
リリース後の保守開発を見据えた、
良い設計スキルを身につけるポイントでもあるので、
特に駆け出しエンジニアやプログラマーの方に
参考にして頂ければ幸いです。
現場で役立つシステム設計の原則を読んで
1章の中で特に重要だと感じたポイントは以下です。
- 小さく分ける命名をする
- 値の範囲を正確に表現する
- 予期せぬ副作用をなくす
自分が面倒見てるプロダクトへの参画者にはまず
この辺りの基本を最低限理解してもらってから、
開発作業を任せるようにしていこうと考えています。
今年から新卒の新入社員に向けても僕が講義することに・・・
詳細はこちらの記事にまとめています。
命名と小さく分けることの関係と重要性〜ソフトウェア設計のきほん〜
業務で扱う値の範囲を正確に表現する〜ソフトウェア設計のきほん〜
2章は〇〇区分、〇〇種別・・・などが業務要件のなかで出てきて、
〇〇区分がこれでなおかつ、〇〇種別がこれの場合はこうするみたいなことは複雑になりがち。
それをどう整理するか？？というテーマの章でした。
特に重要だと感じたのはこの辺りです。
- 条件分岐は単文でなおかつ早期リターンで
- 区分毎にクラスを分けてさらに多態にし、区分の違いをifを使わずに表現
- 区分毎のロジックを列挙型で整理
区分毎にクラスを分けて多態を使ってさらに列挙型にちておいて複雑な分岐をなくしていく。
という考え方は僕の中になかったのですが、早速現場で取り入れてます。
この章詳細はこちらの記事にまとめました。
3章は業務ロジックが至る所にちらばってしまう原因と、
その対策として業務データとロジックを１箇所に集めるドメインモデル方式について書かれていました。
特に重要だと感じたのはこの辺りです。
- クラスをデータの入れ物と捉えるのではなく業務ロジックの置き場と捉える
- パッケージの設計も重要！！パッケージプライベートで依存関係を制御する
自分が設計をする際は、
業務データ＋ロジックの置き場を整理していくイメージで
進めるようにしています。
この章の詳細はこちらの記事にまとめました。
4章は仕様変更時に変更をシンプルで安全にするための考え方や、
ドメインモデルの設計の進め方だったり、
業務知識の整理のやり方などなどについて説明されていた章でした。
特に重要だと感じたのはこの辺りです。
- 業務を理解するための分析とソフトウェアを実現するための設計が一体になった活動がドメインモデルの設計
- 業務で使われる言葉とクラスやメソッドを一致させる
- ドメインオブジェクトを見つけるには業務の関心事の「コト」に注目する
- ドメインオブジェクトは一度作って終わりではなく洗練させていくもの
業務を分析〜業務ロジックの置き場を整理〜作る
を何度も繰り返して洗練させていく作業をまさに今自分は現場でやってます。
やってみると、
作ってみてはじめてわかる事もあるという事が分かったり、
最初の分析でいきなり完璧に分析しきるのは難しいという事も分かりました。
この章の詳細はこちらの記事にまとめました。
現場で役立つシステム設計の原則第４章を読んで｜気付きや今後参考にしたいことなどをまとめてみました
5章はドメインモデルで設計したドメインオブジェクトを組み合わせて、
１つの業務サービスを実現するアプリケーション層のサービスクラスを作る際、
なぜごちゃごちゃしがちなのか？？その対策としてどういう設計思想が重要なのか？？
についてまとめてある章でした。
特に重要だと感じたのはこの辺りです。
- サービスクラスがごちゃごちゃする原因はドメインオブジェクトが機能していないかDBや画面に振り回されるから
- サービスクラスに業務ロジックを書きたくなったらドメインモデル改良の機会
- データベースの具体的な操作と業務の関心事とを分けて考える
- サービスクラスでも部品とそれを組み合わせるという考え方を持つ
ドメインオブジェクトを使う側のサービスクラスは常にシンプルに！！
を僕も最近は現場で心がけています。
この章の詳細はこちらの記事にまとめました。
現場で役立つシステム設計の原則第５章を読んで｜気付きや今後参考にしたいことなどをまとめてみました
6章はデータベース設計における悪い設計と良い設計についてと、
ドメインオブジェクトとデータベース設計は別物として考えるべき
というような内容の話が中心の章でした。
特に重要だと感じたのはこの辺りです。
- 悪いテーブル設計は取り扱う際の暗黙の知識が大量に必要
- 事実を記録するのがテーブル設計の基本
- ドメインオブジェクトの設計とテーブルの設計は別物
僕も現場で暗黙の知識が大量に必要なテーブルに遭遇することが多く。。。
すでに動いているシステムをテーブル設計から変更するのが大変なので
放置。
のようなケースは良くありました。
少なくとも今後新規で自分が設計するものはそういうことをしないようにしたいです。
この章の詳細はこちらの記事にまとめました。
現場で役立つシステム設計の原則第６章を読んで｜気付きや今後参考にしたいことなどをまとめてみました
8章はAPIのインタフェース、１本のAPIの役割を大きくしすぎない工夫について述べられていました。
特に重要だと感じたのはこの辺りです。
- アプリケーション間の連携パターン４つについて｜ファイル転送〜API連携〜メッセージングなど
- RestAPIはPOSTやGETを使いPUTやDELETEは極力使わない
- 大は小を兼ねるAPIはAPI提供側・利用側共に不幸になる
大は小を兼ねるAPIは現場でよく見かけるので、
今後はそっちの方向に行かないように注意したいと思います！！
この章詳細はこちらの記事にまとめました。
現場で役立つシステム設計の原則第８章を読んで｜気付きや今後参考にしたいことなどをまとめてみました
9章は要求分析と設計を同じチームや人でやることのメリットについての
話が中心の章でした。
特に重要だと感じたのはこの辺りです。
- 昔求められたものと最近求められるものとの違い
- 要求分析と設計を１チームで行えば品質が上がり、ドキュメントが減らせ、開発スピードが上がる
- 契約は準委任契約で、業務にも関心が持てるメンバーで体制を組めるとベスト
昔と今の求められていることの違いを理解し、
今求められていることに対して効率よく、品質よく開発を進めるための工夫としては何ができるのか？？
を考えなければなとこの章を読んで改めて思いました。
この章詳細はこちらの記事にまとめました。
現場で役立つシステム設計の原則第９章を読んで｜気付きや今後参考にしたいことなどをまとめてみました
まとめ
本を読んで、
現場を、システム開発の設計〜製造〜テスト工程を経験して、
既存システムの課題にぶち当たったり、
新規システム設計の時の試行錯誤を経験した人がこの本を読むと
とても学びがあるだろうなと感じました。
この本を読んで実践できる人がシステムの設計をしてくれてたらどれだけ
保守開発楽だったかなと。。。。
自分自身、
現場で学んだことを取り入れたり、
現場の課題を本で学んだ視点で見つけて対策打ったり
しています。
自分の場合２〜３年目くらいにこれを読んでおきたかったなと、、、
