Anti-mustrid, mida peaksite oma koodis vältima

Iga arendaja soovib kirjutada struktureeritud, lihtsalt planeeritud ja kenasti kommenteeritud koodi. On olemas isegi lugematu hulk kujundusmustreid, mis annavad meile selged reeglid, mida järgida, ja raamistiku, mida silmas pidada.

Kuid sellegipoolest võime tarkvarast leida anti-mustreid, mis on kirjutatud mõne aja pärast või on kirjutatud liiga kiiresti.

Kahjutu põhiline häkkimine probleemi kiireks lahendamiseks võib teie koodibaasis luua pretsedendi. Seda saab kopeerida mitmesse kohta ja muuta anti-mustriks, mida peate lahendama.

Mis on anti-muster?

Tarkvaras on anti-muster termin, mis kirjeldab, kuidas EI lahendata teie koodis korduvaid probleeme. Anti-mustreid peetakse tarkvara halvaks kujundamiseks ja need on tavaliselt ebaefektiivsed või ebaselged parandused.  

Üldiselt lisavad nad ka "tehnilise võla" - see on kood, mille peate hiljem tagasi tulema ja korralikult parandama .

Kuus anti-mustrit, mida selles artiklis käsitlen, on spagetikood , kuldvasar , paadiankur , surnud kood , koodi levik ja jumala objekt .

Spagetikood

Spagetikood on tuntuim anti-muster. See on kood, mille struktuur on väike kuni null.

Miski pole moduleeritud. On juhuslikke faile, mis on visatud juhuslikesse kataloogidesse. Kogu voolu on raske jälgida ja see on täiesti kokku sassis (nagu spagetid).

Tavaliselt on see küsimus, kus keegi pole oma programmi voogu eelnevalt hoolikalt läbi mõelnud ja lihtsalt kodeerima hakanud.

Mida see teeb ?! Ma ei saa seda jälgida

image.png

See pole mitte ainult hooldusunenägu, vaid muudab uue funktsionaalsuse lisamise võimatuks.

Sa murrad pidevalt asju, ei saa aru oma muudatuste ulatusest ega anna oma töö kohta täpseid hinnanguid, kuna sellise arheoloogia / oletuste tegemisel on võimatu ette näha lugematul hulgal probleeme.

Spagetikoodi anti-mustri kohta saate rohkem lugeda siit .

Kuldvasar

"Ma arvan, et on ahvatlev, kui ainus tööriist, mis teil on, on haamer, kohelda kõike nagu naelu." Abraham Maslow

Kujutage koos minuga ette stsenaariumi: teie arendustiim on uhiuue Hammeri arhitektuuri osas väga-väga pädev. See on fantastiliselt toiminud kõigi teie varasemate probleemide puhul. Olete maailma juhtiv Hammeri arhitektuurimeeskond.

Kuid nüüd jõuab kuidagi kuidagi alati see arhitektuur. Lameda kruviga? Vasar. Phillipsi kruvi? Vasar. Kas vajate kuuskantvõtit? Ei, sa ei tee seda, haamer seda.

Hakkate rakendama arhitektuurilist lähenemist, mis ei sobi täpselt teie vajadustega, kuid saab töö tehtud. Olete ühest mustrist üle sõltuv ja peate õppima parima tööriista parima töö jaoks.

Kogu teie programm võib lõppkokkuvõttes võtta tõsise jõudlushiti, kuna proovite ruudu rõngakujuliseks rammida. Teate, et koodi sisestamine ja programmi käivitamine haamriarhitektuuri abil võtab selle probleemi jaoks kaks korda kauem aega, kuid see on lihtsam ja see on see, mis teile sobib.

Samuti pole see eriti etteaimatav. Erinevatel keeltel on probleemid, millega nad silmitsi seisavad, ühised lahendused ja oma standardid. Te ei saa rakendada kõiki reegleid, mis teie jaoks hästi toimisid, ühes keeles, ilma probleemideta.

