1スプリントよりも時間がかかるリファクタリングを処理するにはどうすればよいですか？

私は50万行を超えるコードであるコードベースを使用しています。リファクタリングが非常に必要です。通常の2週間のスプリントよりも時間がかかるリファクタリング作業が特定されています。このサイトの他の回答で提案したように、これらを小さなタスクに分割することはできません。製品は反復の最後に動作する必要があり、部分的なリファクタリングは、アイテム間の依存関係が恐ろしいため、システムを使用できない状態のままにします。それでは、このハードルにアプローチする最良の方法は何でしょうか？繰り返しますが、それを小さな断片に分割することはオプションではなく、すでに行われています。

更新：人々はなぜこれが2週間のスプリントに収まらないのかの説明が必要なようです。コードを書くだけでなく、スプリントに関与します。私たちには、テストなしのコードはないというポリシーがあります。そのポリシーは常に存在するとは限らず、コードベースの大部分にはそれらがありません。また、統合テストの一部はまだ手動テストです。問題は、リファクタリング自体が非常に大きいということではありません。小さな変更がシステムの多くの部分に影響を与えるという事実があり、それらの部分が依然として正しく動作することを保証する必要があります。

毎月のホットフィックスがあるため、スプリントを延期または延長することはできません。したがって、スプリントを超えて拡張されるこの変更は、修正プログラムに追加される他の作業を停止できません。

リファクタリングと再設計：開発プロセスが2週間のサイクルでこのリファクタリングを処理するのに十分な効率がないため、再設計に名前を変更する必要はありません。将来的には、プロセスが改善されれば、2週間のサイクル内でまったく同じタスクを達成できると信じています。ここで問題になっているコードは、長い間変更する必要がなく、非常に安定しています。現在、会社の方向性が変化に適応しやすくなっているため、コードベースのこの部分が他の部分と同じように適応できるようにしたいと考えています。リファクタリングが必要です。ここでの回答に基づいて、通常のスプリントの時間枠でこのリファクタリングを機能させるために必要な足場が不足していることが明らかになりつつあります。

回答：

これらの問題領域と欠落しているテストを特定する方法についてさらに学習できるように、Corbin Marchが初めて提案したブランチとマージのアプローチを実行します。前進するためには、Buhbが提案したテストに欠けている領域を特定するアプローチを採用し、それらを最初に実装してからリファクタリングを行う必要があります。ここで多くの人がリファクタリングの場合は常にそうすべきだと言っているように、通常の2週間のスプリントサイクルを維持することができます。

リファクタリングを遅らせる余裕がある場合は、コードベースを快適にリファクタリングし、単一のスプリントでリファクタリングできるポイントにユニットテストと自動統合テストを追加することを今後のイテレーションに集中することをお勧めします。

私のおすすめ：

1. ブランチを作成する
2. トランクからブランチに毎日マージし、競合を解決します。
3. 完了するまで作業します。ブランチは、いくつかのスプリントのコア開発の外側にある場合があります。
4. トランクにマージします。

おそらくugくなるという事実を回避することはできません。私はあなたをうらやましくはありません。私の経験では、プロジェクトを大幅に変更すると、すべてが完了した後に新しいパラダイムを変更されたトランクに何らかの形でマージするよりも、進行中の開発を新しいパラダイムにマージする方が簡単です。それでも、それは痛いです。

すべてのタスクを（人工の）2週間のスプリントで実行できるわけではないため、常識が求められます。これ以上分解できず、実行する必要がある場合は、そのまま実行してください。このプロセスは最終結果よりも重要ではなく、決して破られることのない法律ではなく、ガイドラインとして見なされるべきです。

3、4、または5週間のスプリントを行うだけです。誰も気にしない？あなたは明らかに短い時間枠では何もできないと確信しているので、それと戦うのをやめてください。

盲人のアジャイル遵守の王立協会であなたの仲間に話さないでください。

Michael Feathers 著の「Legacy Codeで効果的に作業する」という本から始めることをお勧めします。彼は、リファクタリングスタイルの変更の範囲を縮小するためのさまざまなテクニックを扱っています。

