Reactコンポーネントを再利用する方法（翻訳）

コードの再利用は、ソフトウェア開発で最も一般的なキーポイントの1つです。 多くのフレームワークとライブラリは、再利用のためにコードを構造化するように設計されています。 結局のところ、各ツールには、この目標を達成するための独自のアプローチだけでなく、コードの再利用に関する独自の定義もあります。

コードの再利用とはどういう意味ですか？

コードの再利用の真の定義は特別なプロセスではなく、開発戦略です。 再利用可能なコンポーネントは、最初は再利用性を念頭に置いて設計する必要があり、慎重な計画と直感的なAPIが必要です。 最新のツールとフレームワークはサポートと刺激が可能ですが、再利用はテクノロジーの助けを借りてのみ不可能です。これには、チーム間の合理化されたプロセスと、会社のすべてのレベルでのコミットメントが必要です。

したがって、再利用について話すとき、これは技術的な部分だけを意味するものではありません。 また、企業文化、トレーニング、および他の多くの考慮事項が含まれています。 ここではその一部を取り上げますが、実際にはコードの再利用は開発のすべての段階と組織のあらゆるレベルに影響するプロセスです。

Walmartは、Sam's Club、Asda、Walmart CanadaやWalmart Brazilなどの地域関連会社を含むいくつかのブランドで構成されています。 これらのブランドには、数百の開発者によって作成およびサポートされている多数のアプリケーションがあります。

これらの各ブランドはインターネット上で独自の位置を占めているため、それぞれが、カルーセル、パンくず、ポップアップ、支払いフォームコンポーネントなど、すべてのウォルマートブランドに共通のコンポーネントに取り組んでいる開発者を持っています。 他のチームが引き渡した同じ作業を複製することは時間とお金の無駄であり、異なるチームが同じ間違いをすることも可能です。 重複を排除することにより、開発者はプロジェクトにより集中できます。

バックエンドでは、コードの使用がより直感的です。一部のサービスは、さまざまなブランドからのリクエストを受け入れ、このブランドに関連するデータを返すことができます（データの形式に応じてこれに対処する方法は異なります）。 フロントエンドの場合、サーバーからのデータは特定のブランドに従って変換およびスタイル設定されるため、状況はもう少し複雑です。 フロントエンドコードの再利用は、完全に解決された問題ではありません。

@WalmartLabsでのReactコンポーネントの再利用

Walmart.comでReactを選択した理由は、主にそのコンポーネントモデルがコードの再利用の良い出発点であり、特に状態管理のためにReduxと組み合わせた場合です。 それにもかかわらず、Walmartにはフロントエンドコードの再利用が依然として困難です。

コード再利用ツール

最初のタスクは、コード共有の技術的手段に関連しています。 コンポーネントは、バージョン管理され、インストールが簡単で、更新されている必要があります。 すべてのReactコンポーネントを配置する別のGitHub組織をセットアップしました。 現在、コンポーネントは、それらを作成したコマンドに基づいてリポジトリ内で結合されていますが、より機能的な外観に移行中です。たとえば、Breadcrambs、Tab、Sidenav Linksコンポーネントを含むナビゲーションリポジトリです。 すべてのコンポーネントを内部npmレジストリに保持します。これにより、特定のバージョンのコンポーネントをインストールでき、コンポーネントが更新されたときにアプリケーションが突然クラッシュすることはありません。

このコードは複数のチームで使用されているため、数百のコンポーネントの一貫したパッケージ構造と標準に従う必要があります。 そのため、 コンポーネントおよびアプリケーション用の電極アーキタイプの作成に至りました。 アーキタイプには、eslint、babel、およびwebpack構成ファイルが含まれ、Gulpタスクとnpmスクリプトを使用して依存関係を管理する主要な場所です。 標準化された構造で開発を開始すると、会社全体で高い標準を維持できます。また、開発者が他の人のコードに自信を持ち、コードを再利用できる可能性が高まります。 また、異なる画面解像度を使用してEslint、パフォーマンステスト、およびクロスブラウザーテストを実行する、合理化されたContinious IntegrationおよびContinous Deploymentプロセスの信頼性も向上します。 リクエストプールを作成する際、Continious Integrationはコンポーネントのベータバージョンを公開し、このコンポーネントを使用するすべてのアプリケーションの機能テストを実行できます。 これにより、プルリクエストが何も壊さないことが保証されます。

メタチーム

このプロジェクトの初期には、ほとんどの共有コンポーネントは特定のチームによってのみ導入され、これらのコンポーネントは非常に迅速に変更されました。 最終的に、電極とウォルマートの構造を内部から深く理解しているいくつかの開発者を選択し、メタチームと呼ぶグループを作成しました。 これらの人々は、コンポーネントの組織に含まれるコードをレビューし、すべてのベストプラクティスへの準拠を確保し、一般的に可能な方法で貢献し、支援するために、数週間ごとに数時間または1日費やします。 このチームはまた、組織全体で作成されているものに関する一般情報を収集し、独自のチームで電極を宣伝しました。 また、メタチームのメンバーは、チームの今後のアーキタイプの変更に関する情報を共有し、メインの電極チームのフィードバックを収集しました。

良いスタートでしたが、コードの再利用を改善するための追加の機会を見ました。

