私は今、マーチンファウラーさんのリファクタリング本を読んでいます。
最近、再販されて嬉しい限りです。
また、レガシーコード改善ガイドも読みました。
それぞれすばらしい本です。
なんで今まで読まなかったんだろうと、後悔しているくらいです。

しかし、私の開発グループでは、リファクタリングが禁止されています。
この状況で、私がこれらの本を読んで学んだ手法をどう活かすかについて考えてみました。

自分のコードを書いているそばからリファクタリングする

新規のプログラムを書いているときに、「まずは書いてみよう」と書き出してしまうときがあります。
そのコードが、思いの他モンスターメソッドになってしまったりします。
そんなとき、自分の書いた、そのモンスターメソッドに対してリファクタリングを行います。
まだ製品として出荷されていませんし、他人のレビューも受けていない状態です。
そのようなときに、リファクタリングの手法は使えます。
本当はこのコードの書き方はあまりよくないのですが。

機能追加など修正がどうしても必要なときにちゃっかりリファクタリング

現在、製品として動いているシステムに、新しい機能を追加する仕事がやってきたとします。
その新しい機能を追加するときに、どうしても、既存のコードを変更する必要があります。
そんなとき、どさくさに紛れてリファクタリングをします。
むしろ、こういう場合にこそ、リファクタリングをして、既存のコードをテストで保護するべきです。
これはどんどんやっていきたいと思っています。

プロジェクトのルールを変えるために

上記の場合で、私がテストで保護された、すばらしいコードを書いたとします。
そのコードを、他のプロジェクトメンバーがレビュー等を通して、その有効性を認めたとします。
そうすれば、きっとプロジェクトのルールが変わるんじゃないかなと思います。
ただ、これはまるで小学生が描く夢物語のようです。
それほど単純ではないですし、それに感動するプロジェクトメンバーは私のプロジェクトにはいません。
私はほぼ諦めています。

つまりはこれから書くコードのため

リファクタリングを学習する３つの理由を挙げました。
結論を言えば、「今までのコードは仕方ないけど、これから書くコードはリファクタリング済みのものを書く」ということです。
それが最終的に私を守るものだと信じています。
テストで保護されたコードは、バグを生みづらいです。
つまり、修正が少なく、長生きしやすいコードとなります。
この辺の考えが私の開発プロジェクトでは全く評価されません。
そのため、テストで保護されたコードを買いても、「おつかれさん」くらいなものです。
「え？だから？」といった感じです。
むしろ「そんな無駄なコード書いて時間かけやがって」と言われます。
だからといって、テストで保護されたコードを書くスキルを捨てる事は嫌です。
プログラマーとして死んでしまいます。
このあたりは私の意地ですが、不毛な戦いを続けたいと思います。

これらの本に出会えてよかったと心から思います。

• 

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
•