Non lasciare che il codice di test si insinui nella produzione  TL;DR: Evita di aggiungere flag   o simili. isTesting  Problemi 😔  Astrazione che perde  Inquinamento del codice non commerciale  Codice fragile  Comportamento incoerente  Dipendenze nascoste  Debug difficile   Flag booleani  Test non attendibili   Codice dipendente dalla produzione  Soluzioni 😃  Rimuovi  comportamento Se  Utilizzare l'iniezione di dipendenza  Modella i servizi esterni (non   ) prenderli in giro  Configurazioni separate  Logica di test isolata  Mantenere puliti i confini del comportamento  Rifattorizzatori ⚙️   https://hackernoon.com/refactoring-014-how-to-remove-if?embedable=true  Contesto 💬  Aggiungendo flag come   , si mescolano codice di test e di produzione. isTesting  In questo modo si creano percorsi nascosti attivi solo nei test.  Inoltre, non viene trattato il vero codice di produzione.  Si rischia di trasferire il comportamento dei test alla produzione, causando bug e comportamenti imprevedibili.  Codice di esempio 📖  Sbagliato ❌   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); } }  Giusto 👉   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); } }  Rilevamento 🔍    Semi-automatico [x]  È possibile rilevare questo odore cercando flag condizionali come   ,   ,   e idiomi come questi. isTesting environment == 'test' DEBUG_MODE  Ciò indica che il comportamento dei test si sta infiltrando nel codice di produzione.  Etichette 🏷️  Prova  Livello 🔋    Intermedio [x]  Perché la biiezione è importante 🗺️  È necessaria una netta separazione tra codice di test e codice di produzione.  Quando li mescoli, interrompi la   uno a uno tra il comportamento del mondo reale e il programma. biiezione  Poiché gli ambienti sono entità del mondo reale, è necessario modellarli in modo esplicito nel   . MAPPER  Generazione AI 🤖  Il codice generato dall'intelligenza artificiale spesso introduce questo odore quando si utilizzano rapidi trucchi per i test.  Alcuni strumenti suggeriscono flag come   perché danno priorità alla semplicità rispetto alla progettazione adeguata. isTesting  Rilevamento AI 🥃  Gli strumenti di intelligenza artificiale possono captare questo odore se vengono configurati in modo da contrassegnare la logica condizionale in base agli stati di test.  Provali! 🛠   Ricorda: gli assistenti AI commettono molti errori  Prompt suggerito: rimuovere il metodo IsTesting e sostituirlo modellando gli ambienti  Senza istruzioni appropriate  Con istruzioni specifiche   ChatGPT   ChatGPT   Claudio   Claudio   Perplessità   Perplessità   Copilot   Copilot   Gemelli   Gemelli   Ricerca profonda   Ricerca profonda   Meta-IA   Meta-IA   Qwen   Qwen  Conclusione 🏁  Evitare di utilizzare i flag   . isTesting  Utilizzare l'iniezione di dipendenza e modellare gli ambienti per mantenere separate la logica di test e quella di produzione.  Relazioni 👩‍❤️‍💋‍👨   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  Dichiarazione di non responsabilità 📘  Gli odori del codice sono la mia   . opinione  Crediti 🙏  Foto di   su  Christian Gertenbach Unsplash  Aggiungendo flag di test, si compromette la fiducia nella produzione.   Reparto Cunningham   https://hackernoon.com/400-thinking-provoking-software-engineering-quotes?embedable=true  Questo articolo fa parte della serie 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

Questo audio è prodotto nella lingua originale della storia!

Troppo lungo; Leggere

Code Smell 293 - Dovresti evitare di aggiungere flag isTesting o simili

Code Smell 293 - Dovresti evitare di aggiungere flag isTesting o simili

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

New Year, New Exciting Features: Mint Your Name, Watch Web 2.5 and Meet The Top Startups of The Year

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

HackerNoon - A User Experience Analysis: Part 2

Raggiungi più lettori! POTENZIA la tua storia su HackerNoon

New Year, New Exciting Features: Mint Your Name, Watch Web 2.5 and Meet The Top Startups of The Year

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

HackerNoon - A User Experience Analysis: Part 2

Raggiungi più lettori! POTENZIA la tua storia su HackerNoon

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps