Habr フロントエンド開発者ログ: リファクタリングとリフレクション

私は常に、Habr が内部からどのように構造化されているのか、ワークフローがどのように構造化されているのか、コミュニケーションがどのように構造化されているのか、どのような標準が使用されているのか、そしてここで一般的にコードがどのように記述されているのかに興味を持っています。 幸いなことに、私は最近ハブラチームの一員になったので、このような機会を得ることができました。 モバイル バージョンの小さなリファクタリングの例を使用して、「ここでフロントで働くのはどのような感じか」という質問に答えてみます。 プログラム内: Node、Vue、Vuex、SSR と Habr での個人的な経験についてのメモからのソース。

開発チームについてまず知っておくべきことは、開発チームの人数が少ないということです。 十分ではありません - これらはフロントXNUMX人、バックXNUMX人、そしてハブル全体の技術的リーダーであるバクスリーです。 もちろん、テスター、デザイナー、XNUMX 人のヴァディム、奇跡のほうき、マーケティング スペシャリスト、その他のバンブルムもいます。 しかし、ハブル氏の情報源に直接貢献したのはわずか XNUMX 人だけです。 これは非常にまれなことです。数百万ドルの聴衆を抱えるプロジェクトは、外から見ると巨大企業のように見えますが、実際には可能な限りフラットな組織構造を備えた居心地の良いスタートアップのように見えます。

他の多くの IT 企業と同様に、Habr はアジャイルのアイデア、CI の実践、そしてそれだけを公言しています。 しかし、私の感覚によれば、Habr という製品は継続的に開発されているというよりは、波状に開発されているようです。 そのため、連続したいくつかのスプリントで、私たちは熱心に何かをコード化し、設計と再設計を行い、何かを壊しては修正し、チケットを解決して新しいチケットを作成し、熊手を踏んで足を撃って、最終的に機能をリリースします。生産。 そして、一定の落ち着き、再開発の時期が到来し、「重要ではあるが緊急ではない」象限にあることを行う時期が来ます。

以下で説明するのは、まさにこの「オフシーズン」のスプリントについてです。 今回は、Habr のモバイル版のリファクタリングが含まれていました。 一般に、同社はこれに大きな期待を寄せており、将来的にはハブルの化身である動物園全体を置き換え、ユニバーサルなクロスプラットフォームソリューションになるはずです。 いつか、アダプティブ レイアウト、PWA、オフライン モード、ユーザー カスタマイズ、その他多くの興味深い機能が登場するでしょう。

タスクを設定しましょう

かつて、通常のスタンドアップで、フロントの 20 人がモバイル版のコメント コンポーネントのアーキテクチャの問題について話しました。 これを念頭に置いて、私たちはグループ心理療法の形式でマイクロミーティングを開催しました。 全員が順番にどこが痛かったかを言い、すべてを紙に記録し、共感し、理解しましたが、誰も拍手しませんでした。 その結果、XNUMX の問題のリストが作成され、モバイル Habr が成功までにまだ長く険しい道を残していることが明らかになりました。

私が主に懸念していたのは、リソースの使用効率と、いわゆるスムーズなインターフェイスです。 毎日、在宅、仕事、帰宅のルートで、古い携帯電話がフィードに 20 件の見出しを必死に表示しようとしているのを見ました。 次のような感じでした。

リファクタリング前のモバイル Habr インターフェイス

何が起きてる？ つまり、サーバーは、ユーザーがログインしているかどうかに関係なく、すべてのユーザーに同じ方法で HTML ページを提供しました。 次に、クライアント JS がロードされ、必要なデータが再度要求されますが、承認のために調整されます。 つまり、実際には同じ作業を XNUMX 回行ったということです。 インターフェイスがちらつき、ユーザーはさらに XNUMX キロバイトをダウンロードしました。 詳細に見ると、すべてがさらに不気味に見えました。

古い SSR-CSR スキーム。 認可は、Node JS が HTML の生成で忙しくなく、API へのリクエストをプロキシできるステージ C3 と C4 でのみ可能です。

当時の私たちのアーキテクチャは、Habr ユーザーの XNUMX 人によって非常に正確に説明されていました。

