リファクタリングするタイミング

ファウラーのリファクタリングの本のほとんどを読み、過去の大小の多くのアプリケーションをリファクタリングしました。

私が教えるのが難しいのは、「いつ」リファクタリングするかです。私は過去に非常によく役立ってきた腸の感覚に基づいてこれを行う傾向があります。ただし、コードをそのままにするかリファクタリングするかについて人々と議論するとき、「ガットチェック」に耐えることは困難です。

もっと厳密なアプローチが必要だと感じていますが、それが何であるかはわかりません。

私は「コード臭」、赤緑リファクタリング、その他の考えを理解していますが、リファクタリングに最適なのは、コードを最初に書くのではなく、コードを使用して2回目または3回目にすることですそれは実際に問題であり、実際に使用されていることです。

リファクタリングリファクタリングのコストはコストよりも小さい場合ではないリファクタリング。

ただし、「コスト」を測定できます。たとえば、コードの実装が不十分であるため、些細なバグを修正するには数時間または数日かかる場合がありますか？リファクタリングにより、より多くの顧客を獲得したり、容量を増やしたり、パフォーマンスを改善したりして、既存の顧客を満足させることができますか？

1. ある循環的複雑度 5以下の機能のは？
2. そのリンクをたどることなく、サイクロマティックの複雑さを完全に理解しましたか？
3. 関数のすべてのパスについて、自動テストまたは文書化されたテストケースがありますか？
4. 既存のテストケースはすべて合格しましたか？
5. 機能とそのすべてのエッジケースを1分未満で説明できますか？
6. そうでない場合、5分間はどうですか？
7. 10分？
8. 関数に含まれるコードが100行未満（コメントを含む）ですか？
9. このコードに目視検査だけでエラーがないことに同意する他の2人の開発者を見つけることができますか？
10. この関数は1か所でのみ使用されていますか？
11. 関数はパフォーマンス目標（時間/メモリ/ CPU）を満たしますか？

得点

上記の「いいえ」の回答を追加します。

• 0-1-なぜこれをリファクタリングすることさえ考えますか？前の開発者の命名規則が気に入らないので、おそらく変数の名前を変更したいだけです。
• 2-5-これには少し調整が必要な場合がありますが、この範囲の製品の本番リリースは延期しません
• 6-8-OK、おそらくこれを修正する必要があります...これを再検討し続ける可能性があり、そして/または実際にそれが何をしているかわからない可能性があります。まだフェンスの上にあるが、それは非常に疑わしい
• 9+-これはリファクタリングの最有力候補です。（注、テストケースの作成はリファクタリングの一形態です）

あなたの腸がリファクタリングを行うべきだと言っているとき、それはあなたの本能があなたにあまりにも長い間重要な何かを先送りしていることを少し遅く告げている可能性が高いです。

私は「コード臭」、赤緑リファクタリング、その他の考えを理解していますが、リファクタリングに最適なのは、コードを最初に書くのではなく、コードを使用して2回目または3回目にすることですそれは実際に問題であり、実際に使用されていることです。

リファクタリングには事実上2つのレベルがあります。1つ目は、最初のコーディング時に現れる明らかな問題です。これらは、前もって行うコストが非常に少ない小さな最適化です。メソッドとクラスを小さく保つこと、DRYとSRPに準拠することなど。次に、設計の主要な欠陥に対処する追加の段階があります。これは、コードが数マイル下になるまですぐに明らかにならない場合があります。話しているのはこの2番目のレベルですが、後でリファクタリングするのにコストがかかりすぎないようにするために、後で想定する労力がより簡単に、より安価になるようにコードを既に記述している必要があります。つまり、早期リファクタリングを行うことを意味します。

ジェフが回答で述べたように、「時は金なり」、特に作業負荷が高く、リスクがさらに高い企業ではそうです。コードが最適な状態にあることを確認するために前もって費やした時間は、後で簡単にリファクタリングすべきであったものをからかうことが主要な操作であることが判明したときに、時間を節約できます。

ソフトウェアを作成するとき、コードを前もって改善することに費やされるすべての瞬間は、後で本当に必要になるときに時間を節約できます。リファクタリングが早いほど、後の変更が明確になります。それは、将来の技術的負債に対して今日のドルで頭金を支払うようなものであり、将来の技術的な負債は、明日の膨らんだドルになるでしょう。

