これらのポイントはすべて、モバイル開発、Web フロントエンド、およびバックエンドに適用できます。私は過去 6 年間に直面した問題を通じて、さまざまなチームからこれらのプラクティスを収集しました。これらのプラクティスは、プロジェクトをゼロから構築する場合に特に役立ちます。それらのいくつかはあなたに完全に合うかもしれませんが、他の人はそうでないかもしれません.独自のアプローチやさまざまな経験があれば、ここで共有していただければ幸いです。ところで、あなたが昇進を望んでいるミドルまたはジュニアの開発者である場合、これらのプラクティスをチームに実装することは非常に役立ちます。さあ行こう！

1.準備が整うまでバックエンドの応答をモックする

標準的なソフトウェア開発プロセスでは、新しい機能の要求が企業から寄せられると、フロントエンド、バックエンド、およびモバイル アプリ開発などの複数のチームに分散されます。

その後、各チームは計画とタスクの分解を進めます。しかし、バックエンド チームがパーツの開発により多くの時間を必要とする場合はどうなるでしょうか?週に 1 回しかエンドポイントを配信できないとしたら?

バックエンドがボトルネックになります。

モバイル開発チームとフロントエンド開発チームは、最終的に次のような作業を行います。その後、休憩を取り、コンテキストを別の機能に切り替え、サイクルが続きます。これは、疲労、速度の低下、および品質の低下につながります。

解決策:バックエンド チームとの契約に同意し、すべてのリクエストをモックします。

1. エンドポイントとエンティティについてバックエンド チームと調整します。

2A。スタブ応答を使用してバックエンド API を実装します。 Faker ライブラリは、サンプル データの生成に役立ちます。

2B.または、フロントエンドにスタブを実装します。これは、コード内で直接データを持つオブジェクトにすることができます。たとえば、Node.js では、動的インポートを使用してこれを効率的に実装し、バンドル サイズの増加を回避できます。

 getUser() { return import('../../assets/mocks/users') .then(data => data.userById) .then(deserializeUser); };

これは、実際のリクエストを行う代わりにアセットから JSON ファイルを取得するモック HTTP サービスにもなります。

3. 機能フラグの後ろに機能を隠します。

   
   

4. バックエンドの準備ができたら、フロントエンド スタブ アプローチを使用した場合は実際の API に切り替え、すべてが期待どおりに機能することを確認します。そして、この機能をオンにします。

2.機能フラグ

お気づきかもしれませんが、前のセクションで機能フラグについて触れました。簡単に言えば、機能フラグとも呼ばれる機能トグルにより、開発者はライブ環境で機能をオンまたはオフにすることができます。また、新しい機能を段階的に展開する、A/B テストを実行する、ベータ機能を有効にする、修正プログラムを実装するなど、役立つ場合もいくつかあります。

機能フラグの保存には Gitlab を使用します。これは、バックエンド プロジェクトとフロントエンド プロジェクトの両方で使用される専用のリポジトリです。すばらしいニュースは、ユーザー フレンドリーな UI を備えているため、プロダクト マネージャーが自分で機能を管理できることです。以前は、プロジェクト リポジトリごとに個別に機能フラグを使用していました。ただし、このアプローチでは、製品全体の機能を一度に無効にする機能は提供されませんでした。そのため、すべてを単一のリポジトリに移動します。

コードでは、非常に単純に見えます。

1. プロジェクトでは、すべてのアクティブな機能フラグを取得します。内部的には、Gitlab はUnleash (機能トグル サービス) に基づいているため、公式クライアントを使用しています。
2. そして、非表示にする必要があるコードにif features.YOUR_FEATUREを入れるだけです。
3. 機能フラグにさまざまな値を追加することで、ユース ケースを拡張できます。たとえば、色の値または割引値を追加します。

3.本番環境での問題を追跡するためのエラーの監視

私たちの製品が MVP ステージから実稼働アプリケーションに移行したとき、再現できないエラーがユーザーに表示され、認識さえされない可能性があることを懸念していました。エラー追跡ツールを調査した結果、Sentry に落ち着きました。経験はポジティブでした。それでは、いくつかの重要なニュアンスについて見ていきましょう。

役に立たないエラー

内部では、キャッチされていない例外が追跡されます。アプリケーションとユーザー数が増えるにつれて、エラーの数が圧倒的に多くなり、本当に重要なことに気づくことがほぼ不可能になる可能性があります。不要なものを除外しないと、セントリーはゴミ箱に変わる可能性があります。たとえば、キャンセルされたリクエスト、接続エラー、接続されたスクリプトからのエラーなどのイベントはまったく役に立たず、仕事用のメールに通知をスパムするだけです。解決策として、構成にフィルターを追加できます。これを行うには、単純にbeforeSendコールバックを定義して、それをsentryPackage.initに入れます。このコールバックでは、キャッチされた各エラーを分析し、役に立たない場合は (null を返すことによって) 破棄できます。不要なエラーを除外するフィルターの例を次に示します。

 function beforeSend(event, hint) { const error = hint.originalException; const externalScripts = [ 'gtm.js', // Google Tag Manager 'watch.js', // X Analytics ].join('|'); const errorsToIgnore = [ AxiosError.ERR_NETWORK, AxiosError.ECONNABORTED, AxiosError.ETIMEDOUT ]; if (axios.isCancel(error) || errorsToIgnore.includes(error.code) || error.stack?.match(externalScripts)) { return null; } return event; }

デバッグを改善するためにより多くのデータを含める

デフォルトでは、Sentry は要求と応答の内容をエラー レポートに含めない場合があります。この情報がなければ、適切なデバッグは不可能です。幸いなことに、 beforeSendハンドラーにこの情報を含めることができます。

 function beforeSend(event, hint) { const error = hint.originalException; if (error.isAxiosError) { const url = error.request?.responseURL; const response = error.response?.data; const request = error.config?.data; event.extra = { ...(event.extra || {}), url, response, request }; } return event; }

機密情報のフィルタリング

パスワード、電子メール アドレス、キーなどのデータはエラー コンテンツに含めないでください。 Sentry には、この種の情報を非表示にするメカニズムが組み込まれています。セキュリティ設定で設定できます。さらに、 beforeSendのイベントオブジェクトで何かを削除することもできます

スタンドアロン ソリューション

ビジネスの性質上、この種のデータを別の場所のサーバーに保存することができない場合、Sentry はそれを独自のサーバーで使用する機能を提供します。

4.トレース

Sentry でエラーを正常にキャプチャしたものの、説明の情報が不十分である状況を想像してください。ログに目を向けますが、何千ものリクエストと毎秒さらに多くのログ行の中から特定のエラーを特定するにはどうすればよいでしょうか?特にビジネスに複数のチームがあり、他のサービスと統合している場合、正しいものをどのように区別し、リクエスト チェーンを構築し、正確なエラーを特定できるでしょうか?ここでトレースの出番です。

1. トレースは、呼び出しの完全な図を提供し、メッセージ ブローカーによって非同期通信が実行されている場合でも、失敗した正確なメソッドを識別します。
2. これにより、さまざまなチームと統合するときに、どちら側でエラーが発生したかを簡単に判断できます。
3. トレースは、パフォーマンスのデバッグにも役立ちます。たとえば、レンダリングに時間がかかるかどうか、またはマイクロサービスのメソッドが十分に最適化されていないかどうかを明確にするのに役立ちます。

特定の実装では、OpenTracing API に基づくJaegerを使用しました。

簡単に言えば、各リクエストとそのすべてのメソッド呼び出しは、一意のラベルでタグ付けされます。各ラベルには、その親といくつかのメタデータへの参照があります。この番号の構造は実装によって異なりますが、OpenTracing については、公式リポジトリ ページでその仕組みを読み、スパン、参照、子、親などの用語に慣れることができます。実生活では、幸運にもトレースが使用されることはめったにありません。ただし、これらのまれな事故では、時間を節約できます。

5.パフォーマンスの最適化

フィンテック アプリの MVP を実装したときは、非常に複雑なフォームがありました。当時、私はまだ若く、未熟でした。そして最終的に、私たちのプロジェクトがスローダウンしていることに気付きました。その理由を突き止めるために、さらに時間を費やす必要がありました。 React の props に関する基本的なルールを無視したため、不要な再レンダリングが多数発生しました。今後このような事態を避けるために、できる限りのことをしたいと思いました。

そのため、このようなリンターをプロジェクトに追加し、package.json に追加の開始構成を追加して、why-did-you-renderを実行しました。つまり、このプラグインは、何かが不必要に再レンダリングされた場合に警告を発し、それを回避する方法を提案します。また、ヘッドレス モードでの Lighthouseの実行も含めました。時期尚早の最適化は良くないと言う人もいますが、私にとってはそれが原則です。最初から正しく行うことです。

6.すべてのチーム プロジェクトのコード スタイルを定義

壊れた窓理論について聞いたことがあるでしょう。建物に 1 つの壊れた窓があり、それを交換する人がいない場合、最終的にその建物には無傷の窓が 1 つも残っていません。

プロジェクト内のルールとコントロールが少なければ少ないほど、低品質のコードを記述したり、まったく異なるスタイルで記述したりする誘惑が大きくなります。一貫性のないコードは理解するのに時間がかかりますが、明確で親しみやすい簡潔なコードはすばやく読むことができます。私たちのチームの 1 つで、コーディング スタイルを1 か所で説明しました。優れた出発点として、 PrettierまたはAirbnb コード スタイルを使用できます。

7.回帰テスト

さまざまな種類のテスト、アプローチ、およびそれらを適切に記述する方法について、すでにかなりの量の文献が書かれています。ここで言及する価値のある唯一のことは、本番アプリケーションは回帰テストなしでは存続できないということです。そのため、包括的なエンド ツー エンドのテスト フレームワークの作成に全力を注ぎ、それに基づいて、BDD シナリオとユーザー ストーリーにリンクするテストを作成しました。 Page Object パターンを使用してコードを整理し、Playwright フレームワークを使用してブラウザーとやり取りしました。 Safari を含むさまざまなブラウザーでテストするには、 Moonというソリューションを使用できます。サーバーの 1 つにデプロイできます。

結論

この記事を読んでいただきありがとうございます。結論として、この記事では、開発プロセスとコードの品質を向上させる主要なソフトウェア エンジニアリング プラクティスに焦点を当てています。バックエンド レスポンスのモック、機能フラグ、エラー モニタリング、パフォーマンスの最適化、コード スタイルの標準、回帰テスト、トレースなどの手法を採用することで、より効率的で信頼性の高いソフトウェアを作成できます。私たちのソフトウェアを改善し続け、連絡を取り合いましょう! :)