「コード改善」の優先度と重大度を判断する方法は？

バグ追跡システムには「優先度」フィールドと「重大度」フィールドがあります。重大度は「ユーザーへの影響」、優先度は「製品への影響」として定義します。

私の質問は、「コード改善」タスクを重大度と優先度に分類する方法についてです。改善によって動作が変更されることはなく、「より良いコード」になると仮定します。全体的な長期的なメンテナンスの改善が見込まれますが、定量化するのは困難です。

優先度と重大度の定義を使用すると、予測が困難な長期的な利点を図に導入しない限り、コードの改善により両方の値が最も低くなります。したがって、コードの改善は簡単な作業ではなく、決して試みるべきではないことを意味します。

ただし、コードを絶えず改善してリファクタリングすることは非常に重要だと思います。

• ソフトウェア開発自体は継続的な学習プロセスであり、コードを改善しなければ、それを上達させることはできません。
• チームはコードを誇りに思うべきです。
• 今後のメンテナンスにかかる時間は短くなり、長期的には大幅な節約になります。

または、そのようなタスクは決して作成されるべきではなく、そのような改善は「オンデマンド」でのみ、「バグに関連する場合」に実行されると思いますか？それがバグに関連しているとしても、それがコードレビューの議論ポイントではないでしょうか？例えば、「なぜあなたはこの構造の劇的な変更をしたのですか？」

通常、「コード改善」アクティビティを個別の割り当て可能なタスクと見なしたくないのは、コード改善自体が、ユーザーストーリーや要件の完成に直接近づくことは決してないからです。これが、コード改善タスクが常に割り当てられることのないほど低い優先度になる理由です。

コードの改善は定数であり、すべての開発者がキーボードで入力するのと同じくらい自然に行う必要があると考えています。私はそれをあらゆるタスクの見積もりに織り込みます。私のタスクに、しばらく見られていないクラスまたはソースコードに触れることが含まれる場合、おそらく清掃作業が適切であると想定し、それに応じて見積もりを増やします。

ベストケースのシナリオでは、タスクを早期に完了し、残りの時間を使用してコードや設計を改善することができます。最悪のシナリオでは、タスクは予想よりもはるかに長くかかりますが、バッファーとして余分な時間があります。

コードをリファクタリングする場合は、定義に従ってタスクの優先度を設定します（つまり、「製品への影響」）。必要な作業の範囲に応じて、一部のリファクタリングは製品に大きな影響を与えません。より高い優先度を設定すると、リファクタリングが完了した後、予期しないことが発生しないことを確認するためにさらにテストを行う必要があることを示します。

バグ追跡システムに新しいカテゴリを導入して、これらの種類のタスクを「リファクタリング」タスクとして分類することもできます。これにより、優先度の値の解釈方法がわかります。つまり、優先度が高いほど影響が大きくなるため、より多くのテストが必要になります。

不足しているのは、既存のコードに関する仮定を検証することです。コードを改善すれば、時間を短縮し、大幅な節約を実現できます。これは化粧品ですか、それとも深刻な問題ですか？

デバッグおよび機能強化の見積もりを確認してください。時間がかかっており、最初にコードをリファクタリングする、またはクリーンアップする必要があるという継続的なコメントがある場合、それが最良の測定値になる可能性があります。次に、コードベースを次のように識別できます。良い、マイナーなリワークが必要、または重大なリファクタリングが必要です。

これはすべて相対的です。より多くの機能を必要とし、請求可能な時間にすぐに支払いを希望する顧客がいる場合、この優先度を高くすることは困難です。

興味深い質問。

変更が影響する可能性のあるコードの行数とモジュール数を見積もる必要があると思います。

ユニットテストがある場合は、変更を加えることで何個のユニットテストが破損するかを確認できます。これはおそらく、まずアイデアを得るためにブランチで変更を試みることを意味します。

次に、これらの一致レベルの優先度と重大度にしきい値を設定します。

また、多くのテスターのテストを考慮する必要があります。変更がアプリの大きな領域に影響を与える場合、多くのシステムテストを再検討する必要があります。

ここから2つの仮定から始めましょう。

1. 新しいストーリーごとに、可能な限りチームの周囲の知識に支えられて、コードを可能な限り最大限に記述します。
2. 既存のコードの機能を変更するストーリーがある場合は常に、システムの新しい知識と優れたスキルを使用して、新しいストーリーを実装するプロセスでコードを改善します。

これらの2つの前提を考えると、明示的な「コード改善」の努力は必要ありません。システムを記述するにつれて、コードが改善されます。これは、すべてのコードが保守性に関する最新かつ最高の基準に達しているわけではなく、「壊れていない場合は修正しないでください」という意味です。不要な可視機能を追加するのと同じくらい、「ゴールドメッキ」に変更する必要のないコードのリファクタリングを検討します。コードが何らかの方法で破損している場合、失敗する有効なテストを記述します。バグを記録します。そして、そのバグに対処するためにリファクタリングします。

アジャイル運動から投票を盗みます：

バグを入力し、重大度と優先度を大まかに推測し、

次に、毎日、毎週、または毎月、すべての新しいバグを確認し、その評価に投票します。理想的には、エンドユーザーとのスプリント計画会議でこれを行います。その後、その時点での次の機能についても話し合うことができます。