重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。良いコード/悪いコードで学ぶ設計入門を読んでのまとめ記事も作ってみたのでこちらも是非みてください!!良いコード/悪いコードで学ぶ設計入門を読んでみて(まとめ記事)|気付きと現場で取り入れたいことについて良いコード/悪いコードで学ぶ設計入門第4章を読んでの気付きなど4章では可変と不変についての解説がされていました。可変(ミュータブル)と不変(イミュータブル)を適切に設計しない場合に、どのような悪いことが起きるのか??どういう方針で設計していくと良い設計になるのか??について理解できる章だと思います。変数を再代入すると複雑になりがち良いコード/悪いコードで学ぶ設計入門第4章にはこのようなことが書かれていました。すると変数の意味が変わり、推測を困難にしたり追うのが難しくなる。「インスタンス変数がコロコロ変わる場合同じ状態を再現するために同じ順番で実行するなど結果の予測も大変。金額の合計の計算結果を代入するために使われ、とある時点からはその金額に対する消費税額を代入するために使われる。処理を注意深く追わなければその事実に気付けないと思います。戻り値voidにするような方針でコードを書いたりするのをよく現場で見かけます。書き変わるパターンとそうでないパターンと・・・とかになってくると、バグを埋め込む可能性はかなり高まります。変数の状態をコロコロ変えさせないようにする。いう考え方が重要です。引数としてとある状態で値を受け取って、その状態を変えずに判断、加工を新規のインスタンスや変数を使って行って新規に作った方を返却する。(値の変更も新規のインスタンスや変数で行う)そんなイメージで自分は設計をしています。副作用(意図せず値が書き換えられてしまう)ような心配もなくなりバグが減らせて動作も安定します。副作用ありきの場合はなにか想定外の動きをしたらデバッグで変数の状態が副作用によって書き換えられる再現をしたりするケースも出てきますが、シンプルなのでデバッグを使う機会も減らせます。不変で設計できない場合は可変を考慮すべき箇所を最小限に良いコード/悪いコードで学ぶ設計入門第4章にはこのようなことが書かれていました。「データベースなどコード外とのやりとりは不変にすることはできないのでリポジトリパターンを使って依存する箇所を局所化する。」リポジトリパターンについては自分はドメイン駆動設計で学びましたが、データベースの操作という関心事とドメインの関心事とを分離させ、データベースの操作をドメイン層に依存させることができ、データベースの操作に関する処理を1箇所に集められる。SQLからPostgreSQLに変わってもドメイン層のロジックには影響しない。いうのがメリットだと自分は認識していました。不変にすることができないデータベースに対する操作を可変を考慮させる箇所を局所化することにも繋がっていると言うのは本を読んで認識しました。自分がリポジトリ層の実装を書くときは、1つの集約にまとめた情報をデータベースからいろいろ取得して、ドメインオブジェクトを生成して返却。以降の処理では正常に初期化されたインスタンスを不変で扱える。みたいな考え方で設計してコードを書いています。可変だとなぜ悪いコードになってしまうのか??不変にするとなぜ動作が安定して良いコードになるのか??についてわかりやすく解説してあり、非常に重要な考え方を学べる章だなと思いました。以前、良いコード/悪いコードで学ぶ設計入門の著者のトークでもありましたが、ビジネスのスピードが速い現代では、ビジネスの要求を分析して保守しやすく成長し続けるコードに落とし込めるスキルはgithubを使えたりAWSを使えるのと同じくらい必須のスキルだという話がありました。設計のスキルはそれほど重要だと僕も考えています。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。