新しいプロジェクトが始まるとき、そのコードはきれいで美しいです。 美しい抽象化を設計し、優れたインターフェイスとプロフェッショナルな実装を作成するときが来ました。 人生は美しい！ 私たちのプロジェクトも。
機能を追加し続け、すべてがスムーズに進みます。 ある時点で、コーナーを少し切って、意図したトラックを少しオフにし、特定のケースに非常に小さな治療を追加する必要があります...いいえ、いいえ、松葉杖はありません！ 美しい理論を実用的な実装に近づける必要なコード。 悪い兆候はなく、開発は非常に活発に進行しています。
それでも、理想的なコード画像のキャンバスにはまだ小さなしみが現れています。 一部の人々はそれらを「技術的負債」と呼んでいます。 これは、誰かが本当に何かを借りているという意味ではありません。これは、あまり良いコードではありません。 しかし、彼は何らかの形で機能し、問題を解決します。
開発が継続するにつれて、コード内のそのような場所に頻繁に出くわし、そのたびに、選択範囲を選択します：すべてをきれいに書き換えるか、別の問題（現在作業中の問題）を解決するために問題の場所を迂回します。 ときどき戦闘に突入することもありますが、それでも回避策のあるオプションを選択することがよくあります。
いずれの場合も、少し遅くなります。 しかし、期限が近づくと、開発速度の要件が大きくなるだけなので、コード品質の要件のバーを徐々に下げる必要があります。これにより、「ブロット」の数が増加します。
これらの新しい問題領域（古い問題領域に加えて）は、私たちをますます阻害しています。 私たちは問題を認識していますが、現在の問題を解決するために急いで、他のことに集中することはできません。 同じ速度を維持するためだけに、より多くの仕事を余儀なくされています。
ある時点で、私たちが書いたコードの半分は、小道具、クロール、ハッキング、および以前に作成した他の種類の障害を克服するためのものであることが突然判明しました。 これは良いコードですが、悪いコードもありますが、ここでは魚を包みました。
ポイントAからポイントBへの直線ではなく、この地雷原に沿って歩くたびに、最終的な目標を達成する保証なしに、突然迷路を通るもつれたルートになります。 大変な努力でも、以前と同じ速度で目標に向かって進むことはできなくなりました。
問題の重要性は肉眼で見えるようになりました。 そして、すべてを捨ててプロジェクトをゼロから開始するだけでは修正できません。 コードをリファクタリングするために多くのタスクを実行する必要があり、これらのタスクには顧客に尋ねる時間が必要です。 多くの場合、この時間は私たちに割り当てられません。私たちは自分のコードを修正するために時間を要求します。
時間が割り当てられていても、すぐに結果を期待するべきではありません。 現時点で具体的に見られる問題、および十分な時間が割り当てられている（そしてそれほど多くはない）ボリュームでのみ修正できる問題です。 私たちはこの悪いコードを何週間（または数ヶ月）書いたので、このコードを書き直す時間は確かにありません。
これは私たちが行く必要がある方法ではありません。 長いリファクタリング期間は、プロジェクトにすぐに目立った大きなメリットをもたらしません。 顧客に販売するのは非常に困難です。なぜなら、彼はどのような機能を求められているのか、彼には見られないからです。 それは悪い考えです。 どうする？
簡単にするために！ 次の各タスクを受け取ると、その実装の計画を概説します。 この計画の過程で技術的な負債の「しみ」に遭遇した場合、それをリファクタリングするタスクは現在の機能の実装の一部になります。 もちろん、コード内のすべての悪い場所をすぐに取り上げることはできません。 しかし、これは必要ありません！ 新しい機能の実装中に、新しい小道具や松葉杖を作成するよりも古い「ブロット」を修正すると、プロジェクトコードの全体的な品質が向上します。 次回、新しいタスクに取り組んでいるとき、突然修正済みの場所に戻る必要があります。ファイルの研磨は不要になりますが、すぐにうまく機能し、見栄えがよくなります。 これがソフトウェア開発の方法です。
おそらく、この方法で個々の機能を開発するには、当初考えていたよりも少し時間がかかります。 ただし、このアプローチを使用した一連の機能の開発には時間がかかりません。期限前の最後の段階では、比較的クリーンなコードベースで作業できるため、新しい機能を追加しても回避策を見つけるのに時間がかかりません。 さらに、開発に対するこのような個人的なアプローチは、チーム全体のパフォーマンスに良い影響を与えます。
繰り返しは学習の母です。 新機能が追加されるたびに、コードが少し簡潔になります。 少しだけですが、毎回。 多くの場合、「少し」ある時点で、彼らは穏やかな魂で、あなたの髪を引き裂き、このすべてのゴミを完全に除去したいという欲求と戦うのではなく、それが恥ではない新しいうまく機能する機能を書くことを可能にします。
継続的なリファクタリングの有用性を認識する瞬間は、あなたが思うほど遠くありません。 一部の人々は、このアプローチを使用し始めた同じスプリントの終わりまでに彼に気付き始めました。 プロセスの継続性と増分性の力は、非常に迅速に感じられます。 しばらくすると、リファクタリングなしで同じタスクを完了するよりも、リファクタリングで新しいタスクを完了する方が時間がかかりません（以前のコードの改善に費やした時間のため）。
作業は改善され、コードはよりクリーンになり、以前よりも多くの機能を顧客に提供しています。 みんなが勝ちます。
したがって、リファクタリングはバックログのタスクではなく、その中のすべてのタスクの一部です。