リファクタリング作業を含むすべての開発に追跡の問題を伴うべきですか？
討論：リファクタリング作業を含むすべての開発には、追跡の問題を伴う必要がありますか？ （私たちの場合、Jira）
共通点：私たちの主な目標は品質です。動作する製品は、リリースごとに、何よりも重要です。私たちのコードベースは古く、自動テストが欠けています。私たちはこれに取り組んでいますが、それは長期的なプロジェクトであり、暫定的なプロセスが必要です。
位置1：リファクタリング作業はJiraで追跡する必要があります。変更と明らかに関係がない場合は、別の問題を提起する必要があります。そうしないと、レビューとテストが省略され、私たちの主な目標にリスクが生じます。 PCIコンプライアンス（ビジネスの近い将来の目標）にはこのレベルの追跡が必要であるという議論が行われました。私はそれがどんなレベルの確実性でも真実か偽りであると言う立場にはありません。
位置2：コードの品質は非常に重要です。それが良くなればなるほど（ある程度、私たちがどこにも近くないほど）、動作する製品をリリースし続ける可能性が高くなります。どんなに小さくても、リファクタリングの方法で障壁となるものはすべて、私たちの主な目標に対するリスクです。多くの場合、IDEが機能するので、とにかくうまくいかない可能性はありません。
以下の場合があります：
開発者が「リファクタリング」と関連するリビジョン番号をカードに書き込んだ場合、両方の位置を満たしますか？正直なところ、これは誰もが等しく不幸になるだろうと感じています。それでも、リファクタリングの実行にはある程度の抵抗はありますが、十分な追跡はできません。
反復のリファクタリング作業をカバーする包括的なJiraの問題があるのはどうですか？はい、これにより開発者の抵抗層が削除されますが、Jiraの問題があることによる追跡の利点も削除されるのではないかと心配しています。 QAは何をテストすべきかを明確に理解する方法を教えてください。これは政治的な解決策のようであり、軽量だが最終的には無意味なプロセスを追加することで誰もが落ち着くようにしています。
議論の双方が最終的に同じことを望んでいることを考えると、誰もが本当に幸せになる解決策があるはずだと私には思えます。私たちがこの質問をする最初の人になることはできなかったので、他の人が同じような状況でどのような経験をしたのでしょうか？
おそらくここで何か不足しているかもしれませんが、あなたが行っている作業のチケットを作成することは、他のチケットの「抵抗層」の範囲に入らないのですか？
最近、チケット追跡システムを使用して実装しましたか？もしそうなら、座ってそれを使用するためのルールを作成し、チームがこれらのルールに従うことが期待されていることを知らせます。これに、この作業のリファクタリングチケットの作成が含まれている場合は、そうしてください。早い段階で例外を作成することはできません。そうしないと、チームが設定しようとしているプロセス全体が失敗する可能性があります。
チケットトラッキングシステムをしばらく使用している場合、なぜこれが「レジスタンスレイヤー」になるのか理解できません。チームは、Jiraを開いてチケットを確認することにすでに慣れており、チケットの作成に慣れている必要があります。
すべてのリファクタリング作業を1か所にまとめたい場合は、このためのメインチケットを作成し、チームにその下で実行している作業のタスクを実行させます。次に、開発者がこのための新しいタスクを作成するのに5秒ほどかかり、そのタスクに時間を記録できます。
プロジェクトマネージャー、チームリーダー、および開発者は、リファクト作業にどれだけの時間がかかるかを知る必要があります。あなたはそれが時間のブラックホールになりたくないのです。チケットを持っていると、開発者は自分の作業に責任を持ちながら、マネージャーを提供し、作業に費やされた時間を追跡する場所を導きます。
理想的にはそうです。
コードベースに加えた変更には、その背後に理由があるはずです。これは、リファクタリングの例のように、顧客の要求（最も一般的/可能性が高い、または内部で発生したアイテム）である可能性があります。
これは、変更が加えられた時期を追跡するだけでなく、変更セットをsomethingにリンクして、変更が行われた理由を説明できることを意味します。なぜこれは単なるチェンジセットコメントではないのですか？これが適切でない理由はいくつかあります。
- 作業項目と変更セットの間には常に1：1のマッピングがあるとは限りません。項目を完了するには、いくつかの編集セットが必要になる場合があります。
- チェンジセットのコメントは通常、開発者以外には表示されません。または、他のドキュメントを作業項目に添付する必要がある場合があります。
コードのリファクタリングは、品質を向上させるために非常に望ましいものですが、固有のリスクでもあります。これは、単一のバグによってシステム全体が機能しなくなり、単一の「問題」を解決するとアプリケーション全体に副作用（おそらく予期しない）が発生する「基盤」コードを処理する場合に特に当てはまります。
関係するコードのタイプに関係なく、リファクタリングが特定の問題（チケット）のコードに限定されていない場合、QAが関係し、影響を受けたコードベースの部分を認識させる必要があります。何もすり抜けていないことを確認するために、これらのパーツに対して完全な回帰テストを実行する必要があります。そして、おそらく特に、リファクタリングの実行に自信を持っていただける単体テストのフルセットがある場合でも、そうする必要があります。単体テストは多くのテストを行いますが、多くのテストも失敗します。
したがって、コードの品質が重要であれば、はい、コードを改善するための障壁はできるだけ少なくする必要があります。しかし、私はこれのためのチケットを作成することがどのように障壁であるかを見ることはできません。それは単に、QAがコードの品質を（改善）する機会を得ることができることを保証するだけであり、障害と見なされるものではなく、望ましいものであるべきです。
「リファクタリング」よりも具体的にリファクタリングを説明できないのなら、それは間違っていると思います。リファクタリングには明確な目的と範囲が必要です。 JIRAでリファクタリングタスクを個別に追跡すると、監査、レビュー、テストが簡単になるだけでなく、リファクタリング担当者は具体的な目標（「モジュールXとYの間の循環依存関係を削除する」など）に集中するようになり、単純により良いリファクタリング。
一方、リファクタリングが非常にシンプルでローカルであり、異なるタスクを実行したことによる副産物である場合、別のチケットで追跡することはせず、元のタスクチケットにのみ記録します（可能な場合）。他の人の仕事に影響を与えます。
はい。理想的には、コードに加えたすべての変更をJIRAアイテムに関連付けて、追跡できるようにする必要があります。他の人が指摘したように、特定の変更が行われた理由と、それに関連する他の変更を特定できるはずです。
従来のプロジェクトでエピックを長期間リファクタリングすることは問題ありません。私たちにもエピックがあります。ただし、特定の目的で、コードの特定の領域にこれらを集中させるように努める必要があります。そうしないと、コードを制御し続けることが非常に困難になります。例えば。 「モジュールFooとBarをリファクタリングして循環依存を排除する」、「クラス階層Aをリファクタリングして重複を削除し、継承階層をクリーンアップする」。
リソースが限られているレガシーコードで作業する場合、可能な限り最高の投資収益率を達成するために、技術的負債を削減するための可能な方法を優先する必要があります。したがって、可能なリファクタリング、それらの重要性、リスク、コスト、および利益の分析は、仕事を始める前にとにかく行う必要があります。また、大規模なリファクタリングの進行状況を追跡し、いつ終了するかを知ることも重要です。これらの必要なタスクと比較して、私見では、JIRAアイテムを管理する実際の労力は最小限です。
PCIコンプライアンス（ビジネスの近い将来の目標）には、このレベルの追跡が必要であるという議論がなされています。
this を意味する場合、管理者がコードベースの制御されていない変更を恐れる理由は理解できますが、変更の追跡はソリューションのごく一部にすぎません。クレジットカード番号がログファイルなどを介してシステムから漏洩しないことを確認するために、徹底的なシステムテストとおそらくコードレビューが必要です。リファクタリングは既存のコードの動作を変更するものではなく、これを証明するユニットテストがあるはずです。とにかく（自動リファクタリングツールはコードを壊すことができないという信念に頼ろうとしないでください-厄介な驚きを避けるためにユニットテストが必要です）。
理想的な世界では、 クリスの答え が正しいです。ソフトウェアプロジェクトに関連するコードまたはアーティファクトに変更を加えるたびに、このログが記録されているはずです。提出、承認、適切な関係者への割り当て、推定作業量、実行された作業、記録された合計時間、および文書化された変更の簡単な説明を提出する必要があります。
ただし、これは常に可能であるとは限りません。たとえば、my IDEは、組織のコードガイドラインに基づいてコードファイルを再フォーマットするように構成されています。ファイルを開いて一致しない場合は、修正するのは簡単です-CTRL +ファイルのSHIFT + Fはすべてをフォーマットします。おそらく、インポートを修正するためにCTRL + SHIFT + Oを実行します。これは、割り当てられた欠陥を修正する直前または直後に行います。
その場合、実行した事実と所要時間を常にログに記録する必要がありますが、変更を正式に割り当てて実装するプロセスを実行するよりも、今変更を行わない方が悪い場合があります。場合によっては、許可を求めるよりも許しを請う方が簡単です。その線を描く必要がある場所を正当化するのは、エンジニアとしてのあなた次第です。
概して、リファクタリングはワークフローの通常の部分として実行する必要があります。バグを修正するには[〜＃〜] a [〜＃〜]、メソッドのそのビットをテストする必要があるため、メソッドとして抽出します[〜＃〜] b [〜＃〜]。その間、フィールド[〜＃〜] c [〜＃〜]は非常に不適切な名前になっていることに気づくので、名前を変更します。
私の考えでは、これらのnormalリファクタリングは元のバグに対して「課金」されます[〜＃〜] a [〜＃〜]。それらは修正とともに提出され、修正とともにレビューされ、修正とともに発券されます。それらは修正の一部です。
しかし、大規模で焦点が絞られていないリファクタリングも発生します。クラス[〜＃〜] d [〜＃〜]は大きすぎるという一般的な観察。 [〜＃〜] e [〜＃〜]の重複を排除すると、作業が容易になります。そして、これらのリファクタリングは、（特にテストのないコードベースで）実行する最もリスクの高いものの1つです。ぜひ、それらのチケットを作成してください。少なくとも通常のレビュープロセスを経てください。