良いコード/悪いコードで学ぶ設計入門第４章を読んで｜気付きや今後参考にしたいことなどをまとめてみました

はじめに

良いコード/悪いコードで学ぶ設計入門第４章　不変の活用ー安定動作を構築するーを読んで、

８年間現場で設計をしたり、設計に関する勉強会への参加や技術書を読んできた自分の観点で、

特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。

良いコード/悪いコードで学ぶ設計入門を読んでのまとめ記事も作ってみたので

こちらも是非みてください！！

良いコード/悪いコードで学ぶ設計入門を読んでみて(まとめ記事)｜気付きと現場で取り入れたいことについて

良いコード/悪いコードで学ぶ設計入門第４章を読んでの気付きなど

４章では可変と不変についての解説がされていました。

可変(ミュータブル)と不変(イミュータブル)を適切に設計しない場合に、

どのような悪いことが起きるのか？？

どういう方針で設計していくと良い設計になるのか？？

について理解できる章だと思います。

変数を再代入すると複雑になりがち

良いコード/悪いコードで学ぶ設計入門第４章にはこのようなことが書かれていました。

「変数に再度値を代入する再代入・破壊的代入をすると変数の意味が変わり、推測を困難にしたり追うのが難しくなる。」

「インスタンス変数がコロコロ変わる場合同じ状態を再現するために同じ順番で実行するなど結果の予測も大変。」

例えば１メソッドの中の１つの変数がとある時点までは、

金額の合計の計算結果を代入するために使われ、

とある時点からはその金額に対する消費税額を代入するために使われる。

こういうコードの場合、おそらく変数名がよくわからない命名をすることになったり、

処理を注意深く追わなければその事実に気付けないと思います。

また、他の例では１メソッドの中で複数の戻り値を返したいと考え、

メソッドの中でオブジェクトを直接書き換え、

戻り値voidにするような方針でコードを書いたりするのをよく現場で見かけます。

こういう副作用ありきのコードは複雑で初見で読み取るのは難しく、

さらにこれが巨大共通メソッドで分岐がいくつもあって、

書き変わるパターンとそうでないパターンと・・・

とかになってくると、バグを埋め込む可能性はかなり高まります。

(今までの経験上そうでした)

これが悪いコードを生み出す設計で、

良いコードで書く設計としては、

金額合計、消費税額といった目的毎に変数を用意するのと、

基本的には引数、ローカル変数はfinalとして一度代入したらそれ以降

変数の状態をコロコロ変えさせないようにする。

という考え方が重要です。

引数としてとある状態で値を受け取って、

その状態を変えずに判断、加工を新規のインスタンスや変数を使って行って

新規に作った方を返却する。(値の変更も新規のインスタンスや変数で行う)

そんなイメージで自分は設計をしています。

こうすることで、

コードがシンプルになり、

副作用(意図せず値が書き換えられてしまう)ような心配もなくなり

バグが減らせて動作も安定します。

ついでに言うと、

副作用ありきの場合はなにか想定外の動きをしたらデバッグで

変数の状態が副作用によって書き換えられる再現をしたりするケースも出てきますが、

シンプルなのでデバッグを使う機会も減らせます。

不変で設計できない場合は可変を考慮すべき箇所を最小限に

良いコード/悪いコードで学ぶ設計入門第４章にはこのようなことが書かれていました。

「データベースなどコード外とのやりとりは不変にすることはできないのでリポジトリパターンを使って依存する箇所を局所化する。」

リポジトリパターンについては自分はドメイン駆動設計で学びましたが、

データベースの操作という関心事とドメインの関心事とを分離させ、

データベースの操作をドメイン層に依存させることができ、

データベースの操作に関する処理を１箇所に集められる。

DBMSが例えばMy SQLからPostgreSQLに変わっても

ドメイン層のロジックには影響しない。

というのがメリットだと自分は認識していました。

が、不変にすることができないデータベースに対する操作を

可変を考慮させる箇所を局所化することにも繋がっていると言うのは本を読んで認識しました。。。

自分がリポジトリ層の実装を書くときは、

１つの集約にまとめた情報をデータベースからいろいろ取得して、

ドメインオブジェクトを生成して返却。

ドメインオブジェクトのインスタンス変数はすべて不変とし、

さらに不正な状態ではインスタンス化が失敗するようにガチガチに固めているので、

以降の処理では正常に初期化されたインスタンスを不変で扱える。

みたいな考え方で設計してコードを書いています。

ドメイン駆動設計のリポジトリと集約については別の記事にまとめているので

興味がある方は是非みてください！！

コードで学ぶ集約とリポジトリの関係〜DDD実践のためのきほん〜

まとめ

良いコード/悪いコードで学ぶ設計入門第４章　不変の活用ー安定動作を構築するーでは、

最近のプログラミングで主流になっている不変という考え方について、

可変だとなぜ悪いコードになってしまうのか？？

不変にするとなぜ動作が安定して良いコードになるのか？？

についてわかりやすく解説してあり、非常に重要な考え方を学べる章だなと思いました。