テストコードを本番環境に持ち込まないようにする TL;DR:  や同様のフラグを追加しないでください。 isTesting 問題😔 漏れやすい抽象化 非ビジネスコード汚染 脆弱なコード 一貫性のない行動 隠れた依存関係 デバッグが難しい ブールフラグ 信頼できないテスト 生産依存コード 解決策 😃 を削除する 動作のIf 依存性注入を使用する 外部サービスをモデル化する（ しない） モック化 個別の構成 テストロジックを分離する 明確な行動境界を維持する リファクタリング⚙️   https://hackernoon.com/refactoring-014-how-to-remove-if?embedable=true コンテキスト 💬   のようなフラグを追加すると、テストコードと本番コードが混在することになります。 isTesting これにより、テストでのみアクティブな隠しパスが作成されます。 また、実際の製品コードはカバーされません。 テスト動作を本番環境に配布すると、バグや予期しない動作が発生するリスクがあります。 サンプルコード 📖 間違いです❌   struct PaymentService { is_testing: bool, } impl PaymentService { fn process_payment(&self, amount: f64) { if self.is_testing { println!("Testing mode: Skipping real payment"); return; } println!("Processing payment of ${}", amount); } } そうだね👉   trait PaymentProcessor { fn process(&self, amount: f64); } struct RealPaymentProcessor; impl PaymentProcessor for RealPaymentProcessor { fn process(&self, amount: f64) { println!("Processing payment of ${}", amount); } } struct TestingPaymentProcessor; impl PaymentProcessor for TestingPaymentProcessor { // Notice this is not a mock fn process(&self, _: f64) { println!("No payment: Skipping real transaction"); } } struct PaymentService<T: PaymentProcessor> { processor: T, } impl<T: PaymentProcessor> PaymentService<T> { fn process_payment(&self, amount: f64) { self.processor.process(amount); } } 検出 🔍   セミオートマチック [x] この臭いは、   、   、  などの条件フラグや、次のような慣用句を探すことで検出できます。 isTesting environment == 'test' DEBUG_MODE これらは、テストの動作が本番環境のコードに漏れていることを示しています。 タグ 🏷️ テスト レベル 🔋   中級 [x] なぜ全単射が重要なのか 🗺️ テストコードと本番コードを明確に分離する必要があります。 これらを混在させると、現実世界の動作とプログラム間の一対一の が崩れてしまいます。 全単射 環境は現実世界のエンティティであるため、  で明示的にモデル化する必要があります。 MAPPER  AI世代🤖  AI によって生成されたコードでは、テストのために簡単なハックを使用すると、この臭いがすることがよくあります。 一部のツールでは、適切な設計よりも使いやすさを優先するため、  などのフラグを提案します。 isTesting  AI検出 🥃  AI ツールは、テスト状態に基づいて条件付きロジックにフラグを立てるように構成すると、この臭いを検出できます。 ぜひお試しください！🛠 覚えておいてください：AIアシスタントは多くの間違いを犯します 提案されたプロンプト: IsTestingメソッドを削除し、環境をモデル化して置き換えます 適切な指示がなければ 具体的な指示 チャットGPT   チャットGPT   クロード クロード 困惑 困惑 副操縦士 副操縦士 ジェミニ ジェミニ ディープシーク ディープシーク メタAI メタAI クウェン クウェン 結論 🏁   フラグの使用は避けてください。 isTesting 依存性注入を使用して環境をモデル化し、テスト ロジックと本番ロジックを分離します。 関係👩‍❤️‍💋‍👨   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om   https://hackernoon.com/code-smell-242-zombie-feature-flags?embedable=true 免責事項 📘 コードスメルは私の です。 意見 クレジット🙏 写真は による より Christian Gertenbach Unsplash テストフラグを追加すると、本番環境での信頼性が損なわれます。 ウォード・カニンガム https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true この記事は CodeSmell シリーズの一部です。   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

コードの臭い 293 - isTesting や類似のフラグの追加は避けるべき

コードの臭い 293 - isTesting や類似のフラグの追加は避けるべき

About Author

コメント

ラベル

この記事は

Related Stories

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Telegram: クリプト島と本土を結ぶ橋

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Telegram: クリプト島と本土を結ぶ橋

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps