他の誰かがリファクタリングの問題を抱えていますか？[閉まっている]

かなりの量のコードを書いた後、可能な限り最善の方法でそれをしていないような不安を感じ、最終的にリファクタリングを続け、プロジェクトにあまりにも多くの時間を費やしているようです。時々やった。これは他の誰にも起こりますか、これにどのように対処しますか？

それらが私に起こるとき、私はこれらの瞬間を楽しみます。

理由：自分の仕事を振り返らずに、開発者として前進しないよりももっとうまくやれるはずがあると思うなら。したがって、これらの啓発の瞬間が発生したら、それらを受け入れて、学んだことを書き留めてください。現在のプロジェクトのタイムテーブルを検討し、可能であればコードをリファクタリングし、可能でなければレッスンを受講して、プロジェクトの将来の実装で使用します。

いずれにせよ、あなた自身の過ちから学ぶことは素晴らしいことです！

このアクティビティを制限して生産性を高めるためのいくつかのルールを次に示します。

• タイムボックス、たとえば、タイマーを25分に設定
• 適切なテスト範囲がある場合にのみ実行してください。
• リファクタリングが次のいくつかの機能の開発に役立つようにする

いつでもリファクタリングできるように思われませんか？他の問題を解決しようとする場合にのみ、リファクタリングを制限しようとします。たとえば、パフォーマンスの問題が発生した場合のリファクタリングと解決に役立つリファクタリング-新しい機能とリファクタリングを追加する必要がある場合のリファクタリングは、問題の解決に役立ちます

正直に言うと、膨大な数のコードを作成し、それがすべて完璧で、リファクタリングを必要としないと思ったらもっと心配です...

私が若くて経験の浅いとき、私はプログラミング能力について非常に慢で、いつもうまく設計して計画することが可能であることを想像する傾向がありました-そして、実装段階に到達したらすぐにそれを打ちますすべてが完璧になります。

現実はほとんど反対です。コーディングを開始したらすぐにメンテナンスモードにする必要があるとさえ言う人もいます。ここでの考え方は、SDLCの「実装」段階は実際には存在しないということです。バグ修正やリファクタリングを脇に置いて、作成するコードが「新鮮」で完璧だと偽装してはいけません。

私は思う、と述べているすべてのISリファクタリングについてあまりにも強迫観念を取得することが可能に。まだ見ていません。そして、私が経験すればするほど、より多くのソフトウェアチームが、締め切りに間に合わず、技術的な負債を負うことを特許的に拒否するのは良いことだと思います。結局のところ、これは、リファクタリングが現実の世界で脇に置かれる最も一般的な理由です。

純粋に感情やコードの匂いに依存しないことをお勧めします。

コードの問題点と解決策を明確に列挙してください。リファクタリングがこれに対してどれほど効果的だったかを確認したいので、真剣に書き留めてください。

リファクタリングを達成可能なチャンクに分解する方法を特定し、それらに優先順位を付けます。各チャンクのスコープのみに焦点を合わせ、タスクを損なう可能性のある接線を避けて、規律を持たせます。

また、先に進む前に、既存のコードに対して作成できる単体テストを特定します。すでに広範なテストがある場合、それは素晴らしいことです。単体テストの欠如は、いくつかを作成する絶好の機会です。

私がこのtrapに陥ることは間違いありませんが、リファクタリングは将来のサポート/デバッグのために重要です。

主要なコードを記述するとき、コードの行を現在記述されているメソッドに保持することが非常に簡単になります。主要なコードを完成したら、コードレビューコメントを追加します。それから数日後、コードのレビューを行い、それに応じてリファクタリングします。数日後にそれを読むのに問題がある場合は、数ヶ月または数年後に何が起こるか。

初めて言語や技術を学んだとき、このtrapに陥ります。たとえば、最初にjavaを学習するとき、サーブレットを使用してWebアプリケーションを作成し、それが正しい方法だと考えていることを想像してください。それからjspがあることに気づき、それはおそらくそれより新しいと思います。その後、途中でStrutsといくつかのEJBを見つけると、その後に春（xmlベース）が見つかり、その後にクールな@MVCアノテーションが見つかります。グルービー/グライルとスカラ/リフトの選択！ポイントは通常学習することであり、必ずしも期限を守ることではないため、これは個人的なプロジェクトにとってはまったく問題ありません。

私も仕事で超リファクタラーでした。しかし、より多くの経験を積むにつれて、リファクタリングするものについてより選択的になりました。会社を辞めたとき、コードを持ち歩くことはなく、通常、他のエンジニアは修正するよりもほぼ迅速にコードを破壊することができます。

私が従う経験則は次のとおりです。その時点で可能な限り最適化されるまでリファクタリングし、状況が変化しない限りリファクタリングしません。 （たとえば、新しい言語機能を使用して）物事を行います。

たとえば、既存のアプリケーション用に新しいコードモジュールを作成する必要がありました。私はそれを特定の方法で書きました。翌日、他の用途のために道を広げる必要があると確信していたので、リファクタリングして抽象化することができると考えて次の日に考えました。そこで、コードをリファクタリングしました。その後、私はそれが少しだったことを決めた、あまりにも同じ機能を取得するためにジェネリック（C＃）を使用して、基本的には同じことをやっていたいくつかのクラスとインタフェースを統合し、一般的な、私。この時点で、私はおそらく可能性さらにリファクタリングしてさらに改善しますが、「十分」です-コードは適切に記述され、適切な設計パターンとエンジニアリング概念に従っており、拡張可能です。要件によってコードの再評価が必要になった場合、またはコードをより明確にしたり読みやすくしたりできる言語機能があった場合にのみ、リファクタリングします。