はじめに
技術書『現場で役立つシステム設計の原則』を読んだので、感想や学んだことのまとめ。
書籍について
著者：増田 亨 @masuda220
全体の印象
とても読みやすい。
システム設計の書籍ではあるが「○○の法則」などのとっつきにくい言葉はほとんど使われていない。
実際の現場でよくあるコードや状況から、それは何が原因なのか、どのように解決するのか、という構成になっているので設計に関する書籍の中では読みやすいと思う。
また章立てについて、最初は変数や数行のコードについて話から、クラス設計、データベース設計、画面設計、アプリケーション連携経て、開発プロセスに進む構成になっている。
これにより、システム設計は単にコードを書いたりクラス図を作ったりするものではなく、開発プロセスまでも含めた一連の活動ということが意識される構成だと感じた。
学んだこと
データとロジックを１つのクラスにまとめる
これまで「データがシステムの主役」という考えからデータを中心に設計をしていたが、結果として業務ロジックが整理されていない状態になっていたと思う。
データを正確に定義することと同じく、それを扱う業務ロジックも含めてこそ価値が生まれるのだと学んだ。
データベースはコトを記録する
イミュータブルなデータベース設計に触れる機会がなかったので、考えを広げるヒントになった。
選択肢として活用できるよう、理解を深めていきたい。
疑問点など
削除はDELETEではなくPOSTで依頼する
DELETEを要求する側と応答する側に、削除に関するさまざまな決め事が必要になります。
決め事が必要になるものというイメージがあるので、それぞれの違いがイメージしきれない。
プログラミングの専門知識がなくても業務の知識があれば、進捗を適切に判断できるようになる
実際の現場でどのようにやっているのか知りたい。
まとめ
「とりあえず動くコードを書けるようになった」という人にお勧めしたい書籍。
大抵はそこから先の良いコード・良い設計へ小さなステップで向かえる道は無く、相当な努力をして辿り着くか、あるいは苦しい開発を受けれてしまうのではないだろうか。
この書籍はそこから次の段階へ向かうのに受け入れられ易いと思う。
とはいえ後半の部分は環境によるところが大きい。
例えば画面はシステム開発とは別の人・工程で作られていることがあり、そういう環境では「変更を困難にしている」という認識も無いと思う。
システム開発が単なるエンジニアの業務や手続きという位置付けだと、こうした問題がなかなか認知されない。
これについてはモデリングなどを活用して見える化することで解決の足がかりにできるのではないかと期待している。