どのくらいのリファクタリングが許容されますか？
私は現在、私の開発者の同僚の1人が、彼が行っているすべてのチケットの内容を常にリファクタリングしているプロジェクトにいます。私たちはアジャイル手法を使用しています。いくつかの問題を解決する間、リファクタリングは良いことであり、コードベースをきれいに保ちますが、私の質問は、制限は何ですか、最大でいくつのファイルを処理するべきですか？あまりにも多くのリファクタリングが長期的に私たちを噛んでしまうことはありますか？
時々、彼はバグを導入している可能性があるように感じます（ただし、システムは十分にテストされています）。これにより、レビュープロセスが非常に煩雑になります。元の変更が約10〜20にしか影響しないはずのときに、60〜70ファイルの変更を確認する。
プロジェクトでは、取得するチケットは非常に小さく、通常、10〜20個以下のファイルを変更する必要があります。この開発者は平均50程度です。それは間違っていると感じ、私は彼がそうではないことを納得させる方法を見つけていません。彼はすべてがテストされているので、すべての変更はコードベースを改善するだけだと言います。最後に、このリファクタリングが彼を遅くしている可能性があると私は想定しています。彼はいつも非常に多くのものを変更するだけだからです！ ：D
何かご意見は ？
私の個人的な見解では、リファクタリングを実行する必要がありますが、通常はとにかくチケット用に変更されるクラスに限定する必要があり、より大きなリファクタリングが必要な場合は、チケット自体にする必要があります。場合によっては、小さなものさえも変更しないことに気づき、「このチケットをそのままの状態で十分にリファクタリングしました。」と思い込んだリファクタリングの制限に到達したとき、私は停止するだけですコードベースに不要な変更を加え、チケットのまとめにのみ焦点を当てます。
編集：私がプログラマのスタックエクスチェンジで回答や同様の質問を読んだところ（たった今発見した、なんて素敵な場所なのか！）、私の主な問題は、私が説明したのは単一のコミットであることに気づきました。私はリファクタリングを自由に導入できることをすべての人に伝える必要がありますが、レビュープロセスを容易にするために、それを個別のコミットに保持するようにしてください。
編集：問題があるとわかったもう1つの側面は、マージの競合です。これらのリファクタリングは、他のメンバーが時々同じコードの部分に取り組んでいるために時間を費やすことになります。重要なことは何もありませんが、チームの全員が多くのリファクタリングを行った場合、マージの競合はさらに増えるでしょう。これが世界の終わりだと言っているのではなく、ただテーブルに置いているだけです。
私は量に焦点を合わせるのではなく、実質に焦点を合わせます。 リファクタリング操作のグループ中に影響を受けるファイルの数は、1日あたりに書き込むLOCとは無関係です。極端な例は、規則に従うメソッドの名前変更です。それは何千ものファイルに影響を与える可能性がありますが、設計を根本的に変更する2つのファイルに焦点を当てたリファクタリングよりもほとんど重要ではありません。
whatがリファクタリング操作のグループであり、-どのくらいファイルまたはLOCが影響を受けるのではなく改善されることに焦点を当てることにより、現在発生している問題の複雑さも軽減します。コードのレビュー中に、これらの操作の全体的な影響を確認します。彼らはコードベースを改善しますか？いくら？
操作を個別にリファクタリングすることを検討してください。これは、チームが何を検討するかを正確に判断するのに役立ちます有用、および何を回避する必要があります。たとえば、コードのレビュー中に、同僚が次のリファクタリング操作を行ったことに気付いたとします。
やり過ぎた分割メソッド、
抽象ファクトリーパターンを導入し、
いくつかの
ifsを継承に置き換え、ロジックを簡略化し、いくつかの継承オカレンスを
ifsに置き換え、クラスとLOCの数を減らし、コードを読みやすくしました。メソッド
findSparseを読みやすくするために書き直しました。それらが実際にゲッターとセッターであることを示すためにいくつかのメソッドの名前を変更しました、
シングルトンが置き換えられ、Dependency Injectionが導入されました。コードのテストがはるかに簡単になりました。
6つの変更は28のファイルに影響を与え、無視する必要があると伝えるのではなく、25ファイルのしきい値を超えているため、チームは次のことを検討します。
リファクタリング操作1と7はそれだけの価値があります。
操作2、3、および4は興味深いものですが、時間がかかります。プロジェクトに時間的プレッシャーがかかっている場合は、これらを実行するべきではありませんが、それ以外の場合は実行する必要があります。
オペレーション6は表面的なものであり、Reflectionを使用するプロジェクトの一部にバグが発生するリスクがあります（メリットを上回るリスクを説明することが不可欠です）。この操作は、すべてのチームが変更を行う準備ができるまで延期する必要があります。
操作5では何も改善されていません。リファクタリングの作成者は、自分のスタイルに合わせてコードを書き直しただけです。ほとんどのチームメンバーは、これによってコードが読みやすくなるわけではなく、実際には元のバージョンの方が理解しやすいと主張する人もいます。同様の操作は今後避けてください。
個別の操作に集中することで、チームの視点、歓迎すべきこと、そうでないことを同僚が非常に簡単に理解できるようになります。量に集中することで、より「私はありません」あなたの働き方が好きではない」非建設的な批判。
ご了承ください：
コミットが十分に細かい場合（そしてそうである必要があります。上記のリファクタリングでは、少なくとも7つのコミットと、8番目のコミットが機能自体を実装していることを期待します。理想的には、ポイント3とポイント4も複数のコミットの対象になるはずです。 全体で10を超えるコミット）まで、コミットをロールバックしても問題は多くありません。
コミットがスパースでモノリシックな場合（つまり、上記のリファクタリング操作で1つまたは2つのコミット）、チームでさらに深刻な問題が発生する可能性があります。 1つのコミットが1つの変更に対応し、他の変更から独立したままでいることが可能な限り小さいことを説明してください。
各チケットで発生するリファクタリングの量を事前に合意します。これはチームとして行われます。その開発者が余分なことをしたい場合は、それを呼び出して、それが大丈夫かどうかを判断します。スコープを適切に設定してください。チームが範囲外の何かを破った理由を上司に説明しようとすることは何も悪いことではありません。
また、リファクタリングが実際にコードベースを改善していることを確認してください。あなたのチームは、ホットスポットを特定するためにシステムでいくつかのコード指標を実行しているはずです。すべてを書き直したい開発者もいます。実際にコードベースを改善していることを確認してください。時にはそれだけの努力に値しないか、行われている作業が実際には何も改善していません。繰り返しになりますが、前後の測定が役立ちます。
追加の作業を行っているチームのメンバーを称賛します。彼らが改善に誇りを持つのは良いことです。彼らがしているすべての良い仕事をキャプチャしたいので、驚きを作らないことを彼らに示すようにしてください。それらはスコープの定義に抵抗するかもしれませんが、ある時点でそれがあなたに噛み付くようになるかもしれないので、コードベースにルーズな大砲の束を絶対に望まないでしょう。
最大でいくつのファイルを処理する必要がありますか？
理論的には、完璧なコードベースがないため、無制限にリファクタリングを続けることができます。
私と私のチームのためにうまくいったこの問題を回避する1つの方法は、クリーニングが必要なこれらの領域を特定し、それらからチケットを作成することです（テクニカルデットチケットまたはそれらに沿ったその他のものと呼びます）スプリント中これらの技術負債チケットをメインチケットに添付することを計画しています。
このようにして、作業のスコープを設定し、他の開発者に問題を引き起こす可能性のある追加のリファクタリングを実行しません（つま先を踏んでいないため）。
上記のアプローチでは、リファクタリングのためのすべての小さなコード領域を技術的な負債としてキャプチャするのではないことは明らかです。そのため、これらの小さな変更については、作業中のチケットの下にすべて含めることができます。それで大丈夫です。
ただし、小さな変更によって、予想以上に20以上のファイルが追加されることはありませんであり、これが発生した場合は、次の2つのことを意味します。
1）その人がチケットに関係のないランダムなことを多すぎる方法で実行している。
2）その人は、以前には捉えられなかった大きなリファクタリングを行っています。
どちらの方法でも、これらの2つのシナリオを確実に議論することができます。
最初のケースでは、次のように言うことができます：
チケットに関係のないかなりの量の変更を行うと、コードベースを見つけたよりもきれいに保つの点で役立つよりも注意散漫になります。
このマントラは、現在使用しているコードに関するものですしたがって、クラスAを使用していて、それがクラスBに関連している場合、少し面倒ですが、リファクタリングすることは理にかなっています。
しかし、クラスAで作業していて、まったく関係のないクラスZをリファクタリングしている場合は、テストの必要性が高まるだけでなく、開発プロセス全体が混乱し、速度が低下します（開発テストの速度が低下し、不必要なコンテキストの切り替えが発生します）。 、テストリソースの増加、ワークフローのエントロピーの増加）。
2番目のケースでは、次のように言うことができます：
以前は把握されていなかった大量の技術的負債に取り組むことは、プロセスとチームの裏切りです。なぜなら、それはすべての人によって合意されておらず、ビジネスアナリストによって時間/リソースを費やすものとして優先されなかったためです。
次回、技術的負債の大きなチャンクを見つけた場合、計画と方向性を考慮せずに対処するのではなく、それをキャプチャして、後の優先順位付けのためにバックログに追加する必要があります。
私にとって、プロジェクトに必要な品質のレベルに関しては、あなたとチームメイトが同じページにいないように思えます。
最近、チームと同じ問題がありました。私にとってうまくいったのは、プロジェクトのすべての部分で全員が合意した理想的な設計を決定することでした。リポジトリはCQSを使用し、MVCコントローラーは非常に薄く、主にサービスレイヤーなどを使用します。
すべてのチームメンバーがプロジェクトの設計に同意したら、たとえば、いくつかのUMLダイアグラムによってそれを形式化します。それらを印刷して、コードレビュー中にチームルームで利用できるようにします。設計が明確であれば、goodで十分であり、より多くのリファクタリングが不要になる時期に同意するのは簡単です。
また、現在取り組んでいる機能やストーリーに関連するコードの一部のみをリファクタリングすることをお勧めします。このように、リファクタリング時間は機能全体に比べて短く、プロジェクト管理にリファクタリング時間をより簡単に「販売」することができます。