行ったこと#

一年と言っても、実際には一年以上が経過しましたが、それはあまり重要ではありません。主に、どのようなことを行ったかを見ていきましょう。

1. リリースフローの改善#

会社に入社した当初、白領貸しのフロントエンドはRiotフレームワークをベースに開発されたシステムでした。言語レベルでは、ES6とLessを使用して開発されており、本番環境へのリリースには、ビルド、バンドル、コンパイルのプロセスが必要で、直接本番サーバーにデプロイすることはできませんでした。

そのため、プロジェクトの開発フローは、機能開発、コードコミット、ローカルでのバンドル、バンドルされたコードとソースコードを一緒にテストに提出し、その後、コードをmasterにマージし、再度ローカルでバンドルしてから本番環境にリリースするというものでした。

このフローは非常に非合理的でした。なぜなら、ソースコードとコンパイル・バンドルされたコードを一緒に管理すること自体が不合理だからです。頻繁に、誰かがテストのためにバンドルすると、私がコードをプッシュした際に大量のコンフリクトが発生するという事態が起こりました。そこで、このフローをどのように改善すべきか考えました。

改善案1#

NetEase社内にはomadシステム（自動デプロイプラットフォーム）がありました。このプラットフォームを活用して何かできないかと考えました。入社したばかりで、このデプロイプラットフォームにあまり詳しくなかったため、このプラットフォームに最も多く触れているテスト担当の同僚に尋ねました。テスト担当の同僚は、omadが外部インターフェースを一切提供していないため、私が考えていることは実現できないだろうと教えてくれました。

こうなると困りました。本番環境でのバンドルリリースができないとなると、バンドルプロセスは必然的にローカルで行うしかありません。そこで、今となっては非常に愚かに思える解決策を考案しました。それは、ソースコードとバンドルされたコードをそれぞれ2つのリポジトリで管理するというものでした。

したがって、リリースが必要な場合は、まずソースコードリポジトリでバンドルとコンパイルを行い、その結果を、リリースするコードを管理するリポジトリにコピーする必要がありました。

概念図：

明らかに、この方法は一時的な解決策に過ぎず、1つのコードを管理するために2つのリポジトリが必要でした。コードをコミットするたびに、追加で run build コマンドを実行する必要がありました。

改善案2：#

上記の解決策があまりにも愚かだったため、改善案2が生まれました。これは現在も私たちが使用している解決策です。それは、直接オンラインでバンドルするというものです。詳細は以下の通りです。

ローカルでのコード開発 → コミット → リモートへのプッシュ → omadデプロイ → omad専用のバンドルマシンがスクリプトを実行してバンドル・コンパイル操作を実行 → バンドル・コンパイル後の結果をターゲットマシンにコピー。

概念図：

実際、最初の改善でこのようにすべきでした。しかし、当初は社内デプロイプラットフォームのomadに詳しくなかったため、omadがターゲットマシンにデプロイする前にスクリプトを実行できることを知りませんでした。そのため、最初の非常に愚かな解決策が生まれてしまいました。

現在のこの解決策はかなり洗練されています。私たちはソースコードにのみ集中すればよく、リリース時にはomadがビルドとバンドルデプロイの作業を行います。非常に快適で、この解決策は現在までずっと使用されています。

2. 洗練された開発環境の構築#

既存の白領貸し開発環境は、Expressとwebpackを組み合わせて構築されていましたが、機能は比較的簡素で、開発とバンドルの2つのコマンドしかサポートしていませんでした。さらに、バンドルの設定ファイルは完全にマルチページプロジェクト向けのものでした。

その後、来銭システムを開発する際、私は既存の基盤の上に、より洗練された開発環境を再構築しました。開発、連携デバッグ、テスト、バンドルからリリースまで、必要な機能はすべて揃っています。図を一枚掲載します。詳細はこちらをご覧ください。

3. モバイル向けコンポーネント ne-rc の開発を主導し推進#

来銭を再開発する際、Reactの基本コンポーネント一式を蓄積しましたが、ビジネスとの結合度が高めでした。今後、他のプロジェクトも行う可能性があることを考慮し、パートナーと相談して、基本コンポーネントをビジネスから切り離し、サードパーティのコンポーネントライブラリとしてプロジェクトに組み込むことにしました。

