釣りキチ翔平の備忘録 
はじめに
現場で役立つシステム設計の原則第１章 ちいさくまとめてわかりやすくするを読んで、
今まで現場で設計をしてきた自分の観点で、
特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。
現場で役立つシステム設計の原則第１章を読んでの気付きなど
まず、この章のタイトルに
ソースコードを整理整頓して、どこに何が書いてあるかわかりやすくすることが設計の基本です
現場で役立つ設計の原則 第1章(増田 亨)
このように書かれていました。
これを設計の基本だと捉えて設計をしている人はどれくらいいるのだろうか。。。。が気になりました。
自分の場合はドメイン駆動設計の勉強をするまでは、このような設計の基本を理解できていませんでした。
機能、性能の要求をみたせて無駄なリソースを使わないところばかり意識して設計をしており、
それが設計の基本であり全てくらいに考えていたからです、、、
タイトルのところに小さくさりげなく書いてありましたがここは自分にとっては気になるポイントでした。
変数名など名前をわかりやすくするのは当たり前で簡単だけどやはり重要
変数などの名前はわかりやすくつけるべき！！という記載がありました。
普通のプログラマの普通の設計という勉強会でも同じような話がありました。
ちなみに普通のプログラマの普通の設計(勉強会)に興味のある方はこちらに内容をまとめていますので参照ください。
「普通のプログラマの普通の設計」(勉強会)に参加してみた感想
変数名を見て想像ができるのか、結局わからないからソースコードを追う必要があるのかは大きな違いです。
プログラムの意図をわかりやすくするという意味で重要なことだと思いました。
当たり前で簡単なことだけど徹底するのは難しい。。。。。
メソッドを短くクラスを小さく
そもそも、長いメソッドが悪い理由はこれらが挙げられると本に記載されていました。
- いろんな関心事が混ざりがちで複雑になる
- いろんな関心ごとが混ざると使いまわせない(結局同じことを別の場所でもすることになる)
逆にいうと、とにかく短くすれば良いというわけではなく、
このポイントを理解した上でメソッドを短くする必要があります。
１つの関心毎に特化した単位でメソッドやクラスが分割できると、
他の場所でも使い回すことができ、仕様変更に伴う修正対象はその１箇所に限定することができます。
これが、メソッドを短くクラスを小さくする理由だと自分の中では理解しました。
こんなイメージかな・・・
副作用をなくすために・・・
副作用はとあるメソッドを呼び出すと、とあるオブジェクトの中身が書き換えられてしまうような事象です。
もし副作用があるとてつもなく長いメソッドがあった場合、
このタイミングではオブジェクトはどの状態で、どのタイミングで副作用が発生して、どの状態に変わる？？
といったことに怯えながら開発を進めなければなりません。。。。
そうならないために、副作用をなくす工夫をしましょうね。
というのが副作用の目的だと僕は理解しています。
こんなイメージかな・・・
副作用をなくす方法として
値オブジェクトの利用やコレクションオブジェクトと値オブジェクトの組み合わせが本では記載されていました。
値オブジェクトの方は、
setXXX()メソッドを廃止して、値をセットできるのはインスタンス化の時のコンストラクタだけにする。
それによって一度インスタンス化されると属性が更新できなくできます。
値オブジェクトは他にも
例えば取り扱う金額をintで表現して
マイナス21億〜プラス21億といった業務で扱う必要のない金額を表現できないように、
コンストラクタで取り扱う金額を業務で取り扱う範囲に限定するような目的でも利用できます。
コレクションオブジェクトの方は、
Listなどに自由にadd()やremove()、配列の中身を書き換えなどなどいろんな箇所でさせないために、
１箇所でコレクション操作を管理し外部からは操作させないようにする。
Listを参照させる際unmodifiableListで受け渡し、Listの中身を値オブジェクトにすることで、
値オブジェクトと同じように副作用が発生しないListにできます。
僕は値オブジェクトの考え方は知っていたのですが、コレクションオブジェクトの考え方は
この本で知りました。。。現場でもそこまでちゃんと書いてあるソースは今まで見たことがない。。。
まとめ
現場で役立つシステム設計の原則第１章 ちいさくまとめてわかりやすくするを読んで、
個人的には特に以下３点の考え方は重要だと感じました。
- 変数名など名前をわかりやすくする(ぱっと見て分かるように)
- メソッドは短くクラスは小さく(使いまわせなくならないように)
- 副作用をなくす(オブジェクトが意図せず変更されないように)
手段の紹介ももちろん参考にできますが、
考え方やそう考える理由などを正しく把握する方が手段を把握するよりもはるかに重要！！！
って思います。
2022/3/22追記
現場で役立つシステム設計の原則を読んでみて、
今後現場で取り入れたいこと、気付きなどなど
まとめ記事を作ったので是非こちらも見てください！！
現場で役立つシステム設計の原則を読んでみて(まとめ記事)｜気付きと現場で取り入れたいことについて
おまけ
ドメイン駆動設計についても学習した内容をまとめているので、
興味がある方は是非こちらの記事も読んでみてください！！
ドメイン駆動設計の練習！！モデリング〜サンプルプログラム・テストコード作成(まとめ記事)
