現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 を読んだ
現場のコード以外からもインプットを取れるようにしたくて、とりあえず自分がどの程度基本を把握できているか立ち返るために買ってみました。
評価をつける目的ではなく読んでみての感想なので、中身がどんな本かに興味がある人には誤解を与えてしまう内容が含まれている可能性があるので留意ください。
序盤の方にあるコードそのものの書き方に対するガイドラインは特に違和感なく読めました。
ただ、 `データとロジックを別のクラスに分けることがわかりにくさを生む` の項以降は少しずつ自分の感覚と違うものがありました。関数型言語のトレンドからすると違和感のある主張、ということなんでしょうか。以下本当かな？と思ったポイントです
データと振る舞いを一箇所にまとまったほうが良いのは多分そのとおりだけど、見通しが良くて粒度と一貫性を保ったクラス設計を保ったままできるかな？必ずしもビジネスロジックとデータを結合させる必要はないような気もする
「インスタンス変数を使った何らかの処理をするのが正しい姿」という主張は、インスタンス変数が状態を持てるのが少し嫌な感じがしていて、変数の状態でパターンを出すよりも引数でパターンを列挙するほうが容易に網羅性高いテストが作れて安全だと思う
フィールドが増えたらクラスを小さく切り分けるという主張は正しそうだけど、住所を表すものだからひとまとめにしましょう、と言うのは本当に良くなっているのかな？見かけのコード行数が減って単純に見えるのはメリットっぽいものですが、その中に独自の振る舞いがあって切り出すことに意味があるときだけやったほうが良さそう(本文中ではそういうロジックが当然ある前提でやってるのかも)
例外が存在しない前提で話が進んでいってデータに対してガンガン制約を加えていくのがちょっと怖く感じた。出荷って一切の例外なく必ず対応する注文が存在する前提を敷いて大丈夫なの？とか。設計中に制約を全部発見できる前提なんだろうか
特にDB設計がかなり攻めてるなと感じて、外部キー制約もユニーク制約も当然とても大事なんだけど動かしてからモデリングをミスってた場合に受け身を取る選択肢をガッと狭めてしまう(システムを止めずに対応できなくなる場合がありそう)ので、「制約がないのはおかしい」とまで言い切るのはちょっと言葉が強いなと感じた
UPDATE禁止も言い切るのも強すぎて、パフォーマンスとのバランスを考えることもあると思うけどそっちのが良いと断言しちゃうのはこわい
数値だったら何でもかんでも符号付きintカラムにするもんじゃないよ！というのも正しいけど、「現実的な桁数を指定しましょう」という判断は危険だと感じた。感覚で決まるのではなく、上限もビジネスロジックがありそうって思った
非同期メッセージングに対する評価が高いけど、複雑でテストが難しいものなのでこれこそ真に必要なときにだけ使ったほうが良いと思う
APIでPOSTとPUTを使い分ける議論で、リクエスト側に相手先のIDの知識があるかどうかで使い分けよという主張をしているが、それよりも冪等性のほうが重要な考慮要素だと思った。リクエストを送った相手方がどう受け取ったかに興味がないというのはありえないと思ってしまったのだけど、削除要請についても似た主張なので着眼点が自分と違うなと感じた
「XMLはメタ情報や属性を使えてJSONより表現力が広いので楽で安全」は少し疑問。APIのスキーマ変更に対する記述は標準化されていないので、メタ情報やらアトリビュートになにか書かれたとして安全に取り扱ってくれる保証がなく、別に優位性を得ていないと思った
名前と性別をそれぞれ別APIで取得させる設計はシンプルにやりすぎだと思う
APIが返す日時をhuman-readableにした方がいい主張も違和感がある。日時の表現をISO8601にするのはプログラミングの関心事であって人間の関心ではないという主張だけど、APIという存在自体がそもそも人間が見る想定をしていないプログラミングの関心事なので、プログラミング的に都合の良い表現にするほうがむしろ一貫していると思う
2017年の本なので、5年分のトレンドの変化で少し現代に合わない記述があるのかなと全体的に感じました。
ただ触れたことのない領域には新鮮なことが結構描いてあって、特に普段はゲーム制作をしているので既存業務のモデリングは経験がなく、そうなんだ～って感じでビジネスロジックの発見をするあたりの項を読めました。
あとAPIを基本、拡張、個別対応に分類するのはおもしろい着眼点でした。大規模SaaSとかでやってそう。やめたいけど一部のユーザだけ使ってるから渋々残してるやつを明確にマーキングするのは良さそうですね。
この記事が気に入ったらサポートをしてみませんか？