『WEB+DB PRESS Vol. 127』を読みました。 現在は第2特集の作って学ぶPhoenixを読んでいる途中ですが、第1特集の実践リファクタリングは読み終わったので、メモがてら感想まとめます。
凝集度
関数の役割の少なさを表す指標です。 1～7のレベルがあって、機能的凝集に近づくほど凝集していると判断します。
- 偶発的凝集： 無作為に処理が集められた関数
- 論理的凝集： 関連のない処理をフラグで切り替える関数
- 時間的凝集： 機能的に関連はないが同じ時間に実行する処理をまとめた関数
- 手続き的凝集： 機能的に関連はないが同じ時間で実行順序に意味がある処理をまとめた関数
- 通信的凝集： 機能的に関連はないが同じ時間で同じ値に対して処理をする関数
- 逐次的凝集： 機能的に関連はないが関連する値を受け渡して処理をする関数
- 機能的凝集： 単一の機能を処理する関数
言葉で書くと仰々しく感じますが、実際に本に書いてあるサンプルコードを読んでみたら、そこまで複雑な概念ではありませんでした。
結合度
- 内容結合： 宣言されていない変数での結合
- 共通結合： 共通の複数のグローバル変数で結合
- 外部結合： 共通の単一グローバル変数で結合
- 制御結合： 制御フラグで結合
- スタンプ結合： 構造体やクラスで結合
- データ結合： スカラ型の値で結合
- メッセージ結合： 引数のない関数の呼び出しで結合
グローバル変数を使った関数間の値の受け渡しで、結合度が低くなるのは直感的にも理解できます。 ちなみに、関数に制御フラグを渡すはやってしまいがちです。
興味深かった点
過剰なDRY原則
プログラマーの原則としてDRY原則（Don't Repeat Yourself）がありますが、過剰なDRY原則で仕様変更に弱くなっているコードのサンプルが解説されていて、勉強になりました。
後から触る人が修正しやすかったり、仕様変更に柔軟に対応できるプログラミングを心がけたいです。
良いコードとは何か
これは『綺麗なコード = 良いコードとは限らない』という話です。 リファクタリングと聞くとコードを綺麗にすることだと思いがちですが、何をもってコードを綺麗（良い）と判断するかは、サービスによって変わってきます。
たとえば多くの人が携わるプロジェクトであれば、読みやすいコードであることが良いコードの条件になってくるかもしれません。 また、仕様書や設計書を書かないと決めたプロジェクトであれば、コード内コメントが充実していることが良いコードの条件になるかもしれません。
一般的にはパフォーマンスの良いコードや、プロジェクトチームが高い生産性を発揮できるコードなどが良いコードになってくると思いますが、良いコードを判断するためには多方面からの評価が必要です。
良いコードかどうかを判断するための指標のひとつとして、凝集度と結合度は役立ちそうです。
あとがき
制御フラグはやりがちなんですが、本書を読んで仕様変更や機能追加への耐性が低いことを改めて実感したので、関数はシンプルを心がけていこうと思いました。
