条件付き連鎖の防止/リファクタリング

JavaScript アプリケーションを開発するときに最も一般的なコード臭の 1 つは、過剰な条件連鎖です。この記事では、アーキテクチャとコードを通じてこれらのケースを防ぐ方法について議論したいと思います。

目次

1. はじめに
2. 条件付きチェーンを理解する
3. 条件付きチェーンの問題
4. 条件付きチェーンのリファクタリング
5. アーキテクチャによる条件付きチェーンの防止
6. フロントエンド開発のベストプラクティス
7. 結論

条件付きチェーンとは何ですか?

過剰な条件付き連鎖は、JavaScript アプリケーションでよく見られるコード臭です。この記事では、アーキテクチャとコーディングの実践を改善することで、これらのケースを防止し、リファクタリングする方法について説明します。

条件チェーンは、関数またはメソッドで条件を表現するために使用される過剰な論理演算子です。 React アプリケーションを使用した例を見てみましょう:

上の例でわかるように、このコードのレンダリング方法を決定するためだけに 3 つの条件の連鎖があります。
条件は次のとおりです:

1. スポーツのリストに要素がある場合、デフォルトの要素がレンダリングされる必要があります。
2. コンポーネントの読み込み状態が true の場合、読み込み中のスケルトンがレンダリングされる必要があります。
3. スポーツ リストに要素がない場合は、空の状態が表示されます。

このコードには 2 つの主な問題があります:

1. 配列の長さをチェックし、「&&」演算子を使用するとき、配列の長さに関連する値がある場合にコンポーネントをレンダリングするように JavaScript に指示します。配列がない場合、この値は null または未定義である必要がありますが、配列が存在し、その長さが 0 の場合は、要素の代わりに数値 0 が表示されます。これは、JavaScript に、配列の長さ。
2. これら 2 つの要素のレンダリングを制御するためにチェーンを使用する必要はありません。コンポーネントの「デフォルト」状態をレンダリングする前に条件を追加すると、この状況に対処するより洗練された方法になります。

リファクタリング

そうは言っても、上記のコードのリファクタリングされたバージョンは次のとおりです。

これは、JavaScript の論理演算子を使用して条件連鎖を処理する多くの方法の 1 つです。上記のコードからわかるように、コードの過剰な条件を解決するために一般的ではないアプローチを使用しました。

ザ!! JavaScript の演算子は、値をブール値に強制するために使用されます。これは、JavaScript には真の値と偽の値があるという事実を利用します。最初 ！演算子は値を否定し、真の値を false に、偽の値を true に変換します。 2番目！これを再度否定すると、元の値のブール表現が得られます。これは、真偽に基づいて、文字列、数値、オブジェクトなどの値をブール値 (true または false) に変換するためによく使用されます。

例:

!!空でない文字列は真実であるため、「Hello」は true と評価されます。
!!0 は false であるため、false と評価されます。

アーキテクチャ上の決定を通じてその発生を防止する

これを原則として受け入れてはなりませんが、条件付きチェーンが作成されるほとんどの場合、過剰な条件が動的値を解析して処理しようとします。静的な値を扱う場合、実装では問題が発生する傾向があるためです。よりシンプルかつ簡単になります。

データベースをモデル化するときは、ソフトウェアの依存関係についていくつかの懸念を抱く必要があります。

人々は通常、IT 大学の勉強を通じてこの種の依存関係の研究を学びますが、私はそれを説明します。

ソフトウェアには 2 種類の依存関係があります:

1. 機能の依存関係 - これらの依存関係は、ボタン、画面、入力、フォームなど、ユーザーが操作する機能であるため、ユーザーに直接影響します。
2. 非機能的な依存関係 - これらの依存関係は、主にエラー処理、条件、ビジネス ルール、検証などのバックエンドの依存関係であるため、通常のユーザーには気付かれません。

フロントエンドの過剰な制御の防止

バックエンドは、システムのすべてのロジック部分を担当する必要があるため、機能の依存関係の大部分は、フロントエンド画面やユーザー操作ではなく、バックエンド関数によって処理される必要があります。

新しい機能の開発を開始し、その機能が動作するために必要なもの (プロパティ、インターフェイス、パラメーターなど) を理解するには、何が必要で、何がオプションで、何があってはならないのかを念頭に置いておく必要があります。使用されています。

上記の例は、開発セッション中にしてはいけないことの例として使用する必要があります。ご覧のとおり、このインターフェイスにはオプションのパラメータしかありませんが、このコンポーネントには「おそらく」変数しか付加されていないのではないかと思います。

コンポーネントを開発してフロントエンド アプリケーションに多くのわかりにくいコードをプッシュする前に、コンポーネントがどのように動作するかを理解する必要があります。多くの条件を処理する代わりに、コンポーネントで何が使用され、何が使用されないかだけを決定する方が簡単です。

さらによく考えてみると、次のようなことが考えられます。

現在、インターフェイスには、アプリ内でコンポーネントの有効期間を通じて確実に使用される必須パラメーターのみが含まれており、以前のコンポーネントのように定義または使用できない多くのオプション パラメーターはありません。

結論

条件チェーンの防止とリファクタリングにより、コードがよりクリーンで保守しやすくなります。コンポーネントの要件を理解し、必要に応じてロジックをバックエンドに移し、明確なインターフェイスを設計することで、フロントエンド コードでの複雑な条件チェーンの必要性を大幅に減らすことができます。

---

Unsplash の Samsung Memory による写真

以上が条件付き連鎖の防止/リファクタリングの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。