Ärge unustage oma karjääri jooksul järjepidevat õppimist. Valige oma probleemile sobiv keel. Mõelge arhitektuurile ja lükake oma mugavustsoon välja. Uurige ja uurige uusi tööriistu ja uusi viise, kuidas probleemidele silmitsi seista.

Golden Hammeri anti-mustri kohta saate rohkem lugeda siit .

Paadi ankur

Boat Ankru anti-muster on koht, kus programmeerijad jätnud koodi Codebase sest nad võivad seda hiljem vaja.

Nad kodeerisid midagi veidi täpsustamata ja seda pole veel vaja, kuid nad on kindlad, et saavad järgmisel kuul. Nii et nad ei taha seda kustutada. Saada see tootmisse ja hiljem, kui nad seda vajavad, saavad nad selle kiiresti tööle panna.

Kuid see põhjustab koodibaasis hooldusunenägusid, mis sisaldavad kogu seda vananenud koodi. Suur probleem on see, et nende kolleegidel on raske välja töötada, milline kood on vananenud ja ei muuda voogu, võrreldes koodiga, mis seda teeb.

Kujutage ette, et teil on kiire lahendus ja proovite meeleheitlikult välja mõelda, mis on vastutav klientide kaardiandmete saatmise eest API-le, et nende pangast raha välja võtta. Võite raisata aega vananenud koodi lugemisele ja silumisele, mõistmata, et te pole isegi koodibaasis õiges kohas.

Viimane küsimus on see, et vananenud kood muudab teie koostamisaja pikemaks ja võite segada töötavat ja vananenud koodi. Võiksite hakata seda isegi tahtmatult tootmises "sisse lülitama".

Nüüd näete ilmselt, miks seda nimetatakse paadiankru anti-mustriks - seda on raske kanda (lisab tehnilist võlga), kuid ei tee midagi (sõna otseses mõttes ei ole koodil mingit eesmärki, see ei tööta).

Siit saate rohkem lugeda paadi ankrumudeli anti-mustri kohta.

Surnud kood

Kas olete kunagi pidanud vaatama koodi, mille on kirjutanud keegi, kes teie ettevõttes enam ei tööta? Seal on funktsioon, mis ei tundu midagi tehvat. Aga seda kutsutakse igalt poolt! Küsite ringi ja keegi teine ​​pole päris kindel, mida see teeb, kuid kõik on selle kustutamiseks liiga mures.

Mõnikord näete, mida see teeb, kuid kontekst puudub. Oled võimeline voolu lugema ja aru saama, aga miks? Tundub, et me ei pea enam seda lõpp-punkti jõudma. Vastus on alati sama vastus kõigile erinevatele kasutajatele.

Seda kirjeldatakse tavaliselt kui Dead-koodi anti-mustrit. Kui te ei näe, mis on "tegelik" kood, mis on vajalik teie programmi kulgemiseks ja edukaks käivitamiseks, võrreldes sellega, mida oli vaja alles 3 aastat tagasi, mitte nüüd.

See konkreetne anti-muster on tavalisem tõestuseks kontseptsioonile või uurimiskoodile, mis jõudis tootmisse.

Ühel korral kohtusin tehnikakohtumisel kutiga, kellel oli just see probleem. Tal oli palju surnud koode, mis ta teadis olevat surnud, ja palju partiisid, mida ta kahtlustas, oli surnud. Kuid ta ei saanud juhtkonnalt luba kogu surnud koodi eemaldamiseks.

Ta viitas oma lähenemisviisile kui ahvide testimisele, kus ta hakkas asju kommenteerima ja välja lülitama, et näha, mis tootmises õhkis. Võib-olla natuke liiga riskantne!

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.

Siit saate lähemalt lugeda Jumala objekti anti-mustri kohta.

Järeldus

Igas suures koodibaasis on pidev tasakaal tehniliste võlgade haldamise, uue arenduse alustamise ja teie toote vigade järjekorra haldamise vahel.

Ma loodan, et see artikkel on teile silma andnud, kui märkate anti-mustri jänese auku, ja mõned tööriistad selle puhtaks lahendamiseks.

Jagan oma kirjutist Twitteris, kui teile see artikkel meeldis ja soovite rohkem näha.