Anti-vzory, ktorým by ste sa vo svojom kóde mali vyhnúť

Každý vývojár chce napísať štruktúrovaný, jednoducho naplánovaný a pekne komentovaný kód. Existuje dokonca nespočetné množstvo dizajnových vzorov, ktoré nám dávajú jasné pravidlá, ktoré treba dodržiavať, a rámec, na ktorý treba pamätať.

Ale stále môžeme nájsť anti-vzory v softvéri, ktorý bol napísaný niekedy, alebo bol napísaný príliš rýchlo.

Neškodný základný hack na rýchle vyriešenie problému môže vytvoriť precedens vo vašej kódovej základni. Môže byť kopírovaný na viac miest a premenený na vzor, ​​ktorý musíte osloviť.

Čo je teda anti-vzor?

V softvéri je anti-pattern pojem, ktorý popisuje, ako NIE vyriešiť opakujúce sa problémy vo vašom kóde. Anti-vzory sú považované za zlý dizajn softvéru a sú zvyčajne neúčinné alebo nejasné opravy.  

Oni všeobecne tiež pridať "technický dlh" - čo je kód, musíte sa vrátiť a opraviť správne neskôr.

Šesť anti-vzorov, o ktorých budem v tomto článku diskutovať, sú Špagetový kódex , Zlaté kladivo , Kotva člna , Mŕtvy kódex , Proliferácia kódexu a Boží predmet .

Špagetový kód

Špagetový kód je najznámejší anti-vzor. Je to kód s malou až nulovou štruktúrou.

Nič nie je modulárne. V náhodných adresároch sú rozložené náhodné súbory. Celý tok je ťažké sledovať a je úplne zamotaný dohromady (ako špagety).

Za normálnych okolností ide o problém, keď niekto vopred starostlivo nevymyslel tok svojho programu a práve začal programovať.

Čo to robí?! Toto nemôžem sledovať

image.png

Nejde len o nočnú moru údržby, ale je takmer nemožné pridať nové funkcie.

Neustále budete rozbíjať veci, nebudete rozumieť rozsahu svojich zmien alebo budete dávať akékoľvek presné odhady svojej práce, pretože je nemožné predvídať nespočetné množstvo problémov, ktoré sa pri takýchto archeológiách / dohadoch objavujú.

Viac sa dozviete tu o anti-vzorke špagetového kódu .

Zlaté kladivo

„Predpokladám, že je lákavé, ak jediným nástrojom, ktorý máš, je kladivo, zaobchádzať so všetkým, akoby to bol klinec.“ Abraham Maslow

Predstavte si so mnou scenár: váš vývojový tím je veľmi, veľmi kompetentný v oblasti úplne novej architektúry Hammer. Fungovalo to fantasticky na všetky vaše minulé problémy. Ste popredným svetovým tímom architektúry Hammer.

Ale teraz akosi vždy všetko nakoniec skončí pomocou tejto architektúry. Skrutka s plochou hlavou? Kladivo. Skrutka s krížovou hlavou? Kladivo. Potrebujete imbusový kľúč? Nie nie, kladivo.

Začnete uplatňovať architektonický prístup, ktorý úplne nezodpovedá tomu, čo potrebujete, ale urobí prácu. Ste odkázaní na jeden vzor a musíte sa naučiť najlepší nástroj pre najlepšiu prácu.

Celý váš program by mohol skončiť vážnym zásahom do výkonnosti, pretože sa snažíte naraziť štvorec do tvaru kruhu. Viete, že programovanie tohto kódu a vykonanie programu pomocou kladivovej architektúry pre tento problém trvá dvakrát dlhšie, ale je to jednoduchšie a je vám to dobre.

Tiež to nie je veľmi predvídateľné. Rôzne jazyky majú spoločné riešenia problémov, ktorým čelia, a majú vlastné štandardy. Nemôžete bez problémov použiť každé pravidlo, ktoré pre vás dobre fungovalo, v jednom jazyku.