数百のコンポーネントを検出する問題

Slackチャンネルで多くの同様のメッセージに気づき始めました。 開発者は、特定のタスク用のコンポーネントがすでに存在するかどうかを尋ねました。 UXチームは、使用可能なコンポーネントを確認したいと考えていました。 マネージャーは、他のチームが作成するコンポーネントに関心がありました。 これらすべてのメッセージの共通のスレッドは、コンポーネントの検出でした。 どのコンポーネントが利用可能かを見つけ、それらがどのように使用され、どのように対話するかを確認し、実装、構成、依存関係についてさらに学ぶための迅速で簡単な方法が必要です。

この問題に対する私たちの答えは電極エクスプローラーでした。 それは以前の投稿で話しました。 Explorerを使用すると、開発者は@WalmartLabsで利用可能な数百のコンポーネントを表示し、ドキュメントを読んでブラウザで実際にどのように見えるかを確認できます。 Electrode Explorerは組織内のすべてのReactコンポーネントにWebインターフェースを提供するため、開発者はコンポーネントを確認して対話するためにnpm install



を実行する必要はありません。

重複を完全に排除することの難しさ

コードを再利用するためのこれらのすべてのツールとプロセスを使用しても、依然として困難がありました。 問題の1つは、チームが他のチームにとって有用であることに気付かずに新しいコンポーネントを開発することが多かったということでした。 コンポーネントは、コード再利用エコシステムに最初に含まれていなければ再利用できませんでした。 コンポーネントの一般的なシステムのフレームワーク内でさえ、多くの重複を観察しました。同様のタスクを持つ他のコンポーネントのアプローチとはわずかに異なるコンポーネントもありました。 1つの技術的ソリューションでは不十分であることに気付きました。会社の規模に関する考え方を変える必要があり、すべてのレベルのすべての利害関係者がコードの再利用に焦点を当てたアプローチを使用しています。 これには、プロジェクト時間を割り当ててコンポーネントを要約し、新しいコンポーネントを作成する代わりに既存のコンポーネントを拡張し、可能な限りコード共有の機会を意識的に探します。

このプロセスを支援するために、新しいコンポーネントを提供できるプロセスを作成しました。 このシステムの一部として、開発者は新しいコンポーネントを検討してから作業を開始します。 これにより、他のチームの開発者は、既存のソリューションまたは代替アプローチを提案する機会を得ることができ、チームの他の人々に何が起こっているかを常に知らせることができます。

コンポーネント提案プロセスとメタプロセスは、時々発生する重複を回避するのに役立ちました。

継続的な統合と継続的な展開の重要性（CI / CD）

あるチームがコンポーネントの作業をしている間に、別のチームのアプリケーションに損害を与える可能性があるという重大な問題に直面しました。 プロジェクト内の特定のバージョンでコンポーネントをブロックしなかった場合、コンポーネントが別のコマンドで変更されたため、CI / CDがテストの失敗を報告する場合があります。 これらは非常に不快な状況であり、多くのチームが特定のバージョンのコンポーネントをブロックすることになり、コンポーネントの新しいパッチを受け入れることさえできません。

まさにこの瞬間に、CI / CDはその栄光のすべてに現れます。 コンポーネントが更新されると、自動化はコンポーネントの同じメジャーバージョンを使用するアプリケーションでテストを実行する必要があります。 アプリケーションが特定のバージョンのコンポーネントをブロックした場合でも、テストが実行されます。 CI / CDシステムは、テストが成功した場合、ロックされたバージョンの新しいバージョンへのアップグレードを要求するプル要求を作成します。 テストが失敗した場合、チームは通知を受け取り、後で共同で問題を解決します。

内部ソースの哲学

再利用の基本的な要因は、 以前の記事でLaurent Desegurが説明したオープンソース/内部ソースの哲学に対する理解です。 WalmartLabsは、Hapi、 OneOps 、Electrodeなどのプロジェクトから明らかなように、オープンソースを積極的に使用および開発してきました。 社外ではそれほど目立ちませんが、実際にはオープンソースのクローズド実装である内部ソースモデルに非常にコミットしています。 内部ソースアプローチでは、チームや開発者はコンポーネントを「所有」しません。すべてのコンポーネントは組織全体に共通です。 これにより、潜在的なエラーが減り、開発者は既存のコンポーネントの改善に集中できます。

このポリシーにより、再利用の可能性が大幅に拡大しました。 さらに重要なことは、それが開発者に共同哲学へのコミットメントを知らせることです。 また、開発者は、コードの複雑なエラーをキャッチするのに時間を費やす代わりに、最も必要な場所で時間と知識を使用することができ、会社に本当の利点をもたらします。

結論

再利用は単なる技術的な解決策ではなく、組織のコミットメントを必要とし、長期的な結果をもたらす哲学的なアプローチでもあります。 WalmartLabsでは、それがもたらすメリットを目の当たりにしました。現在、SamsClub.comをElectrodeプラットフォームに移行し、開発者はSam's Clubの設定で何百ものWalmart.comコンポーネントを再利用しています。

再利用のストーリーを教えてください-どのような問題に遭遇しましたか？ それらをどのように解決しましたか？ 今後何を改善したいですか？

記事の元のテキスト