当店では、リリースウィンドウで完了できない大きなリファクタリングまたは書き換えタスクがある場合、機能をシステムにそのまま残します。ただし、時間の許す限り、リファクタリングされた新しいレゴブロック関数から始めます。最終的に、レゴブロックが十分に行われた状態になり、スプリントがレゴブロックをアプリケーションに接続してユーザーに有効にするのに十分な時間を提供します。

より簡潔には、新しい名前を使用して大きな関数を分割または再加工します。次に、最後に、厄介な古いコードの代わりに、名前を変更してリファクタリングした作業を使用します。

リファクタリング中にコードを適切に機能させる方法を見つけるために、1つのスプリントを捧げます。これは、非推奨のメソッドとクラス、ラッパー、アダプターなどの形式を取ることができます。あなたのリファクタリングは、コードを長期的にきれいにするために、短時間コードを汚すかもしれません。それで大丈夫です。今、あなたはそれができないと言っています。私はそれが正しいとは思いません-もしそれができたらあなたのプロセスがどのようになるか考えてください、そうするためにあなたがどんなステップを取ることができるか考えてください。その後、飛び込みます。

コービン・マーチの答えに+1、それはまさに私が考えていたものです。あなたのコードベースは少しいようで、クリーンアップするのに一回のスプリントサイクル以上かかるでしょう。
コービンが言ったように、

1. 「リファクタリングプロジェクト」に分岐します
2. ブランチの変更をテストする
3. QAテストのためにテスト環境に昇格する
4. リファクタリングが完了するまで、トランクに増分的にマージします。

あなたのPMがそれを見るのに苦労しているなら、あなたはこれをあなたの開発マネージャーに売るのに何の問題もないと確信しています。道路も1日で完成しません。リファクタリングにはしばらく時間がかかりますが、最終的には、メンテナンスが容易になり、機能強化リリースが速くなり、プロダクションチケットが少なくなり、SLAがより充実します。

本当にやりたい再設計は大きなタスクですが、小さな要素をリファクタリングして個々の依存関係を解消/分離することは可能でしょうか？ご存知のように、疑わしい場合は間接指定を追加してください。これらのデカップリングはそれぞれ、完了できない巨大なタスクよりも小さなタスクである必要があります。

依存関係が削除されると、残りのリファクタリングタスクを分割して、スプリント内で取得できるようになります。

私が現在取り組んでいるプロジェクトでは、4週間のスプリントを使用しています。また、ユーザーストーリーを終了できない場合があり、次のスプリント中にそれを再起動するだけです。

しかし、私見では、リファクタリングを4週間のスプリントに収まる小さなストーリーに分割することが可能であるべきです。4週間以内にコードを一貫した状態にできない場合は、リファクタリングするのではなく、アプリケーションを書き直しているように感じます。

特定のタスクに2週間のスプリントサイクルよりも時間がかかる場合は、タスクを別の時間にスケジュールすることをお勧めします。あなたのチームはリファクタリングの必要性を認識しており、それは重要です。時には、他のオプションがない...そして、はい、それは吸う。

リファクタリングを開始するときが来たら、通常のスプリントを一時停止します。選択肢はありません。スマートなバージョン管理を使用してください-ブランチ、リファクタリング、テスト、マージ。いくつかの大きなプロジェクトのリファクタリングが機能よりも優先される時点が常にあります。可能であれば、柔軟性を高めるために懸念を分離しようとします。

コードベースの一部（これも少し大きい）で最近同じ問題を経験したので、いくつかの洞察を皆さんと共有できることを願っています。私の状況では、コードベースは別のチームによって開発されていたため、元の開発者の誰もこのリファクタリングに関与していませんでした。コードベースでの私の経験は約1年であり、別の開発者は2年の作業を行いました。

ここで他の回答に関する2つの小さなメモを許可します。

• 分岐は、自分でプレイグラウンドを確立するのに役立ちますが、1つの大きなチェンジセットで変更をトランクにマージしないでください。チームの他のメンバーと深刻なトラブルに巻き込まれます。
• それを段階的に行う必要があり、それを行うことができます。言い訳しない。レガシーコードを使用した効率的な作業をお読みください。もう一度読んでください。
• あなたがそれを行うことができると考えると、1つの大きなステップは誤解です。作業は多いように見えますが、段階的に行う方が管理がはるかに簡単です。

