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

はじめに

良いコード/悪いコードで学ぶ設計入門第５章　低凝集ーバラバラになったモノたちーを読んで、

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

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

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

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

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

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

５章では低凝集について詳しく解説されていました。

低凝集を引き起こすことにつながる悪いコードや設計の例と、

その対策について学べる章だと思います。

インスタンス変数を使わないメソッドが低凝集な悪いコードに繋がる

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

「インスタンス変数を利用しないメソッドや staticメソッドで特に値を引数に加工などを行うものは 低凝集問題につながる」

「引数の状態を変えることを目的に利用するのは可読性が落ちるためやるべきではない。」

自分は今まで現場でデータクラスやUtilクラス、巨大な共通クラスなど見てきました。

それらは呼び出し元から(無理やり共通化しているせいで)大量の引数を受け取って

それを元に判断、加工などをする。

データとロジックが別の場所にバラバラと散らばり、

巨大共通クラスは引数も多く(しかもよくわからないフラグとか)何をやっているかわかりずらく、

ひどいものだと副作用で引数で渡した変数が意図せず書き換わってしまう。

というケースが多いです。

そうなると、

新規参入してきたメンバーはそのよくわからない巨大共通クラスを使いたがらず、

また同じようなロジックを別の場所に書き始めます。

そのため、

仕様変更が入ってプログラムを改修するときにはいろんな箇所を改修してテストして、、、

より変更が複雑で危険になり、技術負債が増えていきます・・・

これが現場で自分が見てきた悪い設計で作られた悪いコードの結末です。

そうならないように自分が意識しているのは、

要件を分析して設計していく際は、

要件全体を俯瞰した上で、

データとそれを使った判断、加工(ロジック)を１つの場所(クラス)にまとめていく。

そういう考え方で設計していくように心がけています。

そうすることで、無理に全く関係ないデータを複雑にフラグや副作用ありきで

扱わなければならなかった巨大共通メソッドは生まれにくくなります。

データとロジックが１箇所に、強く関連する意味のある単位でクラスにまとめるので、

あちこちのデータやロジックを読みつなげたりせず小さな単位で部品ができるので、

新規参画メンバーも変更による危険を遅れて同じロジックを別の箇所にコピーするようなことも減ると考えます。

これが高凝集にするための良いコードに繋がる良い設計の考え方かなと思います。

ファクトリを使ってインスタンス化のパターンが複雑でも使う側をシンプルに

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

「インスタンス化時に生成パターンが複数ある場合、 コンストラクタをprivateにして外からインスタンス化できないようにして、 staticなファクトリをパターン分用意して、それ経由でインスタンス化できるようにする。」

「ファクトリを用意しない場合、 オブジェクトを使う側に判断ロジックを持たせることになってしまう。」

このファクトリというテクニックは現場でもたまに使っているケースを見かけます。

これによってインスタンス化のためのビジネスロジックも１箇所にまとめることができます。

自分はこのファクトリを使う場合に限らず、

オブジェクトを使う側がシンプルになるように常に心がけるというところを設計やコードを書く際は

意識しています。

特に仕様変更時に使う側に分岐を入れればサクッと対応できる！！

と思って使う側にいろんな判断を入れ始めると悪いコードに向かっていきます。。。。

なぜなら、使う側が１箇所複雑になると、

いろんな使う側の箇所を同じように複雑にすることにつながり、

いろんな箇所に業務ロジックが散らばることにつながり、

変更が危険で厄介なコードになってしまうからです。

そうならないためのテクニックの１つがファクトリだと自分は理解しています。

まず、その根本的な部分を持った上で、

このファクトリに限らず細かいテクニックについて学ぶことは重要だと思います。

小手先の細かいテクニックを覚えるだけでなく、

目的と効果とを正しく理解し、自分の引き出しとするのが重要です。

(ちょっと学んだから使ってみたいという思いだけで

新しいテクニックをコードに適用しようとしたり、

目的と効果が曖昧なままとりあえず適用したりは避けるべきです)

まとめ

良いコード/悪いコードで学ぶ設計入門第５章　低凝集ーバラバラになったモノたちーでは、

低凝集で設計してコードを書くとどのように悪いコードになっていくのか？？

なぜ悪いコードになっていくのか？？

そうならないためにどういう考えで設計をして良いコードを書いていくのか？？

ついて学べる章だと思います。

以前、良いコード/悪いコードで学ぶ設計入門の著者のトークでもありましたが、

ビジネスのスピードが速い現代では、

ビジネスの要求を分析して保守しやすく成長し続けるコードに落とし込めるスキルは

githubを使えたりAWSを使えるのと同じくらい必須のスキルだという話がありました。

設計のスキルはそれほど重要だと僕も考えています。

こういった本を通じてプログラマーやエンジニアの設計スキルが上がり、

現場で変更が危険なシステムと出会す機会が減り、

設計についていろいろ語り合えるプログラマーやエンジニアが増え、

そういう方と一緒に仕事ができることを期待しています！！！