Huwag hayaang lumabas ang test code sa produksyon  TL;DR: Iwasang magdagdag   o mga katulad na flag. ng isTesting  Problema 😔  Leaky abstraction  Polusyon sa code na hindi pangnegosyo  Marupok na Code  Hindi pare-pareho ang pag-uugali  Mga nakatagong dependency  Mahirap na pag-debug   Mga flag ng Boolean  Mga hindi pinagkakatiwalaang pagsubok   Code na umaasa sa produksyon  Solusyon 😃  Alisin  ang gawi Ifs  Gumamit ng dependency injection  Magmodelo ng mga panlabas na serbisyo (Huwag   sila) kutyain  Paghiwalayin ang mga pagsasaayos  Ihiwalay ang lohika ng pagsubok  Panatilihin ang malinis na mga hangganan ng pag-uugali  Mga refactoring ⚙️   https://hackernoon.com/refactoring-014-how-to-remove-if?embedable=true  Konteksto 💬  Kapag nagdagdag ka ng mga flag tulad ng   , pinaghalo mo ang testing at production code. isTesting  Lumilikha ito ng mga nakatagong landas na aktibo lamang sa mga pagsubok.  Gayundin, hindi mo saklaw ang tunay na code ng produksyon.  Ipagsapalaran mo ang pagpapadala ng gawi sa pagsubok sa produksyon, na humahantong sa mga bug at hindi nahuhulaang gawi.  Halimbawang Code 📖  Mali ❌   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); } }  Tama 👉   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); } }  Pagtuklas 🔍    Semi-Awtomatiko [x]  Made-detect mo ang amoy na ito sa pamamagitan ng paghahanap ng mga conditional na flag tulad ng   ,   ,   , at mga idiom na tulad nito. isTesting environment == 'test' DEBUG_MODE  Ang mga ito ay nagpapahiwatig na ang pag-uugali ng pagsubok ay tumutulo sa code ng produksyon.  Mga tag 🏷️  Pagsubok  Antas 🔋    Intermediate [x]  Bakit Mahalaga ang Bijection 🗺️  Kailangan mo ng malinaw na paghihiwalay sa pagitan ng test at production code.  Kapag pinaghalo mo ang mga ito, masisira mo ang one-to-one   sa pagitan ng real-world na gawi at ng programa. Bijection  Dahil ang mga kapaligiran ay mga real-world na entity kailangan mong tahasang imodelo ang mga ito sa   . MAPPER  Pagbuo ng AI 🤖  Ang AI-generated code ay madalas na nagpapakilala ng amoy na ito kapag gumagamit ka ng mabilis na mga hack para sa pagsubok.  Ang ilang mga tool ay nagmumungkahi ng mga flag tulad ng   dahil inuuna nila ang kadalian kaysa sa tamang disenyo. isTesting  AI Detection 🥃  Maaaring mahuli ng mga tool ng AI ang amoy na ito kung iko-configure mo ang mga ito upang i-flag ang conditional logic batay sa mga estado ng pagsubok.  Subukan Sila! 🛠   Tandaan: Maraming pagkakamali ang AI Assistants  Iminungkahing Prompt: Alisin ang IsTesting method at palitan ito sa pamamagitan ng pagmomodelo ng mga environment  Nang walang Wastong Tagubilin  Sa Mga Tukoy na Tagubilin   ChatGPT   ChatGPT   Claude   Claude   Pagkalito   Pagkalito   Copilot   Copilot   Gemini   Gemini   DeepSeek   DeepSeek   Meta AI   Meta AI   Qwen   Qwen  Konklusyon 🏁  Iwasang gumamit   flag. ng isTesting  Gumamit ng dependency injection at i-modelo ang mga kapaligiran upang panatilihing magkahiwalay ang lohika ng pagsubok at produksyon.  Mga Relasyon 👩‍❤️‍💋‍👨   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  Disclaimer 📘  Ang Code Smells ay   ko. opinyon  Mga kredito 🙏  Larawan ni   sa  Christian Gertenbach Unsplash  Kapag nagdagdag ka ng mga flag ng pagsubok, pinapahina mo ang tiwala sa produksyon.   Ward Cunningham   https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true  Ang artikulong ito ay bahagi ng CodeSmell Series.   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

Ang audio na ito ay ginawa sa orihinal na wika ng kuwento!

Masyadong mahaba; Upang basahin

Make resilience your competitive advantage

Code Smell 293 - Dapat mong Iwasan ang Pagdaragdag ng isTesting o Katulad na mga Flag

Code Smell 293 - Dapat mong Iwasan ang Pagdaragdag ng isTesting o Katulad na mga Flag

About Author

MGA KOMENTO

HANG TAGS

ANG ARTIKULONG ITO AY IPINAKITA SA

Related Stories

Getting intimate with Ethereum tokens

State of the Noonion: The Year of Profitability and Product Renaissance

Encrypted Instant Messaging Recommendations January 2017

COVID-19: We Need More Than Data, We Need Insights!

Getting intimate with Ethereum tokens

State of the Noonion: The Year of Profitability and Product Renaissance

Encrypted Instant Messaging Recommendations January 2017

COVID-19: We Need More Than Data, We Need Insights!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps