最適化」タグアーカイブ

やってることの分だけコードがある、のはフツーのこと。

WEB+DB PRESS vol.127」(以下、wdp127)にリファクタリングの話があったので読んでみたら良かった。

https://gihyo.jp/magazine/wdpress/archive/2022/vol127

知らない単語が出てきたのでメモしておく。

□ 凝集度(cohesion)
□ 結合度(coupling)

調べてみると、語源は1979年あたりにヨードンが提唱していたらしい。

□ DRY(Don’t Repeat Yourself)

コードの最適化、なんでもDRYというルールがあるそうだ。

プログラミングしていると、同じようなコードを何度も書くとき、共通化できるのでは?と考える。あちこちに書いておくと、あとでそこに修正が生じた場合にあちこち直さなくてはならないため不便だし、処理が同じならモジュール化すべきだという考えだ。

wdp127では凝集度について、論理的凝集は避ける、ようなことが書いてある。要はフラグを使った関数内分岐を避けよ、という意味と理解した。ウチでは同じような意味で「多機能関数はダメ」というルールがある。

結合度については値は引数で渡す、ようなことが書いてある。要はグローバル変数は避けよ、という意味と理解した。ウチでは「関数の中はローカル変数だけを使う」と「グローバル的な変数にはゲッターセッターを用意して関数を介して取得する」というルールがある。ただし例外として、画面に一覧を表示する際のフォームオブジェクトはグローバル参照をしていいというルールもある。画面に表示する情報についてゲッターセッターをすべて用意するのはあまりにも面倒だ。フォームオブジェクトは名前付のルールでわかるようにしている。

ウチでは上記のほかに、

・モジュール内の構造は原則2つまで

forやifの構造が3つ以上出現する場合は、さらなるモジュール化を検討せよ、という意味だ。

・処理の分だけコードはある

仕様がケース分岐しているのであればコードも分岐している、のがフツーだ。入り口から分岐させて、中に共通処理を見つけたら共通モジュール化する、のが良い。

・デバッグしやすいコード

できるだけ1行で書く、というコードはダメ。if文の中に関数を記述したり、引数に関数を記述するのはわかりやすいNGだ。デバッグする時にたとえばforループが何回回るのかは重要な要素だ。上手くいかないときは0回の場合が多い。これをデバッグするには繰り返し回数を見れば良いのだが、大体はなんかの関数の戻り値である。これをfor($i;1;myFunc())のように書いてしまうとmyFunc()の戻り値を見たくなる。$count:=myFunc()とか記述して$countの値を見ることになる。それなら最初からそういうコードにしておけば良い。

・プログラマに必要な機能はおそらくユーザにも必要

上記はソース内部の記述だが、表面的な仕様でもデバッグに便利な機能を実装しよう。あるテーブルの中身が見たいような機能は言われなくても作ってしまう。デバッグでよく使うツールであればプログラマは便利になる。そのままリリースして、ユーザに「削除して」と言われてから「隠す」ようにすればよい。

まだ語り尽くせないので、また思いついたら続きを書く。。。