Anti-modeliai, kurių turėtumėte vengti savo kode

Kiekvienas kūrėjas nori parašyti struktūrizuotą, paprastai suplanuotą ir gražiai pakomentuotą kodą. Yra net begalė dizaino modelių, kurie suteikia mums aiškias taisykles, kurių reikia laikytis, ir pagrindą, į kurį reikia atsižvelgti.

Tačiau programinėje įrangoje, kuri buvo parašyta praėjus tam tikram laikui arba parašyta per greitai, vis tiek galime rasti antimalių modelių.

Nekenksmingas pagrindinis įsilaužimas greitai išspręsti problemą gali sukurti precedentą jūsų kodo bazėje. Jį galima nukopijuoti keliose vietose ir paversti anti-modeliu, kurį reikia spręsti.

Taigi, kas yra antimodelis?

Programinėje įrangoje „anti-model“ yra terminas, apibūdinantis, kaip NE išspręsti pasikartojančias jūsų kodo problemas. Anti-modeliai yra laikomi netinkamu programinės įrangos dizainu ir dažniausiai yra neveiksmingi arba neaiškūs pataisymai.  

Paprastai jie taip pat prideda „techninę skolą“ - kodą turite sugrįžti ir vėliau tinkamai ištaisyti .

Šeši antimaliai modeliai, kuriuos aptarsiu šiame straipsnyje, yra „ Spageti kodas“ , „ Auksinis plaktukas“ , „ Laivo inkaras“ , „ Negyvasis kodas“ , „Kodo ir Dievo objekto platinimas“ .

Spagečių kodas

Spagečių kodas yra geriausiai žinomas antimodelis. Tai kodas, kurio struktūra yra nuo nulio iki nulio.

Niekas nėra moduliuojamas. Yra atsitiktinių failų, išmėtytų atsitiktiniuose kataloguose. Visą srautą sunku sekti ir jis yra visiškai susipainiojęs (kaip spagečiai).

Paprastai tai yra problema, kai kas nors iš anksto nėra gerai apgalvojęs savo programos eigos ir tiesiog pradėjo koduoti.

Ką tai daro?! Aš negaliu to sekti

image.png

Tai ne tik priežiūros košmaras, bet ir neįmanoma pridėti naujų funkcijų.

Jūs nuolat laužysite dalykus, nesuprasite savo pakeitimų apimties arba pateiksite tikslius savo darbo įvertinimus, nes neįmanoma numatyti daugybės klausimų, kurie iškyla atliekant tokią archeologiją / spėliones.

Čia galite daugiau sužinoti apie „ Spaghetti Code“ anti-modelį.

Auksinis plaktukas

- Manau, kad yra viliojanti, jei vienintelis jūsų turimas įrankis yra plaktukas, viską vertinti taip, lyg tai būtų vinis. Abraomas Maslowas

Įsivaizduokite su manimi scenarijų: jūsų „dev“ komanda yra labai, labai kompetentinga visiškai naujoje „Hammer“ architektūroje. Tai fantastiškai pasiteisino dėl visų jūsų praeities problemų. Jūs esate pirmaujanti pasaulyje „Hammer“ architektūros komanda.

Bet dabar kažkaip visada viskas naudojama šioje architektūroje. Plokščios galvutės varžtas? Plaktukas. „Phillips“ galvutės varžtas? Plaktukas. Jums reikia „Allen“ veržliarakčio? Ne tu ne, užkalk.

Pradedate taikyti architektūrinį požiūrį, kuris ne visai tinka tam, ko jums reikia, tačiau atliksite darbą. Jūs per daug pasitikite vienu modeliu ir turite išmokti geriausią įrankį, kad galėtumėte atlikti geriausią darbą.

Visa jūsų programa gali patekti į rimtą pasirodymą, nes bandote kvadratą suskaldyti apskritimo forma. Jūs žinote, kad užtrunka dvigubai ilgiau, kol užkoduojate ir vykdote programą naudodami plaktuko architektūrą šiai problemai spręsti, tačiau tai yra paprasčiau ir tai, kas jums patogu.

Tai taip pat nėra labai nuspėjama. Skirtingos kalbos turi bendrus problemų, su kuriomis jie susiduria, taisymus ir savo standartus. Negalite pritaikyti visų taisyklių, kurios jums buvo naudingos, viena kalba be jokių problemų.

