XPとリファクタリングを実践しながら、プルリクエストをレビューしやすくする

Question

私はTDDを実践し、積極的にリファクタリングしています。最近、一部の同僚は、結果のプルリクエストを確認するのが難しい、または多くの回帰テストが必要になると不満を述べています。

私がリファクタリングするとき、私は安全で振る舞いを維持するリファクタリングを使用することに慣れています。主に名前の変更とメソッドの抽出についてです。誰かが「これには多くのテストが必要だ」と言ったとき、私はそこにたどり着いた方法を彼らに示し、返答は「ああ、私はそれは多くのテストを必要としないと思う」ので、私の方法は品質の観点から健全です。

しかし、私は自分のプルリクエストを確認し、レビュー担当者の立場に立って、それらがどこから来ているのかを確認します。手順は必ずしも明確ではなく、結果として生じる変更は比較的大きくなる可能性があります（8ファイルなど）。

XPまたはTDDを実践して積極的にリファクタリングする場合、プルリクエストをレビュー担当者にとって使いやすいものにするにはどうすればよいですか？

Doc Brown · Accepted Answer

あなたが書いた

誰かが「これには多くのテストが必要になるだろう」と言ったとき、私はそこに着いた方法を彼らに示します

それで彼らはコミットログから「どうやってそこに着いたか」という情報を簡単に得ることができなかったので、あなたはそれを彼らに説明しなければなりませんでしたか？これは、コミットが大きすぎるか、コミットメッセージを改善する必要がある、またはその両方であるかのような印象を与えます。だから私は以下をお勧めします：

リファクタリングを動作に影響する変更から厳密に分離し、個別にコミットする
特に影響を受けるコード領域が「重複」する場合は、一度に複数のリファクタリングをコミットすることも避けてください。
あなたが行ったすべてのリファクタリングがコミットで言及されていることを確認し、書くことに集中してくださいなぜあなたは何かを変更しました。

たとえば、複数のファイルを操作する必要がある関数またはメンバー変数の名前を変更する場合、これを「抽出関数」リファクタリングと混同しないでください。代わりに、名前の変更をコンパイルしてコミットし、名前の変更の種類（およびおそらくそれを行った理由）をログに記述します。次に、「抽出関数」を別のコミットにして、関数を抽出した理由を説明します。たとえば、新しく抽出された関数を再利用して重複するコードもいくつか削除した場合は、それで十分です。この重複の削除がコード内の多くの場所に影響する場合は、別のコミットで行うことを検討してください。

このようにして、レビュー担当者が最新のプルリクエストを理解するのに問題がある場合、レビュー担当者はコミットログを確認して、変更の個々の手順を1つずつ実行できます。

Tajh Taylor · Answer

個人的な経験を除いて、この質問に他にどのように答えるかはわかりません。私のチームも似たような状況ですが、私のチームでの立場のおかげで、私の同僚はおそらく私のプルリクエストについて不満を言うことはあまりありません。それでも、チームが私が行ったことと、なぜリファクタリングしたのかをチームが理解できるようにし、ユニットテストまたは統合テストを通じて、行った変更が問題を引き起こさないことを確信しています。

私がすることは3つありますが、それらはすべてdisciplineに要約されます。あなた自身のコーディング習慣について規律を持つことに勝るものはありません。

割り当てられた問題に固執する。うまくいけば、あなたは何をすべきかを正確に説明するよく書かれた問題チケットを持っています。レガシーコードに飛び込むと、新しいコードに関係するすべての要素を「修正」し始めたくなることがよくあります。その誘惑に抵抗し、現在取り組んでいる問題を解決するために厳密に必要ではない修正のために新しい問題を提出してください。
意味のあるコミット。私は、問題に取り組み、それが終わったら単にgit commit -aを行う多くの開発者を見てきました。多くのファイルが変更され、変更に数日かかった場合、その単一のコミットには多くのものが含まれ、プルリクエストで評価することが困難になります。それほど頻繁ではありませんが、すべてのファイルまたは小さな変更を個別にコミットする開発者を見てきました。比較的単純なプルリクエストには数十のコミットがあります。ここでは、タスク分解が重要なスキルです。適切なコミットを行う方法について私が考える方法は、問題を解決するためにどのような手順を実行するかを箇条書きで言葉で説明することです。これで、（多かれ少なかれ）プルリクエストにあるコミットのリストと一致するはずです。もちろん、単一のコミットがビルドを壊さないようにすることは常にいいことです（プロジェクトのソースコード管理ポリシーに従ってコンパイルまたはテストします）が、それが不可能である場合もあります。私自身は、単一のコミットでコンパイルが壊れないようにすることを目指していますが、すべての作業が完了するまでテストはパスしない可能性があります。もちろん、TDDに厳密に従っている場合、テストは設計上、作業が完了するまで合格しません。
必要に応じてテストカバレッジを増やします。テストカバレッジに代わるものはありません。レガシーコードをリファクタリングしている場合、同等のテストが以前になかったとしても、適切なテストカバレッジを追加するのはユーザーの責任です。変更によって他の誰かによるリグレッションテストが必要になることがわかっている場合は、その取り組みをディスカッションの一部にする必要がありますbefore問題に取り組み始める。同僚が慣れ親しんだ動作のコードを変更することは公平ではありません（十分にカバーされていなくても）。また、変更をカバーするためのテストも提供しませんおよび他の人の追加作業を説明し、次にいくつかを説明します。変更していないコードにテストを追加することもあります。それが機能し、それに依存できることを自分で証明するためです。多くの場合、これは雑用のように感じられますが、将来の苦痛や心痛を大幅に軽減します。これは、あなたが説明したように追加の回帰カバレッジの必要性を否定するものではありませんが、将来のあなたに自信を与えます。

今、あなたがすでに規律あるコーダーであり、これらすべてのことをすでに行っている場合、リスクや変更に対する同僚の許容度があなたよりも低いか、またはチームがすべての変更に対応できる時間がないとチームが感じている可能性があります。。これらすべては、チームコミュニケーションを改善し、問題への取り組みが始まる前に影響をよりよく共有する必要性を示しています。

幸運を祈ります！

Solomon Ucko · Answer

役立つかもしれない1つのことは、コミットメッセージで使用したリファクタリングをリストすることです。