リファクタリング作業を含むすべての開発に追跡の問題を伴うべきですか？

議論：リファクタリング作業を含むすべての開発には追跡の問題を伴うべきですか？（この場合、Jira）

共通点：私たちの主な目標は品質です。機能する製品、すべてのリリースは、何よりも重要です。私たちのコードベースは古く、自動テストが欠けています。私たちはこれに取り組んでいますが、それは長期的なプロジェクトであり、暫定的なプロセスが必要です。

ポジション1：リファクタリング作業はJiraで追跡する必要があります。変更と明らかに関係がない場合は、別の問題を提起する必要があります。そうしないと、レビューとテストが省略され、私たちの主な目標にリスクが生じます。PCIコンプライアンス（ビジネスの近い将来の目標）ではこのレベルの追跡が必要であるという議論が行われました。私はそれがどんなレベルの確実性でも真実か偽りであると言う立場にはありません。

ポジション2：コードの品質は非常に重要です。それが良くなればなるほど（ある程度、私たちがどこにも近くないほど）、機能する製品をリリースし続ける可能性が高くなります。どんなに小さくても、リファクタリングの方法で障害となるものはすべて、私たちの主な目標に対するリスクです。多くの場合、IDEが自動的に機能します。そのため、とにかく問題が発生することはほとんどありません。

次のケースが行われました：

開発者がカードに「リファクタリング」と関連するリビジョン番号を書き込んだ場合、それは両方の立場を満たしますか？正直なところ、これは皆を等しく不幸にしてしまうような気がします。それでも、リファクタリングの実行にはある程度の抵抗はありますが、十分な追跡機能はありません。

イテレーションのリファクタリング作業を網羅する、すべてを網羅するJiraの問題についてはどうですか？はい、これにより開発者の抵抗層が削除されますが、Jiraの問題があることによる追跡の利点も削除されると思います。QAは何をテストすべきかを明確に理解する方法を教えてください。これは政治的な解決策のようであり、軽量だが最終的には無意味なプロセスを追加することで誰もが落ち着くようにしています。

議論の双方が最終的に同じことを望んでいることを考えると、誰もが本当に幸せになる解決策があるはずだと私には思えます。私たちはこの質問をする最初の人ではあり得なかったので、同様の状況で他の人はどのような経験をしましたか？

おそらくここで何か不足しているかもしれませんが、あなたが行っている作業のチケットを作成することは、他のチケットの「抵抗層」の範囲に入らないのですか？

最近、チケット追跡システムを使用して実装しましたか？その場合は、座ってルールを作成し、これらのルールに従うことが期待されていることをチームに知らせます。これに、この作業のリファクタリングチケットの作成が含まれている場合は、そうしてください。早い段階で例外を作成することはできません。例外が発生すると、チームが設定しようとしているプロセス全体が失敗する可能性があります。

チケットトラッキングシステムをしばらく使用している場合、なぜこれが「レジスタンスレイヤー」になるのか理解できません。あなたのチームはすでにJiraを開いてチケットを確認することに慣れているはずであり、チケットの作成に慣れているはずです。

すべてのリファクタリング作業を1か所に留めておきたい場合は、このためのメインチケットを作成し、チームにその下でタスクを実行してもらいます。その後、開発者がこのための新しいタスクを作成するのに5秒ほどかかり、そのタスクに時間を記録できます。

プロジェクトマネージャー、チームリーダー、および開発者は、リファクティングの作業に費やす時間を知る必要があります。あなたはそれが時間のブラックホールになりたくないのです。チケットがあると、開発者は自分の仕事に責任を持ちながらマネージャーを提供し、作業に費やす時間を追跡する場所をリードします。

理想的にはそうです。

コードベースに加えた変更には、理由があります。これは、お客様のリクエスト-最も一般的/可能性の高いもの、またはリファクタリングの例のように内部で発生したアイテムの場合があります。

つまり、変更が加えられた時期を追跡するだけでなく、変更セットをリンクして、変更が加えられた理由を説明する何かに戻すことができます。なぜこれが単なるチェンジセットのコメントではないのですか？これが適切でない理由はいくつかあります。

• 作業項目とチェンジセットの間には常に1対1のマッピングがあるわけではありません-項目を完了するためにいくつかの編集セットが必要になる場合があります。
• チェンジセットのコメントは、通常、開発者以外には表示されません。または、ワークアイテムに他のドキュメントを添付する必要がある場合があります。

コードのリファクタリングは、品質を改善することが非常に望ましい一方で、固有のリスクでもあります。これは、単一のバグによりシステム全体が機能しなくなり、単一の「問題」を解決することでアプリケーション全体に副作用（おそらく予期しない）が生じる「基礎」コードを扱う場合に特に当てはまります。

