レガシーシステムでのリファクタリング：技術的なプッシュバックの良し悪し
コードのリファクタリングに関しては、奇妙な考え方に気づいていますが、それをどのように認識しているかについてはあまりよくわかりません。
現在のプロジェクトの概要：
既存のサードパーティWebアプリケーションの拡張機能として使用されるWebアプリケーション。サードパーティアプリケーションは、顧客とベンダー間のスケジュールを維持します。この拡張機能を使用すると、顧客が再スケジュールを要求する日時を変更したり、緊急時に現在のスケジュールセットを変更したり、契約できなくなった場合にベンダーを変更したり、適切な請求ファイルを作成したりできます。開発に関しては、チームはスクラムのほとんどのアイデアに従うように設定されています。
システムは、主にプロジェクトの顧客が内部プロセスを完全に理解していないために、多くの想定される1回限りの基準に基づいて構築されました（内部トレーニング/売上高のため）。ハードコードされた文字列を含むことに基づくチェックがある多くの領域を見てきました。
これは私たちに問題をもたらします。特定のベンダー（SomeVendorと呼ぶことができます）のチェックがあり、名前にSomeが含まれているかどうかのチェックが設定されています。後でベンダーを獲得したり失ったりすると、別のベンダーがSomeOtherVendorとして追加されます。それに関する問題はもちろん、Someを含むことに基づくチェックです。 SomeVendorは、チェックする必要がある特定のケースであり、同様にチェックする必要がある他のベンダーであり、独自の機能セットで分岐します。これらのチェックを見つけると、スケジュールに関して開発されたものであることがわかりますが、ベンダーに関連付けることはできますが、常に割り当てられているわけではありません。ユーザーは実行時にそれを関連付けます。
お客様は、SomeVendorに問題があることに気づき、欠陥をバックログに入れるように要求し、製品の所有者に優先順位を付けました。私は欠陥を見つけて、有効なSomeVendorベンダーのルックアップテーブルを作成しました（IDに基づいて複数のベンダーが有効だった場合）。
Sprintの途中で展開が予定されているので、これを展開に追加する必要があるかどうかをリードと話し合いました。彼はこのソリューションが気に入ったと述べましたが、チェックする必要のあるすべてのベンダーのマッピングを組み込む方法でそれを実現できるかどうか尋ねました。彼はまた、現在の問題のためだけにそれを作ると述べた。
翌日、上級開発者は私と一緒に設計に取り組むように依頼し、すべてのベンダーの構成とそれをコードベースに組み込むことについて話し合います。上で述べたように、システムはいくつかのタイプのベンダーを「可能性がある」として説明しますが、常にそうであるとは限りません。
システムはそれを可能な限り説明するだけであるという点について説明しましたが、実行時に保存するまで決定されません。これを製品の所有者に持ち込み、プロジェクトの顧客から基準を取得することをお勧めします。
コードベースがこれを正しく使用するようにリファクタリングするポイントはわかりますが、この時点でオーバーエンジニアリングの領域に足を踏み入れているように感じます。その感覚は主にストーリー/欠陥によるものであり、お客様との間ですでに決定され、優先順位が付けられており、スプリント計画から私たちが行うと言ったことを示しています。これは、彼らが必要としていることを彼らが知らない成果物に忍び込んでいるように感じます（これは最近私たちと顧客の間で議論されました）。
このタイプのリファクタリングは、発生するはずのことですか、それとも技術的な反発の兆候ですか？実際には、答えが特にアジャイルを扱っているかどうかは私には関係ありません。チームがいくつかの要求された仕事をして、それから同意されなかった何かを提供するという意味で、私には奇妙に思えます。
あなたが抱えている具体的な問題はわかりませんが、あなたの質問にいくつかの一般的な考えがあることに気づきました。
実装している変更が製品のユーザー認識動作に影響を与えていない場合は、製品の所有者を関与させる必要はありません。ここでの技術専門家として、この変更が長期的にあなたにとって価値があるかどうかを判断するのはあなたの責任です。今数日を費やすと、将来のデバッグとバグ修正の数週間を節約できる場合は、それを試してみてください。これを製品の所有者に説明する必要はありません。
もう1つは、リファクタリングを行っていることを呼び出すことです。リファクタリングは短くて迅速な変更であり、エンドユーザーに認識できる変更を加えることなく、製品にすぐにコミットできます。そして、これらの小さなリファクタリングの多くは、長期間にわたってソフトウェアの内部動作を大幅に変更する可能性があります。あなたがしていることは、私がそれをリエンジニアリングと呼んでいるように、もっと聞こえます。しかし、それでも、この変更はエンドユーザーには見られないはずです。
あなたの変更は多くの小さな変更に分割でき、時間の経過とともにゆっくりと展開できると確信しています。これにより、変更のいずれかが何かを壊していないかどうかを確認できます。また、他の開発者が変更をより適切に吸収し、フィードバックを提供する機会も与えられます。
スプリント中期の展開
これは何ですか？スプリント中に展開があってはなりません。スプリントの最後には、展開可能なアーティファクトのみが作成されます。それ以外はすべて進行中の作業として扱う必要があります。スプリント中にデプロイを行う場合、なぜかんばんのような継続的なものではなく、スプリントを使用しているのだろうか。