Reactアプリケーションでの無秩序なコード爆発を管理する方法
そこで、ReactでWebアプリケーションのUIをやり直すことにしました。レーンを6か月下っていくと、コンポーネントとレデューサー、サンクとアクションの完全な混乱があり、神はそうでないことを知っています。
Reducer.tsという名前の複数のファイルがあり、各ファイルは3000〜5000行で、それぞれに数千のリデューサー関数があります。
同じことは、actions.tsファイルとaccessor.tsファイルの場合にも当てはまります。興味深いことに、thunk.tsファイルは数百万に近い行を持つgodファイルです（誇張ですが、アイデアはわかりました）。
次に、APIサーバーへのすべての可能な呼び出しを処理する数千行の長さのapi.tsファイルがあります。
ルートレベルでは、1つのファイルに30,000行を超えるtypes.tsファイルがあり、すべてのTypeScriptタイプが定義されています。
私は小規模のReactアプリを使用して数年になりますが、このレベルのプロジェクトサイズと厄介なコードに触れたことはありません。
ユニットテストはまったくないことはすでにおわかりでしょう。
主な問題は、Reactが個別にリファクタリングおよび管理できる独立したコンポーネントを提供するという約束が、このシナリオでは完全に壊れているように見えることです。
明らかに、反応自体には問題はありませんが、私たちのケースでそれが使用されてきた方法は、適格ではありません。すべてが非常に相互に関連しており、すべての機能が少なくとも6〜10個のファイルに分散しているため、非常に単純なバグのコードを見つけるのにも数時間かかります。
ベテランの反応開発者への私の質問は以下の通りです：
Redux、thunk、types、accessorsを削除して、各コンポーネントのロジックをそのコンポーネント内に移動すると、それは基本的な罪になるのでしょうか？これにより、1つのアクションのコードを検索するために6〜10個のファイルをジャンプする必要がなくなります。
ストア、レデューサー、アクセサー、api.tsを保持する必要がある場合でも、すべてを同じファイルに保持し、それらをgodファイルにするのは宗教的な習慣ですか？処理しているアクション/機能ごとに、少なくとも個別のレデューサーまたはアクセサー、API呼び出し、またはサンクファイルを作成できますか？
大規模なReactアプリを構築する場合、コード編成に推奨される方法はありますか？
私は強力な単体テストのバックグラウンドを持っているので、メンテナンスを改善するために、クリーンで十分に分離されたテスト可能なコードを用意することが不可欠だと思います。
React世界ではプロジェクトが既に行われている方法が物事を行う正しい方法であるため、私は間違った方向に考えていますか？
手がかりをありがとう。
私の組織では比較的上級の人として、1つのファイルに30k行のような非常識なコード構造を持つPRをはっきりと拒否しています（その多くはコピーと貼り付けです）。
私の提案は、チームと話して、最高の、または少なくとも合理的に慣用的な、Reactプラクティスを認識させてから、それらを強制することです。
ただし、実際にそれを行う余裕があることを確認してください。つまり、問題が速度を低下させ、バグの頻度を大幅に増加させることを経営陣が理解していることを確認してください。
もちろん、混乱を一挙に修正することはすでに実行不可能です。私はいくつかのチケットを作成して、コード内の最も悪質な違反者を修正し、コードに触れるたびにコードを改善するよう要求しました（ここでも、時間を割り当てています）。
しかし、教育とチームのエンジニアからの賛同が最初に来ます。人々は、メリットが見られないような習慣には従いません。問題を説明し、可能な解決策を説明し、利点を説明します。数回のラウンドとある程度の忍耐が必要になる場合があります。
いずれにせよ、あなたが述べたことはReactの問題ではなく、エンジニアリング文化の問題であり、そこで修正する必要があります。
洞察をありがとうみんな。上記のコメントと投稿された回答で指摘されているように、私たちは複数の問題を抱えていました（これらの回答を読むまで、いくつかは目に見えませんでした）。
まだ長い間リファクタリングモードになっていますが、完了のために、参照用のヒントをここに投稿します。うまくいけば、将来的に誰かを助けるかもしれません。
最初の問題はコミュニケーションでした。 @ 9000、Flater、Gregが示唆したように、それは主に人の問題でした。
チームと率直に話し合った後、悪いアーキテクチャと厄介なコードに関係するのは私だけだったことがわかりました。厳しい締め切りは、誰もが箱から出して考えないようにするもう1つの理由でした。
1週間のうなり声のミーティングの後、最終的に、現在のコーディングプラクティスに問題があり、それに対処する必要があるという主要な事実に同意しました。
私たちが採用したアプローチは以下の通りです。
- アプリはすでに稼働しており、1,000人を超えるユーザーが使用しているため、遮断モードを使用できません。
- IntelliJ抽出機能を使用して、コードの一部を小さな独立したファイルに抽出し始めました
- コードが小さな独立したファイル/クラスに抽出されるたびに、その特定の部分の単体テストが追加されます。
- 私たちはゆっくりと着実に行くことにしました。したがって、リファクタリングは、開発者ごとに1日に1つまたは2つの抽出という一定のペースで進んでいます。遅いように見えますが、このペースでは、3か月以内に少なくとも30〜35％のコードベースが単体テストでカバーされるはずであり、現在よりもはるかに良好な状態になると推定しています。
- 100行を超える新しいクラス/ファイルがある場合は常に、少なくとも3人のレビュー担当者が議論し、（可能な場合は）より小さな単位にリファクタリングする必要があるという任意のレビュールールを追加しました。
これまでのところ、結果に非常に満足しています。プッシュされるすべての新しいコードはすでにより良い形になっており、古いコードはよりテスト可能で理解しやすくなっています。
コードの編成について心配しているのはあなただけですか？チームとコーディング標準に関する議論を進める準備はできていますか？管理についてはどうですか、彼らはハイテク債務のために停止に陥るリスクを知っていますか？
最初のラウンドでは、extract functionまたはまたは（== --- ==）のような自動リファクタリングがクラスをファイルに移動しますはあなたの友達です。 JetBrains これでうまくいきました。他にもあると思います。テストがない場合でも、これらは比較的安全で、コード内の密結合を減らすための良い出発点になります。