大きなファイルのリファクタリングを処理する最良の方法は何ですか？

現在、残念ながらソフトウェア品質ガイドラインが常に守られているわけではないファイルを含む、より大きなプロジェクトに取り組んでいます。これには、明らかに複数の異なる機能を含む大きなファイル（2000〜4000行を読む）が含まれます。

次に、これらの大きなファイルを複数の小さなファイルにリファクタリングします。問題は、彼らがとても大きいので、異なるブランチの複数の人々（私を含む）がこれらのファイルで作業していることです。ですから、これらのリファクタリングを他の人々の変更とマージすることが難しくなるので、私は実際に開発とリファクタリングから分岐することはできません。

もちろん、全員がマージしてファイルを開発し、ファイルを「フリーズ」し（つまり、誰もファイルを編集できないようにする）、リファクタリングしてから「フリーズ解除」する必要があります。しかし、リファクタリングが完了するまでこれらのファイルに対する作業を基本的にすべて停止する必要があるため、これもあまり良くありません。

だから、リファクタリングする方法がありますか、他の誰かに作業を停止することを要求しないでください（長い間）、または開発のために機能ブランチをマージして戻しますか？

これは社会的な問題ではなく技術的な問題であることを正しく理解しています。過度のマージ競合を回避したい場合、チームはこれらの競合を回避する方法で協力する必要があります。

これはGitの大きな問題の一部であり、分岐は非常に簡単ですが、マージには依然として多くの労力がかかる可能性があります。開発チームは多くのブランチを立ち上げる傾向があり、そのコンテキストを理解せずにGit Flowをエミュレートしようとしている可能性があるため、それらのマージが難しいことに驚いています。

高速で簡単なマージの一般的なルールは、大きな機能の違いが累積するのを防ぐことです。特に、機能ブランチは非常に短命でなければなりません（数か月ではなく、数時間または数日）。変更を迅速に統合できる開発チームは、マージの競合が少なくなります。一部のコードがまだ製品の準備が整っていない場合は、機能フラグを使用して統合することはできますが、機能を無効にすることは可能です。コードがmasterブランチに統合されるとすぐに、実行しようとしている種類のリファクタリングがアクセス可能になります。

差し迫った問題には多すぎるかもしれません。ただし、リファクタリングを実行できるように、このファイルに影響する変更を週の終わりまでマージするように同僚に依頼することは実行可能です。待機時間が長くなると、マージの競合自体を処理する必要があります。それは不可能ではなく、回避可能な作業です。

また、依存コードの大規模な分割を防ぎ、API互換の変更のみを行うこともできます。たとえば、いくつかの機能を別のモジュールに抽出する場合：

1. 機能を別のモジュールに抽出します。
2. 古い関数を変更して、呼び出しを新しいAPIに転送します。
3. 時間が経つにつれて、新しいAPIへのポート依存コード。
4. 最後に、古い関数を削除できます。
5. （機能の次の束のために繰り返します）

この複数ステップのプロセスにより、多くのマージの競合を回避できます。特に、抽出した機能を他の誰かが変更している場合にのみ競合が発生します。このアプローチのコストは、すべてを一度に変更するよりもはるかに遅く、一時的に2つの重複したAPIがあることです。これは、何か緊急事態がこのリファクタリングを中断し、重複が忘れられるか優先度が下げられるまで、それほど悪くありません。

しかし、最終的には、どのソリューションでもチームと調整する必要があります。

より小さなステップでリファクタリングを行います。大きなファイルに名前があるとしましょうFoo：

1. 新しい空のファイルを追加し、Bar「トランク」にコミットします。

2. Fooに移動できるコードの小さな部分を見つけますBar。移動を適用し、トランクから更新し、コードをビルドしてテストし、「トランク」にコミットします。

3. ステップ2を繰り返しまでFooとBar同じサイズを持っている（またはあなたが好むどんなサイズ）

そうすれば、次回チームメイトがトランクからブランチを更新するときに、「小さな部分」で変更を取得し、それらを1つずつマージできます。他の誰かがその間にトランクを更新したため、ステップ2でマージの競合が発生した場合も同様です。

これにより、マージの競合や手動で解決する必要はなくなりませんが、各競合をコードの小さな領域に制限するため、管理しやすくなります。

そしてもちろん-チームでリファクタリングを伝えます。あなたが何をしているのかを仲間に知らせてください。そうすれば、特定のファイルのマージの競合を予想しなければならない理由がわかります。

ファイルをアトミック操作として分割することを考えていますが、中間的な変更を加えることができます。ファイルは時間の経過とともに徐々に大きくなり、時間の経過とともに徐々に小さくなります。

長い間変更する必要のない部分を選択し（git blameこれで解決できます）、最初にそれを分割します。その変更を全員のブランチにマージし、次に分割する最も簡単な部分を選択します。たぶん、1つの部分を分割するだけでも大きなステップなので、最初に大きなファイル内でいくつかの再配置を行う必要があります。