モバイル版はクソだよ。 ありのままに言ってますよ。 SSRとCSRの恐ろしい組み合わせ。

どんなに悲しくても、私たちはそれを認めなければなりませんでした。

私はオプションを評価し、「もうダメだ、正しくやれ」というレベルの説明を含むチケットを Jira で作成し、タスクを大まかに分解しました。

• データを再利用し、
• 再描画の回数を最小限に抑え、
• 重複したリクエストを排除し、
• ロードプロセスをより明確にします。

データを再利用しましょう

理論的には、サーバー側レンダリングは XNUMX つの問題を解決するように設計されています。XNUMX つは検索エンジンの制限に悩まされないことです。 SPAインデックス作成 そして指標を改善する FMP (悪化は避けられない TTI）。 典型的なシナリオでは、最終的には 2013年にAirbnbで策定 年 (まだ Backbone.js 上にあります)、SSR は Node 環境で実行される同じ同型 JS アプリケーションです。 サーバーは、生成されたレイアウトをリクエストへの応答として送信するだけです。 その後、クライアント側でリハイドレーションが行われ、ページをリロードしなくてもすべてが機能します。 Habr にとって、テキスト コンテンツを含む他の多くのリソースと同様に、サーバー レンダリングは検索エンジンと友好的な関係を構築する上で重要な要素です。

このテクノロジーの出現から XNUMX 年以上が経過し、この間、フロントエンドの世界では実際に多くの水が流れ込んできたという事実にもかかわらず、多くの開発者にとって、このアイデアは依然として秘密に包まれています。 私たちは傍観せずに、SSR サポートを備えた Vue アプリケーションを実稼働環境にロールアウトしました。その際、小さな詳細が XNUMX つ欠けていました。それは、初期状態をクライアントに送信しなかったことです。

なぜ？ この質問に対する正確な答えはありません。 サーバーからの応答のサイズを大きくしたくなかったか、その他のアーキテクチャ上の問題が原因だったか、単に普及しなかったかのいずれかです。 いずれにせよ、状態を破棄し、サーバーが行ったことすべてを再利用することは、非常に適切で便利であるように思えます。 このタスクは実際には簡単です - 状態は単に注入されるだけです 実行コンテキストに追加すると、Vue はそれをグローバル変数として生成されたレイアウトに自動的に追加します。 window.__INITIAL_STATE__.

発生している問題の XNUMX つは、循環構造を JSON に変換できないことです (循環参照); この問題は、そのような構造を平らな構造に置き換えるだけで解決されました。

さらに、UGC コンテンツを扱うときは、HTML を壊さないようにデータを HTML エンティティに変換する必要があることに注意してください。 これらの目的のために私たちは使用します he.

再描画の最小化

上の図からわかるように、この例では、XNUMX つの Node JS インスタンスが SSR と API の「プロキシ」という XNUMX つの機能を実行し、ユーザーの承認が行われます。 この状況により、ノードはシングルスレッドであり、SSR 機能は同期であるため、JS コードがサーバー上で実行されている間は認証が不可能になります。 つまり、コールスタックが何らかの処理でビジー状態の間、サーバーはそれ自体にリクエストを送信できません。 状態を更新しましたが、ユーザー セッションを考慮してクライアント上のデータを更新する必要があったため、インターフェイスのけいれんが止まらなかったことがわかりました。 ユーザーのログインを考慮して、正しいデータを初期状態に置くようにアプリケーションに教える必要がありました。

この問題に対する解決策は XNUMX つだけでした。

• クロスサーバーリクエストに認可データを添付します。
• Node JS レイヤーを XNUMX つの別々のインスタンスに分割します。

XNUMX つ目の解決策ではサーバー上でグローバル変数を使用する必要があり、XNUMX つ目の解決策ではタスクを完了する期限が少なくとも XNUMX か月延長されました。

どのように選択すればよいでしょうか? ハブルは最も抵抗の少ない道に沿って移動することが多い。 非公式には、アイデアからプロトタイプまでのサイクルを最小限に抑えたいという一般的な要望があります。 製品に対する態度のモデルは、booking.com の公準をいくらか思い出させますが、唯一の違いは、Habr がユーザーのフィードバックをより真剣に受け止め、そのような決定を下すのは開発者であるあなたを信頼していることです。

このロジックと、問題をすぐに解決したいという私自身の願望に従い、グローバル変数を選択しました。 そして、よくあることですが、遅かれ早かれその代金を支払わなければなりません。 私たちはほぼすぐに支払いをしました。週末に働き、その影響を片づけて、手紙を書きました。 死後の そしてサーバーを XNUMX つの部分に分割し始めました。 このエラーは非常に愚かで、それに関連するバグを再現するのは簡単ではありませんでした。 そして、はい、これは残念なことですが、何らかの形でつまずき、うめき声​​を上げながらも、グローバル変数を使用した私の PoC は実稼働環境に入り、新しい「XNUMX ノード」アーキテクチャへの移行を待っている間、非常に正常に動作しています。 これは重要なステップでした。正式に目標が達成されたためです。SSR は、完全にすぐに使用できるページを提供することを学習し、UI がより穏やかになりました。

リファクタリングの第 XNUMX 段階後のモバイル Habr インターフェイス

最終的に、モバイル バージョンの SSR-CSR アーキテクチャは次の図につながります。

「3 ノード」SSR-CSR 回路。 Node JS API は常に非同期 I/O に対応しており、SSR 関数は別のインスタンスに配置されているため、SSR 関数によってブロックされません。 クエリチェーン #XNUMX は必要ありません。

重複したリクエストの排除

操作が実行された後、ページの最初のレンダリングはてんかんを引き起こさなくなりました。 しかし、SPA モードで Habr をさらに使用すると、依然として混乱が生じました。

ユーザーフローの基本はフォームの遷移であるため、 記事一覧→記事→コメント 逆も同様で、そもそもこのチェーンのリソース消費を最適化することが重要でした。

投稿フィードに戻ると、新しいデータリクエストが発生します

深く掘り下げる必要はありませんでした。 上のスクリーンキャストでは、アプリケーションがスワイプして戻るときに記事のリストを再リクエストしていることがわかりますが、リクエスト中は記事が表示されません。これは、以前のデータがどこかに消えていることを意味します。 記事リスト コンポーネントがローカル状態を使用しており、破棄するとローカル状態が失われるようです。 実際、アプリケーションはグローバル状態を使用していましたが、Vuex アーキテクチャは正面から構築されました。モジュールはページに関連付けられ、ページはルートに関連付けられます。 さらに、すべてのモジュールは「使い捨て」です。その後ページにアクセスするたびに、モジュール全体が書き換えられます。

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

合計すると、モジュールができました 記事一覧、タイプのオブジェクトが含まれます 記事 とモジュール ページ記事、オブジェクトの拡張バージョンでした 記事、 種の 記事全文。 概して、この実装自体にはひどいことは何もありません。非常に単純で、素朴とも言えるかもしれませんが、非常に理解できます。 ルートを変更するたびにモジュールをリセットすれば、そのまま使用することもできます。 ただし、記事フィード間を移動すると、たとえば /フィード → /すべて、個人フィードに関連するものはすべて破棄されることが保証されています。なぜなら、私たちは XNUMX つしか持っていないからです。 記事一覧, そこに新しいデータを入れる必要があります。 これにより、再びリクエストの重複が発生します。

このテーマに関して掘り出すことができたすべてを収集した後、私は新しい国家構造を策定し、同僚に提示しました。 議論は長く続きましたが、最終的には賛成意見が疑問を上回り、実行に移しました。

ソリューションのロジックは XNUMX つのステップで最もよくわかります。 まず、Vuex モジュールをページから切り離し、ルートに直接バインドしようとします。 はい、ストア内のデータはもう少し多くなり、ゲッターは少し複雑になりますが、記事を XNUMX 回ロードすることはありません。 モバイル版に関しては、これがおそらく最も有力な議論です。 次のようになります。

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

しかし、記事リストが複数のルート間で重複する可能性がある場合や、オブジェクト データを再利用したい場合はどうなるでしょうか。 記事 投稿ページをレンダリングして、 記事全文? この場合、次のような構造を使用する方が論理的です。

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

記事一覧 ここでは、それは単なる記事のリポジトリのようなものです。 ユーザーセッション中にダウンロードされたすべての記事。 これは、地下鉄の駅間のどこかで苦労してダウンロードされた可能性のあるトラフィックであるため、当社ではこれらのトラフィックを細心の注意を払って扱います。また、ユーザーにすでに持っているデータのロードを強制することで、このような苦痛を再びユーザーに与えることは絶対に望んでいません。ダウンロードされました。 オブジェクト 記事ID オブジェクトへの単なる ID の配列 (「リンク」のようなもの) 記事。 この構造により、ルートに共通するデータの重複やオブジェクトの再利用を回避できます。 記事 拡張データをマージして投稿ページをレンダリングするとき。

記事リストの出力もより透明になりました。イテレータ コンポーネントは記事 ID を含む配列を反復処理し、ID をプロップとして渡して記事ティザー コンポーネントを描画し、子コンポーネントは次に必要なデータを取得します。 記事一覧。 出版物ページに移動すると、既存の日付が次の情報から取得されます。 記事一覧、不足しているデータを取得するリクエストを作成し、それを既存のオブジェクトに追加するだけです。

なぜこのアプローチが優れているのでしょうか? 上で書いたように、このアプローチはダウンロードされたデータに関してより穏やかであり、再利用することができます。 しかし、これに加えて、このようなアーキテクチャに完全に適合するいくつかの新しい可能性への道が開かれます。 たとえば、記事が表示されるたびにポーリングしてフィードに記事を読み込みます。 最新の投稿を「ストレージ」に置くだけで済みます 記事一覧、新しい ID の別のリストを次の場所に保存します。 記事ID そしてそれをユーザーに通知します。 「新しい出版物を表示」ボタンをクリックすると、現在の記事リストの配列の先頭に新しい ID が挿入されるだけで、すべてがほぼ魔法のように機能します。

ダウンロードをもっと楽しく

リファクタリングのおまけはスケルトンの概念です。これにより、遅いインターネット上でコンテンツをダウンロードするプロセスの嫌悪感が少し軽減されます。 この問題については何の議論も行われず、アイデアからプロトタイプまでの道のりには文字通り XNUMX 時間かかりました。 デザインは実際に自動的に描画され、データを待機している間、シンプルでほとんどちらつきのない div ブロックをレンダリングするようにコンポーネントに教えました。 主観的には、この負荷へのアプローチにより、ユーザーの体内のストレスホルモンの量が実際に減少します。 スケルトンは次のようになります。

ハブラローディング

反射する

私はハブレで半年働いていますが、友達は今でも「あそこはどうですか？」と尋ねます。 はい、快適です - はい。 しかし、この作品が他の作品とは異なる点があります。 私が働いていたチームは、自社の製品にまったく無関心で、ユーザーが誰であるかを知りも理解もしていませんでした。 しかし、ここではすべてが異なります。 ここでは、自分の行動に責任を感じます。 機能を開発するプロセスでは、あなたは部分的にその所有者となり、機能に関連するすべての製品会議に参加し、提案を行い、自分で決定を下します。 毎日使う製品を自分で作るのはとても素晴らしいことですが、おそらく自分よりもその製品を得意とする人のためにコードを書くのは、ただただ信じられないほどの気分です (皮肉ではありません)。

これらすべての変更をリリースした後、肯定的なフィードバックを受け取りました。それは非常に素晴らしいものでした。 感動的ですね。 ありがとう！ もっと書いてください。

グローバル変数の後にアーキテクチャを変更し、プロキシ層を別のインスタンスに割り当てることにしたことを思い出してください。 「XNUMX ノード」アーキテクチャは、パブリック ベータ テストの形ですでにリリースされています。 今では誰でもそれに切り替えることができ、モバイル Habr の改善に協力していただけます。 それが今日のすべてです。 コメントにあるすべての質問に喜んでお答えします。

出所： habr.com