Nepamirškite nuosekliai mokytis savo karjeroje. Pasirinkite problemai tinkamą kalbą. Pagalvokite apie architektūrą ir išstumkite savo komforto zoną. Tyrinėkite ir tyrinėkite naujas priemones ir naujus būdus, kaip spręsti iškilusias problemas.

Daugiau apie „ Golden Hammer“ anti-modelį galite paskaityti čia .

Laivo inkaras

Boat Anchor“ antimodelis yra tas, kur programuotojai kodo bazėje palieka kodą, nes vėliau to gali prireikti.

Jie užkodavo kažką šiek tiek neatitinkančio specifikacijos ir to dar nereikia, tačiau yra tikri, kad kitą mėnesį tai padarys. Taigi jie nenori jo ištrinti. Nusiųskite ją į gamybą, o vėliau, kai to prireiks, galės greitai pradėti veikti.

Bet tai sukelia priežiūros košmarus kodų bazėje, kurioje yra visas tas pasenęs kodas. Didžiulė problema yra ta, kad jų kolegoms bus sunku išsiaiškinti, kuris kodas yra pasenęs ir nekeičia srauto, palyginti su tuo kodu.

Įsivaizduokite, kad naudojatės karštu taisymu ir desperatiškai bandote išsiaiškinti, kas yra atsakinga už klientų kortelių duomenų siuntimą API, kad būtų paimtos lėšos iš jų banko. Galite sugaišti laiką skaitydami ir derindami pasenusį kodą, patys nesuvokdami, kad net nesate tinkamoje kodo bazės vietoje.

Paskutinis klausimas yra tas, kad pasenęs kodas ilgina jūsų kūrimo laiką ir galite maišyti veikiantį ir pasenusį kodą. Galima net pradėti netyčia „įjungti“ gamyboje.

Dabar jūs tikriausiai suprantate, kodėl jis vadinamas laivo inkaro antimustriniu modeliu - jis sunkus nešiotis (prideda techninę skolą), bet nieko nedaro (tiesiogine to žodžio prasme, kodas neatlieka jokio tikslo, jis neveikia).

Daugiau apie „ Boat inchor anti-model“ galite skaityti čia .

Negyvas kodas

Ar teko kada pažvelgti į kodą, kurį parašė asmuo, kuris nebedirba jūsų įmonėje? Yra funkcija, kuri neatrodo, kad ji ką nors daro. Bet tai vadinama iš visur! Jūs klausiate, ir niekas kitas nėra visiškai tikras, ką jis daro, bet visi per daug nerimauja, kad jį ištrintumėte.

Kartais galite pamatyti, ką jis daro, bet trūksta konteksto. Sugebate perskaityti ir suprasti srautą, bet kodėl? Panašu, kad mums nebereikia pasiekti to taško. Atsakymas visada yra tas pats atsakymas kiekvienam vartotojui.

Tai paprastai apibūdinama kaip „ Dead code anti-model“. Kai nematote, kas yra „tikrasis“ kodas, reikalingas jūsų programos eigai ir sėkmingam vykdymui, palyginti su tuo, kuris buvo reikalingas tik prieš 3 metus, o ne dabar.

Šis konkretus antimodelis yra labiau paplitęs įrodant koncepciją ar tyrimo kodą, kuris baigėsi gamyba.

Vieną kartą susitikime technikos srityje sutikau vaikiną, kuris turėjo būtent šią problemą. Jis turėjo daug negyvų kodų, kurie, kaip jis žinojo, buvo mirę, ir daugybė įtariamų mirė. Bet jis negalėjo gauti vadovybės leidimo kada nors pašalinti visą mirusį kodą.

Savo požiūrį jis įvardijo kaip „ Beždžionių bandymą“, kur jis pradėjo komentuoti ir išjungti dalykus, norėdamas pamatyti, kas sprogo gamyboje. Gal šiek tiek per daug rizikinga!

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.

Čia galite daugiau sužinoti apie Dievo objekto anti-modelį.

Išvada

Bet kurioje didelėje kodų bazėje yra pastovi pusiausvyra tarp techninių skolų valdymo, naujos plėtros pradžios ir jūsų produkto klaidų eilės valdymo.

Tikiuosi, kad šis straipsnis atkreipė dėmesį į pastebėjimą, kai galbūt einate ant triušio skylės, kuriai būdingas antimodelis, ir keletą priemonių, kaip tai švariai išspręsti.

Dalinuosi savo rašymu „Twitter“, jei jums patiko šis straipsnis ir norite pamatyti daugiau.