ソースコードへのすべての変更がバグレポートまたは機能要求に関連付けられなければならず、そのポリシーを改革する方法がない場所で働いているとしましょう。このような環境で、コードのリファクタリング (つまり、コードを改善するが、バグを修正したり機能を追加したりしない変更) に対処する最善の方法は何ですか?
すべてのバグ レポートと機能の説明は、マネージャーと顧客に表示されることに注意してください。
私は「こっそりリファクタリング」アプローチに投票します。これは、リファクタリングが最初に行われることを意図した方法であると私は信じています。「コードをクリーンアップする」ためだけにリファクタリングするのはおそらく悪い考えです。これは、本当の理由もなく変更を行っていることを意味します。リファクタリングとは、定義上、バグの修正や機能の追加を意図せずに を変更することです。KISS の原則に従っている場合、最初から最も拡張性の高いシステムを実現する方法を考えていないため、新しい機能には少なくともいくらかのリファクタリングが必要になります。
コードのブロックで作業している場合、ほとんどの場合、そのコードのブロックを変更する必要があるバグ修正または新機能があり、リファクタリングは変更を簡単にするために変更前に行われるか、結果を整理するための変更後。いずれの場合も、リファクタリングをそのバグ修正または機能に関連付けることができます。
コードをリファクタリングする正当な理由があるに違いありません。
別の機能が同じコードを使用できるようにすることが理由である場合は、変更を他の機能の要求に関連付けます。
何かを高速化する場合は、「xyz」を高速化するための機能リクエストを作成し、変更をそれに関連付けます。そうすれば、顧客はあなたが製品を改善していることを確認できます。
バグを設計する場合は、バグをログに記録します。
私の環境では、ポリシーを適用できないことに注意してください。しかし、賢明なマネージャーは変更のレポートを受け取ることができ、コミット テキストにバグ\リクエストの参照がない場合はフォローアップされます。
各オプションを見てみましょう。
元のコードにセキュリティ リスクがある、またはクラッシュや不安定性が生じる可能性があると思われる場合。危険を概説する小さなバグ レポートを書き、それを修正します。
機能要求に基づいてコードを反応させるのは難しいかもしれません。しかし、有効な機能リクエストを使用してこれを行うことができます。これにより、次のポイントに進みます...
有効なバグまたは機能がある場合は、バグを修正するか機能を追加するために、関数 x をわずかに変更する必要があることを述べてください。
これは、アプリケーションの改善による自己開発が許可されていないことを示唆しているようです。開発者は、許可されていない場合でも、新しい手法やテクノロジを探求することを奨励する必要があります。
関連する会議で、変更を加える必要がある説得力のある理由を示して、改善について話し合うことができるかもしれません。そうすれば、少なくとも、別の方法でコードを忍び込まなくても、管理者が変更に対応できるようになります。
そのような融通の利かない (そしてばかげた) ポリシーのある場所で働いている場合、最善の解決策は別の仕事を見つけることです!