Anti-kuviot, joita sinun tulisi välttää koodissasi

Jokainen kehittäjä haluaa kirjoittaa jäsennellyn, yksinkertaisesti suunnitellun ja hienosti kommentoidun koodin. On olemassa jopa lukemattomia suunnittelumalleja, jotka antavat meille selkeät säännöt, jotka on noudatettava, ja kehyksen, joka on pidettävä mielessä.

Mutta voimme silti löytää anti-malleja ohjelmistoista, jotka on kirjoitettu jonkin aikaa tai kirjoitettu liian nopeasti.

Vaaraton perushakkerointi ongelman ratkaisemiseksi nopeasti voi luoda ennakkotapauksen koodipohjaasi. Se voidaan kopioida useisiin paikkoihin ja muuttua anti-malliksi, jota sinun on käsiteltävä.

Joten mikä on anti-malli?

Ohjelmistossa anti-pattern on termi, joka kuvaa, kuinka EI saa ratkaista koodissasi toistuvia ongelmia. Anti-malleja pidetään huonona ohjelmistosuunnitteluna, ja ne ovat yleensä tehottomia tai epäselviä korjauksia.  

Yleensä ne lisäävät myös "teknisen velan" - koodin, joka sinun on palattava takaisin ja korjattava kunnolla myöhemmin.

Kuusi anti-mallia, joista keskustelen tässä artikkelissa, ovat spagettikoodi , kultainen vasara , veneen ankkuri , kuollut koodi , koodin ja Jumalan objektin lisääntyminen .

Spagettikoodi

Spagettikoodi on tunnetuin anti-kuvio. Se on koodi, jolla on vähän tai nolla.

Mikään ei ole modulaarinen. On satunnaisia ​​tiedostoja, jotka on siroteltu satunnaisiin hakemistoihin. Koko virtausta on vaikea seurata, ja se on täysin sotkeutunut yhteen (kuten spagetti).

Normaalisti tämä on asia, jossa joku ei ole tarkkaan miettinyt ohjelmansa kulkua etukäteen ja on juuri alkanut koodata.

Mitä se tekee?! En voi seurata tätä

image.png

Tämä ei ole vain ylläpito painajainen, mutta se tekee lähes mahdottomaksi lisätä uusia toimintoja.

Murskaat jatkuvasti asioita, et ymmärrä muutosten laajuutta tai annat tarkkoja arvioita työstäsi, koska on mahdotonta ennakoida lukemattomia kysymyksiä, jotka nousevat esiin tällaista arkeologiaa / arvauksia tehdessäsi.

Voit lukea lisää täältä Spaghetti-koodin anti-kuviosta.

Kultainen vasara

"Oletan, että on houkuttelevaa, jos ainoa työkalusi, jolla sinulla on vasara, kohdella kaikkea kuin naulaa." Abraham Maslow

Kuvittele kanssani skenaario: dev-tiimisi on erittäin, erittäin pätevä upouuden Hammer-arkkitehtuurin suhteen. Se on toiminut fantastisesti kaikissa aiemmissa asioissasi. Olet maailman johtava Hammer-arkkitehtuuritiimi.

Mutta nyt jotenkin kaikki päätyy aina käyttämään tätä arkkitehtuuria. Litteäpäinen ruuvi? Vasara. Phillips-ruuvi? Vasara. Tarvitsetko kuusiokoloavainta? Ei, älä vasara sitä.

Aloitat soveltamaan arkkitehtuuriajattelua joka ei aivan sovi mitä tarvitset, mutta hoitaa hommansa. Olet liian riippuvainen yhdestä mallista ja sinun on opittava paras työkalu parhaaseen työhön.

Koko ohjelmasi voi päätyä ottamaan vakavan suorituskyvyn, koska yrität lyödä neliötä ympyrän muotoon. Tiedät, että koodaaminen ja ohjelman suorittaminen vasaraarkkitehtuurilla vie kaksi kertaa kauemmin tätä ongelmaa varten, mutta se on helpompaa ja se on sinulle miellyttävä asia.

Se ei myöskään ole kovin ennustettavissa. Eri kielillä on yhteiset korjaukset kohtaamiinsa ongelmiin ja omat standardinsa. Et voi soveltaa kaikkia yksittäisiä sääntöjä, jotka toimivat sinulle hyvin yhdellä kielellä, seuraavaan ilman ongelmia.

Älä laiminlyö johdonmukaista oppimista urallasi. Valitse ongelmallesi oikea kieli. Ajattele arkkitehtuuria ja työnnä mukavuusalueesi ulos. Tutki ja tutki uusia työkaluja ja uusia tapoja lähestyä kohtaamiasi ongelmia.

Voit lukea lisää täältä Golden Hammerin anti-kuviosta.

Veneen ankkuri

Vene Ankkuri antisuunnittelumalli siellä ohjelmoijat jättää koodin codebase koska he tarvitsevat sitä myöhemmin.

He koodasivat jotain hieman määrittelystä poikkeavaa ja sitä ei vielä tarvita, mutta he ovat varmoja, että tulevat ensi kuussa. Joten he eivät halua poistaa sitä. Lähetä se tuotantoon ja myöhemmin, kun he tarvitsevat sitä, he voivat saada sen toimimaan nopeasti.

Mutta tämä aiheuttaa ylläpito painajaisia ​​koodipohjassa, joka sisältää kaiken vanhentuneen koodin. Valtava ongelma on, että heidän kollegoillaan on vaikea selvittää mikä koodi on vanhentunut eikä muuta virtausta verrattuna siihen koodiin, joka tekee.