関係するコードの種類に関係なく、リファクタリングが特定の問題（チケット）のコードに限定されていない場合、QAが関係し、影響を受けるコードベースの部分を認識させる必要があります。彼らは、これらの部品に対して完全な回帰テストを実行して、何も滑らないことを確認する必要があります。そして、もしあなたがリファクタリングをすることに自信を感じさせるような完全なユニットテストのセットを持っているなら、おそらく彼らはそうしなければならないでしょう。単体テストは多くのテストを行いますが、多くのテストも失敗します。

したがって、コードの品質が重要であれば、はい、コードを改善するための障壁はできるだけ少なくする必要があります。しかし、私はこれのためのチケットを作成することがどのように障壁であるかを見ることはできません。それは単に、QAがコードの品質を（im）改善する機会を得て、障害と見なされるものではなく、望ましいものであることを保証します。

「リファクタリング」よりもリファクタリングを具体的に説明できないと、間違っていると思います。リファクタリングには明確な目的と範囲が必要です。JIRAでリファクタリングタスクを個別に追跡することで、監査、レビュー、テストが容易になるだけでなく、リファクタラーが具体的な目標（たとえば、「モジュールXとY間の循環依存関係を削除する」など）に集中するように強制され、単純により良いリファクタリング。

一方、リファクタリングが非常にシンプルでローカルであり、異なるタスクを実行することの副産物である場合、別のチケットで追跡するのではなく、元のタスクチケットにのみ記録します。他の人の仕事に影響を与えます。

はい、理想的には、コードで行うすべての変更はJIRAアイテムに関連付けられ、追跡可能である必要があります。他の人が指摘したように、特定の変更が行われた理由と、それに関連する他の変更を特定できるはずです。

レガシープロジェクトでEpicsを長期間リファクタリングすることは問題ありません。ただし、これらを特定の目的で、コードの特定の領域に集中するように努力する必要があります。たとえば、「循環依存関係を排除するためにモジュールFooとBarをリファクタリングする」、「重複を削除して継承階層をクリーンアップするためにクラス階層Aをリファクタリングする」などです。

リソースが限られているレガシーコードに取り組む場合、技術的な負債を削減するための可能な方法を優先して、可能な限り最高の投資収益率を達成する必要があります。したがって、可能なリファクタリング、それらの重要性、リスク、コスト、および利益の分析は、ジョブを開始する前にとにかく行う必要があります。また、大規模なリファクタリングの進行状況を追跡し、いつ終了するかを知ることも重要です。これらの必要なタスクと比較して、私見では、JIRAアイテムを管理する実際の労力は最小限です。

PCIコンプライアンス（ビジネスの近い将来の目標）にはこのレベルの追跡が必要であるという議論が行われました

これを意味している場合、管理者がコードベースの制御されていない変更を恐れる理由をある程度理解できますが、変更の追跡はソリューションのごく一部にすぎません。ログファイルなどを介してクレジットカード番号がシステムから漏洩しないことを確認するために、徹底的なシステムテストとコードレビューが必要です。リファクタリングは既存のコードの動作を変更するものではなく、これを証明するユニットテストがあるはずです。とにかく（自動リファクタリングツールはコードを壊すことができないという信念に頼ろうとしないでください-厄介な驚きを避けるためにユニットテストが必要です）。

理想的な世界では、クリスの答えは正しいです。ソフトウェアプロジェクトに関連付けられたコードまたはアーティファクトに変更を加えるたびに、このログが記録されます。提出、承認、適切な関係者への割り当て、推定作業量、実施作業、記録された合計時間、変更の簡単な説明を文書化する必要があります。

ただし、これは常に可能であるとは限りません。たとえば、私のIDEは、組織のコードガイドラインに基づいてコードファイルを再フォーマットするように構成されています。ファイルを開いて一致しない場合は、修正するのは簡単です。ファイルをCTRL + SHIFT + Fでフォーマットすると、すべてがフォーマットされます。インポートを修正するためにCTRL + SHIFT + Oを使用している可能性があります。これは、割り当てられた欠陥を修正する直前または直後に行います。

その場合は、実行した事実とその所要時間を常に記録する必要がありますが、変更を正式に行わないことは、変更を正式に割り当てて実装するプロセスを実行するよりも悪い場合があります。場合によっては、許可を求めるよりも許しを請う方が簡単です。その線を描く必要がある場所を正当化するのは、エンジニアとしてのあなた次第です。

概して、リファクタリングはワークフローの通常の部分として行う必要があります。バグAを修正するには、メソッドのその部分をテストする必要があるため、メソッドBとして抽出する必要があります。その間、フィールドCの名前がひどく悪いことに気づき、名前を変更します。

私の考えでは、これらの通常のリファクタリングは元のバグAに対して「課金」されます。それらは修正とともに送信され、修正とともにレビューされ、修正によってチケットが発行されます。それらは修正の一部です。

しかし、大規模で焦点が絞られていないリファクタリングも発生します。クラスDは大きすぎるという一般的な観察。Eの重複を排除すると、作業が容易になります。そして、それらのリファクタリングは、（特にテストのないコードベースで）実行するリスクが最も高いものの1つです。必ず、それらのチケットを作成してください。少なくとも通常のレビュープロセスを経てください。