チームの技術的負債をなくすために、毎月のリファクタリング日をどのように計画しますか？
私のチームは（まだ）あまり作業をしていませんでした技術的負債そして私たちのコードベースには大量のTODOコード、未使用のコード、「良くなる可能性がある」コード、@ Ignoreunitestsなどが含まれています。
これから始めますこれらの問題に対処します。私たちは製品に取り組んでおり、他にもやることがたくさんあるので、この戦略を考えていました。
1人のエンジニアが毎週0.5-1x日技術的負債に対処するために割り当てられます。彼はこの日/半日だけコードの保守に取り組みます。チームには4人以上の開発者（6人の開発者）がいるため、これは各開発者に対して月に1回（およびそれ以上）になる可能性があります。
アプリ（プラグイン）を使用 SonarLint（ https://www.sonarlint.org/ ）、CheckStyle、IntelliJ検査などを使用してコードベースを検査します。
各エンジニアはチェックリストに記入モジュールごとに作業するため、「technical-debt-fight」を行う必要があります::「未使用のコードを削除する」チェックボックス、「1xtodoを終了する」チェックボックス... 。等
要約が記入されます毎日（簡単に言えば、コミット要約のように）後に、次の週に仕事を続ける他のエンジニアがこれを行うことができます。
月に1回-2 作業を確認します /このプロセスについて話し、終了のタイミングを設定します（半年のプロセス？）
これは単調な/時には退屈な/不快な作業になる可能性があるため、チェックリストを使用しておよび「強制」チームは良い考えです。私自身もチェックリストを見て、何をする必要があるかを見て喜んでいます。特にこれは月に一度の仕事なので。
この計画についてどう思いますか？この技術的負債の問題をどのように「攻撃」しますか？
それに加えて、マーティン・ファウラーのリファクタリングノートについてもっと読むつもりです。
他の推奨事項は大歓迎です！ありがとう！
非常に悪い場合を除いて、他の方法では作業していないランダムなもののリファクタリングを具体的に開始することはありません。無視されたテストは、テストしている機能が壊れていることを意味する場合にそのようなケースになる可能性があります。
むしろ、コードに触れる必要があるときはいつでも、コードを見つけたよりも良い状態に保つという哲学を適用します。機能の実装には最初は少し時間がかかる場合がありますが、これは会社のビジネス側に販売する方がはるかに簡単です。また、リファクタリング中に新しいバグが発生する「おっと」を大幅に削減しますが、触れていた機能にはあまり詳しくありません。
もちろん、コードがまったく使用されていない場合は、破棄してください。そのためのバージョン管理があります。
ちなみに、作業中のブランチでTODOを使用する予定がない限り、コードでTODOを使用しないことをお勧めします。すぐに実行するか、残りの変更に課題追跡システムなどを使用してください。
これは、品質についてあまり妥協してはならないという事実にも触れています。有効なビジネスシナリオが存在する場合もありますが、最終的には開発者としてのあなたが優れたコードに責任を負います。物事をより速く行うためのビジネス側からのプッシュは文字通り常に存在しますが、それが定期的に低品質やテストされていないコードを書いていることを意味する場合、それはあなた自身の責任です。
リファクタリングの取り組みは、定期的な問題として定義、計画、および取り組む必要があります。一部のタイムスライスが予約された結果として、時間の経過とともに消滅すると予想される技術部門の1つの大きな塊とは見なされません。それを真剣に受け止め、あなたの問題が何であるかを定義し、それを仕事として扱ってください。仕事です。
技術的負債を削減した私の経験では、コードカバレッジが良好であることを確認する必要があります。これを一度に行うことは困難（そして鈍い）であり、たとえあなたがこれを行うための時間を取っておいたとしても。通常、エンジニアは問題を修正したり、新しい機能を実装したりするタスクを取得します。
問題を修正する
- 現在の（バギー）シナリオで合格するテストを作成します。
- 失敗するテストを記述します。つまり、バグを修正した後に合格します。
- テスト1を失敗させ、テスト2を合格させるために、最小限の作業を行います。ここでは特別なことをする必要はありません。正しいテストに合格するだけです。
- 失敗しているはずの最初のテストを削除します。
- ビジネスロジックを裏付けるテストがあるため、コードをリファクタリングしても安全です。 SOLID原則がここで役立ちます。
- これで、テストもリファクタリングできます。
新しいコードを実装する
- 場合によっては、エンジニアは最初に、新機能の影響を受けるコードの周りに合格テストを作成する必要があります。
- 新しい機能の失敗したテストを記述します。これは、新しい機能の実装後に後で合格します。
- テストに合格するために最小限の作業を行います。
- 次に、コードをリファクタリングします。 SOLID原則がここで役立ちます。
- ここで、テストもリファクタリングします。
コードは、最初に実装されたときに完璧に見えます。後で（おそらく数ヶ月後に）それはそれほどきれいに見えないでしょう。すでに適切なテストがある場合は、新しいコード環境に合わせてコードをリファクタリングするのは簡単で安全です。これは、技術的負債を管理する上で重要なステップです。
MartinFowlerによるリファクタリングノートは非常に良い出発点です。