続 atsushifxの七転八倒

ウツ、発達障害の闘病記とIT関係のつれずれを書いていきます

転ばぬ先のリファクタリング

「業務のコードをリファクタリングするケースが想像付かない」とのこと。
そこで僕が「理解容易性の向上と設計の向上を行う為にリファクタリングですよ。」と言ってみたら
「そもそも設計が悪いんじゃないの?」とのこと。

XPer的考えからすれば、リファクタリングは期間を設けてるものではなく、常にできるだけやっておくものです。
元記事ははぶさんがちゃんと応えているのでやぶへびっぽいですが、リファクタリング変更に備えるという意味が濃いと思います。
いくら設計が完璧だろうとなんだろうとシステムは変わるものというのがXP的立場です。
さらにBPRという考えから見れば、ユーザーの教育曲線を考えて一次開発、二次開発というかたちでシステムが変わっていくのが普通なはずです。
そしてそれが起こったときのシステム変更のコストを抑えるための術がリファクタリングなんです。

  • if文の分岐の羅列でロジックをわかりにくくするよりテーブル形式で見やすくする。
  • 変更箇所を分散させるのではなく一箇所にまとめる
  • 例外処理のような後が大変な処理が必要のないロジックにする

といった形で後の変更を容易にするもんがリファクタリングです。
有識者というわけではないですが、まぁ参考意見としてどうぞ