人々が頻繁にマージして開発に戻っていない場合は、それらをマージした後、その機会に変更したばかりの部分を分割することを奨励する必要があります。または、プルリクエストのレビューの一環として、分割を行うよう依頼します。

アイデアはゆっくりと目標に向かって進むことです。進行が遅いように感じますが、突然、コードがはるかに優れていることに気付くでしょう。オーシャンライナーを回すには長い時間がかかります。

この問題の通常の解決策とは異なる解決策を提案します。

これをチームコードイベントとして使用します。できる人全員にコードをチェックインしてもらい、ファイルをまだ使用している他の人を助けてください。関係者全員がコードをチェックインしたら、プロジェクターを備えた会議室を見つけて、協力して新しいファイルに移動します。

これに特定の時間を設定することで、1週間分の議論に終わりが見えないようにすることができます。代わりに、これは必要なものがすべて見られるまで、毎週1〜2時間のイベントになることもあります。ファイルをリファクタリングするのに1〜2時間しか必要ないかもしれません。たぶん、試すまでわかりません。

これには、リファクタリングで全員が同じページにいるという利点があります（しゃれを意図していません）が、ミスを避けたり、必要に応じて維持できるメソッドのグループ化について他の人から入力を得るのにも役立ちます。

このような方法で行うと、組み込みのコードレビューがあると考えることができます。これにより、適切な量の開発者がコードをチェックインし、レビューの準備ができたらすぐにコードを承認できます。あなたはまだあなたが見逃したものについてコードをチェックすることを望むかもしれませんが、それはレビュープロセスがより短いことを確認するための長い道のりになります。

これは、すべての状況、チーム、または企業で機能するとは限りません。作業は、これを簡単に実現する方法で配布されないためです。また、開発時間の誤用として（誤って）解釈されることもあります。このグループコードには、マネージャーとリファクタリング自体からの賛同が必要です。

このアイデアを上司に売り込むには、コードレビュービットと、最初からどこにいるのかを知っている全員に言及してください。開発者が新しいファイルのホストを検索する時間を失うのを防ぐことは避ける価値があります。また、開発者が物事が終わった場所や「完全に欠けている」場所についてPOを取得しないようにすることは、通常良いことです。（メルトダウンが少ないほど良い、IMO。）

この方法で1つのファイルをリファクタリングすると、それが成功して有用であれば、より多くのリファクタリングの承認をより簡単に取得できる場合があります。

ただし、リファクタリングを行うことに決めた場合は、幸運を祈ります！

この問題を修正するには、共有リソース（コード自体）を変更しようとしているため、他のチームからの賛同が必要です。そうは言っても、人を混乱させることなく巨大なモノリシックファイルを「移行」する方法があると思います。

また、個々のファイルのサイズに加えて、巨大なファイルの数が手に負えないほど増えていない限り、一度にすべての巨大なファイルをターゲットにしないことをお勧めします。

このような大きなファイルをリファクタリングすると、予期しない問題が頻繁に発生します。最初のステップは、大きなファイルが現在masterまたは開発ブランチにあるものを超えて追加機能を蓄積するのを止めることです。

これを行う最良の方法は、デフォルトで大きなファイルへの特定の追加をブロックするコミットフックを使用することだと思いますが、コミットメッセージ内の魔法のコメントなどで無効にすることができます@bigfileok。痛みはないが追跡可能な方法でポリシーを無効にできることが重要です。理想的には、コミットフックをローカルで実行でき、エラーメッセージ自体でこの特定のエラーをオーバーライドする方法を示す必要があります。また、これは私の好みですが、認識されていない魔法のコメントまたはコミットメッセージで実際に発生しなかったエラーを抑制する魔法のコメントは、コミット時の警告またはエラーである必要がありますので、必要かどうか。

コミットフックは、新しいクラスをチェックしたり、他の静的分析（アドホックかどうか）を行ったりする可能性があります。また、現在のファイルよりも10％大きい行数または文字数を選択して、大きなファイルが新しい制限を超えて拡大できないと言うこともできます。また、行数が多すぎたり、文字数が多すぎたり、w / eが増えたりして、大きなファイルを成長させる個々のコミットを拒否することもできます。

大きなファイルが新しい機能の蓄積を停止すると、一度に1つずつリファクタリングすることができます（同時に、コミットフックによって強制されるしきい値を減らして、再度成長するのを防ぎます）。

最終的に、大きなファイルはコミットフックを完全に削除できるほど小さくなります。

ホームタイムになるまで待ちます。ファイルを分割し、コミットしてマスターにマージします。

他の人は、他の変更と同様に、朝に変更を機能ブランチにプルする必要があります。