こうして、ne-rc が誕生しました。私たちのモバイル向けコンポーネントライブラリです。まだバージョン1.0のリリースに向けて努力を続けていますが、すでに3つの社内プロジェクトに成功裏に導入されています。

効果は顕著で、重複開発コストを大幅に削減しました。同時に、将来のメンテナンスコストも削減しました。このことから、安定して発展するチームには、やはり独自の社内コンポーネントライブラリが必要であると言えます。

4. チーム業務の改善#

既存のビジネスラインのフロントエンド担当者が私の入社後まもなく退職したため、フロントエンド技術部は私を一時的にリーダーに任命しました。私は自身の経験不足を深く認識していましたが、同時にこれが成長の機会であることも知っていました。ここで、私を信頼してくれた上司に深く感謝します。

そのため、私は非常に努力し、ビジネスラインチームのメンバーと、チームの技術力とビジネスサポート能力をどのように向上させるかについて多くの議論を重ね、最終的に以下のことを行いました。

• 開発フレームワークの最適化
• レガシープロジェクトの改修
• プロジェクトの標準化
• 技術計画

開発フレームワークの最適化#

最終的な成果は、前述の通り、完全な開発環境を構築したことです。そして、継続的に最適化を行いました。当初、白領貸しプロジェクトの開発では、リビルドに毎回30秒、本番環境へのバンドルリリースに4〜5分かかっていましたが、その後、去花プロジェクトではリビルドが600ms、バンドルがわずか1分に短縮されました。この間には、webpackに対する最適化と、プロジェクトの公開・提供方法の変更の両方が含まれています。

これらの最適化の過程で、多くの経験を積むことができました。

レガシープロジェクトの改修#

いくつかのレガシープロジェクトがあり、全体的にはメンテナンス状態でしたが、時折、多くの運用上の要件がありました。しかし、既存の開発方法とリリース方法はどちらも比較的煩雑でした。私たちは、大規模なリファクタリングを必要としない範囲で、段階的なアップグレードを行いました。主にビルドとリリースに関してです。 既存のwebpack設定ファイルの記述方法を書き換え、ローカルでのバンドルリリースからオンラインでのバンドルリリースにアップグレードしました。これにより、これらのプロジェクトのメンテナンスコストが軽減されました。

プロジェクトの標準化#

ビジネスラインのメンバーが増えるにつれて、協力が必要な状況では、標準化は不可欠です。私たちは、プロジェクトドキュメント、コードスタイルチェック、Gitブランチ管理、コードレビューなど、あらゆる側面から、完璧でありながら可能な限り煩雑でない標準を策定しました。

技術計画#

私たちのチームのプロジェクトはほとんどがReactを使用しているため、Reactエコシステムの技術動向を継続的に注視する必要があります。しかし同時に、Node.jsやAngularなどの他の技術やソリューションにも注目しています。フロントエンド技術部からはVueももっと見るように言われました。しかし、今のところVueは見ていません（笑）。おそらく興味が湧かないのでしょう。

5. ビジネスサポート#

私たちのフロントエンド技術部は機能部門に属していますが、ビジネスサポートは依然として私たちの仕事の最も主要な構成要素です。結局のところ、会社は利益を上げる必要がありますから。いくつかの小規模なプロジェクトやバックエンドプロジェクトを除いて、私は主に以下のプロジェクトの保守と開発に参加しました。

a. 白領貸しプロジェクトの保守 b. 来銭プロジェクトの開発とリリース c. 去花プロジェクトの開発とリリース

去花はまもなくリリースされます。私たちはすでに内部テストを開始しています。これは分割払いを提供するプロジェクトで、現在、Kaolaにのみ接続されていますが、まもなく外部にも公開されます。間もなく、皆さんはKaolaで買い物をする際に分割払いの支払いオプションを利用できるようになります。

プロジェクトがリリースされるのを見ると、やはり嬉しいものです 😄。

まとめ#

時間は本当にあっという間に過ぎました。NetEaseに入社してもう一年以上になります。

この期間で、私は大きく成長しました。仕事のスキル、コミュニケーションスキル、そしてワークフローや規範のいずれにおいても、多くのことを学ぶことができました。

多くの優秀な同僚と出会うこともできました。これらの優秀な同僚と一緒に仕事ができることは、とても嬉しいことです。もしかしたら、今後ずっとNetEaseにいるわけではないかもしれませんが、NetEaseでのこの経験は非常に価値のあるものです。