どうしたらCEOや技術者ではない人に、リファクタリングの意義を正しく説明することができるだろうか？
「リファクタリングを正しく伝えるには」という議論の中で、 BigVisibleのアジャイルコーチであるAdam Sroaka氏は次のように発言した。「リファクタリングは必要なのです。なぜなら、要求は必ず変わるので、それを満たすものを作るにはコードを必ず変更しなければならないからです。仮によい設計原理に沿ったコードがあったとしても、変更したら設計原理に沿わないものとなるでしょう。コードが変わったときに設計を改善する技術が、リファクタリングなのです。」
CollabNetの認定スクラムトレイナーのMichael James氏は、テストファーストでコーディングしながらリファクタリングすることが重要だと言及した。新しいコードを書くとき、最初はいつも往々にして煩雑で、私と私のペアプログラミングのパートナーはコードを整えることに時間をとられるから、と彼は説明した。
XP創設者の一人、Ron Jeffries氏は「リファクタリングが『義務』である理由」 という投稿で次のように説明した。「2週間のスプリントでスクラムプロジェクトで求められるインフラのすべてを提供できないとしたら、 改善するためにリファクタリングを実施しなければいけない状態である、と考えた方がよいです。さもなければプロジェクトチームの開発スピードはもっと遅くなり、最終的には混乱に陥るでしょう。スクラムや他のどのようなアジャイル開発手法でも、要求は変更されるというのが基本前提です。要求が変わったら、使い残し、やり残しを仕上げるリファクタリングを実施しなければいけません。」
同じ 「リファクタリングを正しく伝えるには」のスレッドの中で、 Michael James 氏は、要求が変わらないとしてもリファクタリングは必要だと付け加えた。なぜなら最初の1回で完全なコードを書くことは絶対に不可能だからである。
Mark Woyna氏は 自動車産業を参考にするべきだと主張した。自動車会社は毎年車に多くの小さな変更を実施して発売する。そのうちエンドユーザの要求にこたえるための変更はほんのわずかである。ライフスパンの改良やコスト削減のために部品を変えたりすることもある。
筆者はリファクタリングはマネージメントとともに話すべきことではないのではないと考えている。日々の職業倫理の、小さな一部品であるべきではないか。他の本格的な開発に移る前のウォームアップとして、朝の最初にメソッドのリネームや抽出を実施してはどうだろう。