Kuvittele, että sinulla on pikakorjaus ja yrität epätoivoisesti selvittää, mikä on vastuussa asiakkaiden korttitietojen lähettämisestä sovellusliittymälle varojen nostamiseksi pankista. Voit tuhlata aikaa vanhentuneen koodin lukemiseen ja virheenkorjaukseen huomaamatta, ettet ole edes oikeassa paikassa kooditietokannassa.

Viimeinen asia on, vanhentunut koodi pidentää rakennusaikaa ja saatat sekoittaa toimivan ja vanhentuneen koodin. Voit jopa alkaa vahingossa "kytkeä sen päälle" tuotannossa.

Nyt voit luultavasti nähdä, miksi sitä kutsutaan veneen ankkurin anti-malliksi - se on raskas kantaa (lisää teknistä velkaa), mutta ei tee mitään (kirjaimellisesti, koodilla ei ole tarkoitusta, se ei toimi).

Voit lukea lisää täältä veneen ankkurin anti-kuviosta.

Kuollut koodi

Oletko koskaan joutunut katsomaan koodia, jonka on kirjoittanut joku, joka ei enää toimi yrityksessäsi? On toiminto, joka ei näytä tekevän mitään. Mutta sitä kutsutaan kaikkialta! Kysyt ympärilläsi, eikä kukaan muu ole aivan varma, mitä se tekee, mutta kaikki ovat liian huolissaan sen poistamisesta.

Joskus voit nähdä, mitä se tekee, mutta asiayhteys puuttuu. Pystyt lukemaan ja ymmärtämään virtauksen, mutta miksi? Näyttää siltä, ​​että meidän ei tarvitse enää päästä kyseiseen päätepisteeseen. Vastaus on aina sama vastaus jokaiselle käyttäjälle.

Tätä kuvataan yleisesti Dead-koodin anti-mallina. Kun et näe mitä "todellinen" koodi tarvitaan ohjelman kulkuun ja onnistuneeseen suorittamiseen verrattuna siihen, mitä tarvittiin vasta 3 vuotta sitten, ei nyt.

Tämä erityinen anti-malli on yleisempi todiste konseptista tai tutkimuksen koodista, joka päätyi tuotantoon.

Kerran teknisessä tapaamisessa tapasin kaverin, jolla oli juuri tämä ongelma. Hänellä oli tonnia kuollutta koodia, jonka hän tiesi olevan kuollut, ja erien, joiden epäili olevan kuolleita. Mutta hän ei saanut johdolta lupaa poistaa kaikki kuolleet koodit.

Hän viittasi lähestymistapaansa Monkey-testauksena, jossa hän alkoi kommentoida ja sammuttaa asioita nähdäksesi, mikä räjähti tuotannossa. Ehkä hieman liian riskialtista!

If you don't fancy Monkey testing your production app, try to frame technical debt to management as "technical risk" to better explain why you think it's so important to tidy up.

Or even write down everything your particular module/section does you want to re-write, and take an iterative approach to remove piece by piece the dead code. Checking every time you haven't broken anything.

You don't have to drop a huge rewrite with thousands of changes. But you will either understand why it's so crucial and document why it's needed, or delete the dead code as you desired.

You can read more here about the Dead code anti-pattern.

Proliferation of Code

Objects or modules regularly communicate with others. If you have a clean, modularised codebase you often will need to call into other separate modules and call new functions.

The Proliferation of Code anti-pattern is when you have objects in your codebase that only exist to invoke another more important object. Its purpose is only as a middleman.

This adds an unnecessary level of abstraction (adds something that you have to remember) and serves no purpose, other than to confuse people who need to understand the flow and execution of your codebase.

A simple fix here is to just remove it. Move the responsibility of invoking the object you really want to the calling object.

You can read more here about the Proliferation of Code anti-pattern.

God Object

If everywhere in your codebase needs access to one object, it might be a God object.

God objects do too much. They are responsible for the user id, the transaction id, the customer's first and last name, the total sum of the transaction, the item/s the user is purchasing...you get the picture.

It is sometimes called the Swiss Army Knife anti-pattern because you only really need it to cut some twine, but it also can be a nail file, saw, pair of tweezers, scissors, bottle opener and a cork screw too.

In this instance you need to separate out and modularise your code better.

Programmers often compare this problem to asking for a banana, but receiving a gorilla holding a banana. You got what you asked for, but more than what you need.

The SOLID principles explicitly discuss this in object orientated languages, to help us model our software better (if you don't know what the SOLID principles are, you can read this article).

The S in the acronym stands for Single Responsibility - every class/module/function should have responsibility over one part of the system, not multiple.

You can see this problem over and over again, how about the below interface?

interface Animal { numOfLegs: string; weight: number; engine: string; model: string; sound: string; claws: boolean; wingspan: string; customerId: string; } 

Can you see by even just briefly scanning this interface that the responsibility of this is far too broad, and needs refactoring? Whatever implements this has the potential to be a God object.

How about this?

 interface Animal { numOfLegs: string; weight: number; sound: string; claws: boolean; } interface Car { engine: string; model: string; } interface Bird { wingspan: string; } interface Transaction { customerId: string; } 

Interface segregation will keep your code clear about where the responsibilities lie, and stop forcing classes that only need wingspan to also implement the engine, customerId and model  and so on.

Voit lukea lisää täältä Jumalan esineiden anti-kuviosta.

Johtopäätös

Kaikissa suurissa koodikannoissa on vakaa tasapaino teknisen velan hallinnan, uuden kehityksen aloittamisen ja tuotteesi virheiden jonon hallinnan välillä.

Toivon, että tämä artikkeli on antanut sinulle silmän tarkkailulle, kun saatat mennä alas anti-kuvion kaninreikään, ja joitain työkaluja sen ratkaisemiseksi puhtaasti.

Jaan kirjoitukseni Twitterissä, jos pidit tästä artikkelista ja haluat nähdä lisää.