Nezanedbávajte dôsledné vzdelávanie sa vo svojej kariére. Vyberte si správny jazyk pre svoj problém. Popremýšľajte o architektúre a vytlačte svoju komfortnú zónu. Skúmajte a skúmajte nové nástroje a nové spôsoby riešenia problémov, ktorým čelíte.

Viac o anti-vzore Golden Hammer sa dočítate tu .

Kotva na člne

Boat Anchor anti-vzor je miesto, kde programátori opustiť kód do codebase, pretože oni by mohli potrebovať neskôr.

Niečo kódovali mierne mimo špecifikáciu a ešte to nie je potrebné, ale sú si istí, že to bude budúci mesiac. Nechcú to teda vymazať. Pošlite ho do výroby a neskôr, keď to potrebujú, môžu rýchlo uviesť do prevádzky.

To však spôsobuje nočné mory údržby v kódovej základni, ktorá obsahuje všetok ten zastaraný kód. Obrovským problémom je, že ich kolegovia budú ťažko pracovať s tým, aký kód je zastaraný a nezmení tok, oproti kódu, ktorý to robí.

Predstavte si, že ste na hotfixu a zúfalo sa snažíte zistiť, čo je zodpovedné za zasielanie podrobností kariet zákazníkov do API na výber prostriedkov z ich banky. Mohli by ste strácať čas čítaním a ladením zastaraného kódu, bez toho, aby ste si uvedomovali, že nie ste na správnom mieste v kódovej základni.

Posledným problémom je, že zastaraný kód predĺži váš čas potrebný na zostavenie a môžete zmiešať pracovný a zastaraný kód. Mohli by ste dokonca začať chtiac-nechtiac „zapínať“ vo výrobe.

Teraz už pravdepodobne vidíte, prečo sa to nazýva anti-vzor lodnej kotvy - je ťažké ho prepraviť (pridáva sa technický dlh), ale nič nerobí (doslova, kód nemá žiadny účel, nefunguje).

Viac sa dozviete tu o anti-vzore Kotva do člna .

Mŕtvy kód

Už ste niekedy museli pozerať kód napísaný niekým, kto už vo vašej spoločnosti nepracuje? Existuje funkcia, ktorá nevyzerá, že niečo robí. Ale volá sa odkiaľkoľvek! Opýtate sa okolo a nikto iný si nie je úplne istý, čo robí, ale všetci sa príliš obávajú, aby to odstránili.

Niekedy je vidieť, čo robí, ale chýba kontext. Ste schopní čítať a rozumieť toku, ale prečo? Už to nevyzerá, že by sme mali dosiahnuť tento koncový bod. Odpoveď je pre každého iného používateľa vždy rovnaká.

Toto sa bežne označuje ako anti-vzor Mŕtveho kódu . Keď nevidíte, čo je „skutočný“ kód potrebný na zabezpečenie toku a úspešného vykonania vášho programu, v porovnaní s tým, čo bolo potrebné iba pred 3 rokmi, a nie teraz.

Tento konkrétny anti-vzor je bežnejší v dôkazoch o koncepcii alebo výskumnom kódexe, ktoré skončili vo výrobe.

Raz na technologickom stretnutí som stretol človeka, ktorý mal tento presný problém. Mal tony mŕtveho kódu, o ktorom vedel, že je mŕtvy, a veľa vecí, o ktorých mal podozrenie, že sú mŕtve. Ale nemohol dostať povolenie od vedenia, aby niekedy odstránil všetok mŕtvy kód.

O svojom prístupe hovoril ako o testovaní opíc, kde začal komentovať a vypínať veci, aby zistil, čo nafúklo produkciu. Možno trochu príliš riskantné!

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.

Viac sa dozviete tu o anti-vzore objektu Boh .

Záver

V akejkoľvek veľkej základni kódov existuje neustála rovnováha medzi správou technického dlhu, začatím nového vývoja a správou radov chýb pre váš produkt.

Dúfam, že tento článok vám dal oko, aby ste si všimli, keď by ste mohli ísť do králičej diery anti-vzoru, a nejaké nástroje, ako to vyriešiť čisto.

Zdieľam svoje písanie na Twitteri, ak sa vám tento článok páčil, a chcete vidieť viac.