「コード改善」の優先度と重大度を判断するにはどうすればよいですか？
バグ追跡システムには「優先度」と「重大度」のフィールドがあります。重大度は「ユーザーへの影響」として定義され、優先度は「製品への影響」として定義されます。
私の質問は、「コード改善」タスクを重大度と優先度で分類する方法についてです。改善によって動作が変更されることはないが、「より良いコード」になるとします。全体的に長期的なメンテナンスの改善が見込まれますが、定量化するのは困難です。
優先度と重大度の定義を使用する場合、長期的な利益を予測するのが難しい状況を全体像に導入しない限り、コードの改善は両方の値が最も低くなります。したがって、コードの改善は厄介な作業であり、決して試みてはならないことを意味します。
ただし、次の理由により、コードを常に改善およびリファクタリングすることは非常に重要であると考えています。
- ソフトウェア開発はそれ自体が継続的な学習プロセスであり、コードを改善しなければ、それを上手く進めることはできません。
- チームはコードを誇りに思うべきです。
- 将来のメンテナンスにかかる時間が短縮され、長期的に見れば大幅な節約になります。
または、そのようなタスクを作成してはならず、そのような改善は「オンデマンド」で、「バグに関連して」のみ実行されたと思いますか？それがバグに関連付けられている場合でも、それはコードレビューに関する議論のポイントではないでしょう。 「なぜこのような構造の大幅な変更をしたのですか？」.
通常、コードの改善自体がユーザーストーリーや要件の完了に直接近づくことはないため、「コードの改善」アクティビティを個別の割り当て可能なタスクと見なしたくありません。このため、コード改善タスクは常に優先度が低く、割り当てられることはありません。
私はコードの改善を一定であると考えています。これは、すべての開発者がキーボードで入力するのと同じくらい自然に行うべきことです。私はそれをあらゆるタスクの見積もりに含めます。私のタスクが、長い間見られていないクラスまたはソースコードに触れることを伴う場合、いくつかの管理作業がおそらく順調であると想定し、それに応じて私の見積もりを増やします。
最良の場合のシナリオ私はタスクを早期に終了し、残りの時間を使用して、コードまたはデザインを改善することができます。最悪のシナリオでは、タスクに予想よりもはるかに長い時間がかかりますが、バッファとして余分な時間があります。
コードをリファクタリングする場合は、定義に従ってタスクの優先度を設定します（「製品への影響」など）。必要な作業の範囲に応じて、一部のリファクタリングは製品にあまり影響を与えません。より高い優先度を設定すると、予期しないことが何も発生していないことを確認するために、リファクタリングの完了後にさらに多くのテストを行う必要があることを示します。
バグ追跡システムに新しいカテゴリを導入して、これらの種類のタスクを「リファクタリング」タスクとして分類することもできます。これにより、優先度の値を解釈する方法がわかります。つまり、優先度が高いほど影響が大きくなるため、より多くのテストが必要になります。
不足しているのは、既存のコードに関する想定を検証することです。コードを改善すれば、時間の短縮と大幅な節約を実現できます。これは化粧品ですか、それとも深刻な問題がありますか？
デバッグと拡張の見積もりを確認します。時間がかかり、最初にコードをリファクタリングするかクリーンアップする必要があるかについて継続的なコメントがある場合は、それが最良の測定値となる可能性があります。次に、コードベースを次のように識別できます。良、軽微な再作業が必要、または深刻なリファクタリングが必要。
これはすべて相対的なものです。より多くの機能が必要で、請求可能な時間にすぐに支払いたいというお客様がいる場合、この高い優先順位を与えることは困難です。
興味深い質問です。
変更が影響する可能性のあるコードの行数とモジュールの数を見積もる必要があると思います。
たぶん、もしあなたがそれらを持っているなら、どれだけのユニットテストが変更を加えることによって壊れるかを見ることができるでしょう。これはおそらく、最初にブランチで変更を試みてアイデアを得ることを意味します。
次に、これらの一致レベルの優先度と重大度のしきい値を設定します。
また、多くのテスターのテストが関与する必要があることを考慮に入れる必要があります。変更がアプリの大きな表面に触れる場合、多くのシステムテストを再検討する必要があるかもしれません。
ここでは、2つの仮定から始めましょう。
- 新しいストーリーごとに、可能な限りチームの周囲の知識で補強された能力でコードを作成します。
- 既存のコードの機能を変更するストーリーがある場合は常に、システムの新しい知識とより優れたスキルを使用して、新しいストーリーの実装プロセスでコードを改善します。
これら2つの仮定を前提として、明示的な「コードの改善」の取り組みは必要ありません。システムを作成すると、コードが改善されます。これは、すべてのコードが保守性に関する最新かつ最高の標準に準拠しているわけではないことを意味しますが、「破損していない場合は修正しないでください」。変更する必要のないコードを「金メッキ」にするためのリファクタリングは、不必要な目に見える機能を追加することと同じくらい考えています。コードが何らかの方法で破損している場合は、失敗する有効なテストを記述します。バグを記録します。次に、そのバグに対処するためにリファクタリングします。
私はアジャイル運動から投票を盗みます：
バグを入力し、重大度と優先度を大まかに推測し、
次に、毎日、毎週、または毎月、すべての新しいバグを確認し、それらの評価に投票します。理想的には、エンドユーザーとのスプリント計画会議中にこれを行います。次に、そのときの次の機能についても話し、前向きになることができます。