いずれにせよ、リファクタリングは、ソフトウェアが既に完全で安定している不思議な未来まで延期するタスクであってはなりません。それは、賭け金がはるかに高くなり、製品を変更するのがはるかに難しくなると、後でリスクが増加するためです。リファクタリングはあなたの毎日の活動の一部であるべきであり、これはあなたが言及したレッド・グリーン・リファクタリングの哲学の本質です。

あなたの質問は、各開発者やプログラミングを担当する経営者によっても異なる方法で答えられると思います。

私の個人的な好みは、何か新しいことを学んだり、ベストプラクティスを改善したりするたびに、可能な限りコードをリファクタリングすることです。その状況で使用するのに最適な標準が何であるかを知るとすぐに、コードを標準に維持するのが好きです。ただし、同じソフトウェアを長期間使用する小規模な会社であるため、これを行うことができます。

時は金なりの大規模なソフトウェア開発会社では、この時点から学んだより良い方法で設計を開始するだけかもしれません。その特定のソフトウェアのバージョン2までリファクタリングを心配しないでください。

いつリファクタリングするかを教えることは、あなたが現在いる会社に本当に依存していると感じています。

「リファクタリングするタイミングは？」

短い答え：悪臭を放つコードまたは改善される可能性のあるコードに遭遇するたびに（ボーイスカウトルール）

実際には、これは起こります：

• TDDを練習する場合、TDDサイクルのリファクタリング手順で体系的に、つまり、テストがグリーンになり、新しいテストの作成を開始する前に。
• コードレビューの結果として
• レガシーコードを引き継ぐ場合
• ぎこちなく設計されていると思われるコードを使用する場合
• 等

私が最初にリファクタリングについて学んでいたとき、私の指導者は私に言った：「それを二度行い、あなたの鼻を握りなさい。三度やりなさい。リファクタリング。」（ありがとう、ジョシュ！）具体的には、彼が言っていたことは、同じコードブロックを3回（または同様のコードパターンで）書き込もうとしているとき、つまりリファクタリングするときでした。私は過去10年間、それに従ってきましたが、それが十分な経験則であることがわかりました。

Eclipse、または強力なリファクタリングをサポートする同様のIDEを使用すると、リファクタリングを行う労力が軽減されます。IDEのサポートにより、「3回目」に到達するとすぐに（または必要に応じて）リファクタリングする可能性が高くなります。

また、リファクタリングとしてテストを実行し続けることができ、何も破損していないことがわかるので、TDDはここでも大きな助けになります。

定義によるリファクタリングはプロセスです。これは、ラファクタリングタスクを実行するために暇な時間を見つけようとするのではなく、より適切に記述できるコードコードに出会ったときに常にリファクタリングを続ける必要があることを意味します。

個人的には、進化的なプロトタイプを書くのが好きです。もっと簡単に言うと、ただ機能するコードで、予想されるコーディング標準を満たすまでリファクタリングします。別の良い例は、追加機能を追加し、既存のコードをリファクタリングして再利用できるようにすることです。

私の20年間のプログラミングの中で、実際に仕事を見た経験のある唯一の経験則があります。これは人々が固執することができ、マネージャーは時間を許します。（リファクタリングはダイエットのようなものです。確かに、「カロリーイン/カロリーアウト」は体重を減らすための公式ですが、それは人々が従う食事に変換されません。）

作業中に継続的にリファクタリングします。テスト駆動開発を使用して、1日に数回のレッドグリーンリファクタリングサイクルを実行します。触れたコードの一部だけをリファクタリングします。

自信がついたら、このレジメンとは異なることができます。

私は、それはプロジェクトの所有者とコードの品質について答える人の要求に依存すると思います。他の誰かのお金が問題になっている場合、あなたは単にそれを単独で決定することはできません。

技術的な理由については、いくつかあります。

• コードにバグがある場合、それはこの場所が誤解されていることを意味し、より多くのエラーがここに隠れている可能性が非常に高く、コードの接続された部分を開発しようとすると大きな問題が発生します。したがって、リファクタリングの可能性についてこの場所を確認する必要があります。
• もう1つの理由は、機能を追加または変更し、古いコードが変更/追加に非常に不便であり、その後の変更/追加が非常に可能性がある場合です。もちろん、コストのバランスを取る必要があります。
• おそらく最も深刻な理由は、コードを変更していてテストできない場合です。