リファクタリングの効果をシステム・シンキングで考えてみる
まず、もっとも近視眼的に原因 → 結果を考えるとこうなる。
+記号は、原因側の増加・強化が、結果側にプラスの効果をもたらす事を意味する。反対に、原因側の減少・弱化は、結果側にマイナスの効果を与える。-記号ならば、原因側の増加・強化が、結果側にとってのマイナスとなる。
つまり、上図ではリファクタリングの実施が開発工数の増加をもたらす事を表している。逆に言うと、重複やらスパゲティコードやらの放置も、直接的には工数を減少させるとも言っている。
これに、「ソースの体質」(ソースコードの読み易さ、書き易さ、使い易さ)と開発作業における「余裕」を付け加えて、因果関係のループを作ると以下の用になる。
要するに、短期的には工数増加をもたらすリファクタリングが、ループを繰り返すに連れて効力を増して、次第に工数を減少させていく様子を表しているが、これを説明してみたい。
解説のため、二つのループに分けると下図のようになる。
上のループは-が一個(奇数個)なので、バランス・フィードバック・ループになる。
つまり「リファクタする」→「工数増える」→「余裕が減る」→「リファクタさぼる」→「工数減る」→「余裕がでる」→「またリファクタする」→「・・・」という感じで、一周ずつ反転しながら繰り返して、適当な均衡点に落ち着いて行こうとする。
下のループは-が二個(偶数個)なので、拡張フィードバック・ループになる。
この場合、「リファクタする」→「ソースが改善される」→「だんだん工数が減ってくる」→「余裕が出る」→「もっとリファクタする」→「もっとソースが改善される」→「さらに工数が減ってくる」→「・・・」という自己強化的な繰り返しになる。
ただしソースの体質改善が開発工数に影響を与える際、遅延(上図のコンデンサー記号)を生ずるのが一般的なので、ループの勢いは最初は弱い場合が多い。
とは言っても、ループの効果は一方向的に増強されるのみなので、「リファクタ実施 → 工数増加」と言う短期的な効果を、いずれ結局は追い越す事になる。
というのが、システム・シンキングで理屈をつけたリファクタの効果。
※実は、ループによる効果の増加を待てないような使い捨て度の高いシステムでは、リファクタしたところで却って費用対効果が良くない事も、同時に示唆していたりする。
ちなみに、リファクタしない場合の悪循環は、「リファクタさぼる」→「体質悪化」→「じわじわと工数増大」→「余裕が減る」→「リファクタしようにもできない」→「もっと体質悪化」→「さらに工数増大」→ ・・・、と言った感じ。
0 件のコメント:
コメントを投稿