リファクタリングのためにチームに余分なコードレビューの負担をかける
Martin Fowlerによるリファクタリングを読んでいて、私のコーディングに提案されているパターンで作業しています。これにより、サービスの2つのコードレビューが大幅に長くなり、コードレビューをリファクタリングするだけになりました。 CRに説明的なコメントを散らかしたとしても、レビュー担当者が私が何をしているかを知るのは困難です。私のチームがCRのリファクタリングにそれほど時間をかけないようにするプロセスはありますか？または、この面での一般的なアドバイスだけですか？
リファクタリングのためのリファクタリングは、たとえそれがより優れたコードであったとしても、特にビジネスコンテキストにおいては、単に価値がないだけです。
指摘したように、コードレビューは長く、チームが適切にレビューするのは困難です。しかし、適切なレビューを彼らに与えないことは、実行可能な選択肢ではありません。あなたが利用できない（または去る）場合、他の人々がコードを維持する必要がある場合はどうなりますか？彼らはコードの現在の状態を理解し、修正することができます。変更を検討して質問する機会がない場合、変更とそれがシステムに与える影響を理解しているのはあなただけです。別の目または2つの目も、バグ（おそらく、テストカバレッジが思ったほど良くない）やパフォーマンスの問題が発生していないことを確認するのに役立ちます。プルリクエストにゴム印を付けたくありません。
私の推奨は、これらの変更を計画するためにチームとよりよく協力することです。あなたの意見では、ソフトウェアの理解と保守を容易にするいくつかのリファクタリングを特定したので、それらをどこかに記録して、忘れられないようにし、他の作業で適切に計画できるようにする必要があります。チーム。私がこれまで取り組んできたチームでは、彼らは通常、欠陥追跡システムをこれに使用しており、多くの場合、技術的な負債に特化したチケットタイプ、ラベル、またはタグが付いています。発生すると思われることについて、必要なだけ詳細に調べることができます。この場合、おそらくプルリクエストを作業にリンクしますが、すぐにマージされるとは期待しないでください。
これらのコードの変更に取り組む代わりに、将来的には、作業を実行する可能性を記録し、チームと話し合い、付加価値のある作業に取り組んでいることを確認することをお勧めします。おそらく、チームはこのタイプの作業が貴重であることに同意するでしょう。もしそうなら、彼らは適切なコードレビューを行う時間を作ります。ただし、それが価値がない場合、それは無駄になります（Wordの無駄のない意味で-潜在的なリリースと待機のためにマージされない部分的に行われた作業は、無駄であり、無駄のない開発プロセスから無駄を排除しようとします）。
リファクタリングは技術であり、成果物ではありません。
レビュー対象のコードは、保守、拡張、または理解が容易である必要があります。もしそうなら、リファクタリングは、次の課題をより短時間で提供する準備ができている「前払い」アプローチです。このような柔軟性は、チームが市場シェアを獲得するのに役立つ場合があり、少なくとも次の緊急事態に耐えることができます。
検討中のコードがそのような利点を実証できない場合（そして私は口頭によるパターンよりもデモを好む場合）、リファクタリングによってコードの維持、拡張、または理解が困難になった可能性があります。リファクタリングだけでは、コード品質の指標ではなく、コード品質の異なる状態間をどのように移動するかを示します。
利点が明らかな場合、リファクタリングに対する反対論は、仕事をすることに対する反対論にすぎません。このような議論により、コードはおそらく貧弱な状態に置かれました。技術的負債を返済する時が来たので、チームは支払いをさらに数か月（または数年）延期できるかどうかを尋ねています。
利点が不明確な場合、リファクタリングに対する反対論は、疑わしい価値をもって仕事をすることに対する反対論です。このような議論は健全であり、チームが時間と労力を浪費することに熱心でないことを示しています。
問題は評価の1つですが、苦情がテクニックではなく値に関するものである場合、値を評価することは困難です。私はチームの不満に値に関するいくつかのコメントを含めるようにしようと思います。それは、値が問題であるかどうか、または行われる作業の量だけを判断するのに役立つはずです。
（ユーモアを込めて）説明すると、あなたの歩行をこれ以上容認したくないという不満があり、非常に多くの時間と労力がかかるため、歩行を停止するよう要求することができます。あなたが正しい方向に歩いているかどうかに応じて、それはばかげた議論でも良い議論でもあります（目的地がどのように見えるかさえわかっているとすれば）。
リファクタリングする主な理由：
- 顧客に価値のある機能を簡単に追加できるようにするためのリファクタリング。
- 優先度の高いバグの原因となった不適切なスタイルの選択を削除するためのリファクタリング。
- ロジックを予測するのが面倒で困難なコードをテストするためのリファクタリング。
- このコードを読みやすくするためのリファクタリング...ちょっと待って、ここで行う作業がないのに、なぜこのコードを見ているのですか？
4番目はいつも苦労しているものです。リファクタリングを確認したいのですが、正当化できません。時々、私はこのようなものをリファクタリングし、頭をきれいにしようとしているだけなので、決して入れません。私はジャンクフォルダーにそれをダンプします。ジャンクフォルダーは、再び日の目を見ることはないでしょう。誰かが私に何をしているのかと尋ねられたら、「ああ、コードベースを調べようとしているだけです。指で読むこともあります」と言っています。
これで何も問題はありません、あなたがするより良いことは何もないとき。
リファクタリングは素晴らしい場合がありますが、トリッキーになる可能性があるため、そのように取り組む必要があります。
仕事では boy-scoutルール に従います。つまり、コードに触れるたびに、仕事の範囲内でコードをクリーンアップしようとします。
たとえば、単一のクラスのバグの修正に取り組んでいる場合、タイプミス、紛らわしいメソッド名、または冗長なコードを探すこともあります。そのクラスの全体的なデザインと構造に問題があり、それが親/子/クライアントである場合、チームとプルリクエストでその問題をメモしますが、変更するつもりはありません。
非常に一般的なクラスの使用方法や一般的なインターフェースの更新、ロジックの混乱、SRPなどのリファクタリングに関しては、時間の経過とともにそれらのリストをゆっくりと作成し、スプリントごとに1回、または余分なサイクルがある場合は2回、彼らはリファクタリングのためにいくつかのポイントを取ることができ、一度にすべてに取り組み、チーム全体がこれを認識して準備しています。
ここで注意すべき点は、完全なリファクタリングに終わりはないということです...それは常に進行し続けるうさぎの穴です。したがって、リファクタリングは十分に計画され、明確にスコープされ、それに応じて時間枠が設定されている必要があります。
がんばって！