一見「予約なし」に2週間以上行っても、気付かれることはありません。プロジェクト管理、さらに重要なことにはチームに支えられていることを確認する必要があります。チームがこのリファクタリングにコミットしていない場合（そして、これは遠い将来ではなく、今すぐに行うことを意味します）、問題が発生します。

単独でやるのではなく、ペアプログラミングを使用してください。これは、常に同じキーボードの前に常に座っている必要があるという意味ではありませんが、小規模で狭いタスク（たとえば、このクラスの動作をキャプチャするテストの作成）を個別に処理できます。

スクラッチリファクタリングを行い、そのように扱います。（一種の「スローアウェイ」プロトタイプのリファクタリング、「スローアウェイ」ビットは重要です！）正直なところ、リファクタリングが持つすべての影響を知っていることはまずありません。スクラッチリファクタリングは、特定の点で役立ちます。

• あなたは彼らが存在することを決して知らなかったシステムの断片を発見するでしょう。
• モジュールがどのように相互接続されているかについて、より良い見方ができます。
• システムをモジュールにグループ化する新しい方法を発見します。これは現在の理解とは大きく異なる可能性があります。パートナーと洞察について話し合います。新しいビューを蒸留してみてください。物事が現在どこにあり、どこに論理的に属するべきかを説明する短いアーキテクチャホワイトペーパーを書きます（または図を描きます）。

スクラッチリファクタリングを完了したら、すべてを全面的に変更することはできないことを発見してください。あなたは気分が悪くなります、それはただの大きな太った混乱であり、あなたはただスイッチをひっくり返してそれを機能させることはできません。これは私に起こったことであり、あなたの状況によって異なるかもしれません。

しかし、私のパートナーと私は、システムについてよりよく理解していました。これで、個々の小さなリファクタリング/リデザインを特定することができました。システムのビジョンを図に取り込み、そのビジョンを実装するために思いついたバックログ項目とともに、それをチームと共有しました。共通のコンセンサスを活用して、次の反復の過程でどの項目を実装するかを決定しました。

最後に役立ったのは、大きなホワイトボードを使用することでした。頭に入れておくべきものが多すぎます。メモをとることは非常に重要です。一日の終わりにデブリーフィングのメモを書き、今日やったこと、明日やりたいことを記録します。それは大きな時間をリラックスするのに役立ちます、そしてあなたが仕事に遅れずについて行きたいならば、あなたはリラックスした時間が必要です。幸運を！

メンテナンス期間を開始します。この期間中は、それ以上の開発は実行されません。再設計を実行してから、開発スプリントを再開します。

手元には2種類の作品があります。

1. 工数
2. 天才作品

メソッドの多くは、同様の開発者に、既に知られているので、通常はリファクタリングすることは、作業の最初のタイプで構成されていDRY、SRP、OCP、DIなど、プロジェクトをリファクタリングするために二ヶ月かかる場合このように、それは単純に2ヶ月かかります、そこにされますそれを回避する方法はありません。したがって、私の提案は、元のプロジェクトをリファクタリングせず、現在の状況で機能させることです。利害関係者と製品所有者からの新しい要求と要件の受信を停止します。次に、リファクタリングされて準備が整うまで、チームがプロジェクトに取り組みます。

役立つ可能性のある提案：2週間のスプリント内でリファクタリングと再テストを行う十分な時間がないような未テストのコードがある場合は、まず、他の無関係な小さな変更をコードに加えて、集中できるようにすることを検討してください最初のスプリントのためのテストを書くとき。おそらく、リファクタリングするコードのテストされていないクライアントをいくつか特定できます。クライアントを1つ選択し、ビジネスに何らかの用途の変更を加えて、そのクライアントのテストを作成するように強制します。コードの操作からコードに精通し、より多くのテストを行い、マイナーな貢献リファクタリングをいくつか達成したら、リファクタリングと（今では簡単になった） ）1回の反復で両方をテストします。

別のアプローチは、問題のコードのコピーを作成し、それをリファクタリングしてから、クライアントを一度に1つずつ新しいコードに移動することです。この作業は、反復間で分割できます。

'めないでください：大規模なリファクタリングを小さなステップに分解できないことを受け入れないでください。最も簡単/最速/最良のアプローチは、反復よりも時間がかかる場合があります。しかし、それは反復サイズのチャンクを行う方法がないという意味ではありません。