Fiecare dezvoltator dorește să scrie cod structurat, simplu planificat și frumos comentat. Există chiar și o multitudine de modele de proiectare care ne oferă reguli clare de urmat și un cadru de care să ținem cont.

Dar putem găsi totuși anti-tipare în software-ul care a fost scris cu ceva timp sau a fost scris prea repede.

Un hack de bază inofensiv pentru a rezolva rapid o problemă poate crea un precedent în baza de cod. Poate fi copiat pe mai multe locuri și transformat într-un anti-model pe care trebuie să îl abordați.

Deci, ce este un anti-model?

În software, anti-model este un termen care descrie modul în care NU puteți rezolva problemele recurente din codul dvs. Anti-pattern-urile sunt considerate ca fiind proaste pentru software și sunt de obicei corecții ineficiente sau obscure.

În general, ele adaugă și „datorii tehnice” – care este codul pe care trebuie să-l întoarceți și să îl remediați corect mai tarziu.

Cele șase anti-tipare pe care le voi discuta în acest articol sunt Codul spaghetelor, Ciocanul de Aur, Ancoră pentru bărci, Cod mort, Proliferarea codului si Obiectul lui Dumnezeu.

Codul spaghetelor

Codul spaghetelor este cel mai cunoscut anti-model. Este un cod cu o structură mică până la zero.

Nimic nu este modularizat. Există fișiere aleatorii împrăștiate în directoare aleatorii. Întregul flux este dificil de urmat și este complet încurcat (ca spaghetele).

În mod normal, aceasta este o problemă în care cineva nu a gândit cu atenție fluxul programului lor în prealabil și tocmai a început să codeze.

Ce face?! Nu pot urmări acest lucru

image.png

Acesta nu este doar un coșmar de întreținere, ci face aproape imposibil să adaugi noi funcționalități.

Veți rupe în mod constant lucrurile, nu veți înțelege sfera modificărilor dvs. sau veți da estimări exacte pentru munca dvs., deoarece este imposibil să prevedeți nenumăratele probleme care apar atunci când faceți astfel de arheologie / presupuneri.

Puteți citi mai multe Aici despre Codul spaghetelor anti-model.

Ciocanul de Aur

„Presupun că este tentant, dacă singurul instrument pe care îl ai este un ciocan, să tratezi totul ca și cum ar fi un cui”. Abraham Maslow

Imaginați-vă un scenariu cu mine: echipa dvs. de dezvoltatori este foarte, foarte competentă pentru noua arhitectură Hammer. A funcționat fantastic pentru toate seturile dvs. anterioare de probleme. Sunteți cea mai importantă echipă de arhitectură Hammer din lume.

Dar acum, cumva, totul ajunge să folosească întotdeauna această arhitectură. Un șurub cu cap plat? Ciocan. Șurub cu cap Phillips? Ciocan. Ai nevoie de o cheie Allen? Nu, nu, ciocănește-l.

Începi să aplici o abordare arhitecturală care nu o face destul de se potrivește cu ceea ce aveți nevoie, dar face treaba. Sunteți prea dependenți de un singur model și trebuie să învățați cel mai bun instrument pentru cea mai bună slujbă.

Întregul dvs. program ar putea ajunge să aibă o lovitură serioasă de performanță, deoarece încercați să montați un pătrat într-o formă de cerc. Știți că durează de două ori mai mult timp pentru a codifica și a executa un program folosind arhitectura ciocan pentru această problemă, dar este Mai ușor și cu asta te simți confortabil.

De asemenea, nu este foarte previzibil. Diferite limbi au soluții comune la problemele cu care se confruntă și la propriile standarde. Nu puteți aplica fiecare regulă care a funcționat bine pentru dvs. într-o limbă la următoarea, fără probleme.

Nu neglija învățarea constantă în carieră. Alegeți limba potrivită pentru problema dvs. Gândiți-vă la arhitectură și împingeți-vă zona de confort. Cercetează și investighează noi instrumente și noi modalități de abordare a problemelor cu care te confrunți.

Puteți citi mai multe Aici despre Ciocanul de Aur anti-model.

Ancoră pentru bărci

Ancoră pentru bărci anti-model este locul în care programatorii lasă codul în baza de cod deoarece s-ar putea să aibă nevoie de el mai târziu.

Au codificat ceva ușor în afara specificațiilor și încă nu este necesar, dar sunt siguri că o vor face luna viitoare. Deci nu vor să o șteargă. Trimiteți-l la producție și, mai târziu, când au nevoie de el, îl pot pune rapid în funcțiune.

Dar acest lucru provoacă coșmaruri de întreținere în baza de cod care conține tot codul învechit. Problema uriașă este că colegilor lor le va fi greu să stabilească ce cod este învechit și nu schimbă fluxul, comparativ cu codul care îl face.

Imaginați-vă că vă aflați într-o soluție rapidă și căutați cu disperare să aflați ce este responsabil pentru trimiterea detaliilor cardului clienților către API pentru a retrage fonduri de la banca lor. Ai putea pierde timpul citind și depanând codul învechit, fără să-ți dai seama că nici măcar nu te afli în locul potrivit în baza de coduri.

Ultima problemă este că codul învechit îți face timpul de construcție mai lung și poți confunda codul de lucru și cel învechit. Ați putea începe chiar să „activați” din producție, din greșeală.

Acum puteți vedea probabil de ce se numește ancoră de barcă anti-model – este greu de transportat (adaugă datorii tehnice), dar nu face nimic (destul de literal, codul nu are niciun scop, nu funcționează).

Puteți citi mai multe Aici despre Ancora barcii anti-model.

Cod mort

A trebuit vreodată să te uiți la codul scris de cineva care nu mai lucrează la compania ta? Există o funcție care nu pare să facă nimic. Dar se cheamă de pretutindeni! Întrebați în jur și nimeni altcineva nu este sigur de ceea ce face, dar toată lumea este prea îngrijorată pentru ao șterge.

Uneori puteți vedea ce face, dar contextul lipsește. Ești capabil să citești și să înțelegi fluxul, dar De ce? Se pare că nu mai trebuie să atingem acel punct final. Răspunsul este întotdeauna același răspuns pentru fiecare utilizator diferit.

Acest lucru este descris în mod obișnuit ca Cod mort anti-model. Când nu puteți vedea ce este codul „real” necesar pentru fluxul și execuția cu succes a programului dvs., față de ceea ce era necesar doar acum 3 ani, și nu acum.

Acest anti-model particular este mai frecvent în dovezi privind conceptul sau codul de cercetare care a ajuns la producție.

Odată, la o întâlnire tehnologică, am întâlnit un tip care avea această problemă exactă. Avea o mulțime de coduri moarte, despre care știa că erau moarte, și multe despre care bănuia că erau moarte. Dar nu a putut obține permisiunea conducerii pentru a elimina vreodată tot codul mort.

El s-a referit la abordarea sa ca Testarea maimuțelor, unde a început să comenteze și să oprească lucrurile pentru a vedea ce a explodat în producție. Poate un pic prea riscant!

Dacă nu vă place Testarea maimuțelor aplicația dvs. de producție, încercați să încadrați datoria tehnică față de management „risc tehnic” pentru a explica mai bine de ce crezi că este atât de important să faci ordine.

Sau chiar scrieți tot modulul / secțiunea dvs. particulară pe care doriți să o rescrieți și luați o abordare iterativă pentru a elimina bucată cu bucată codul mort. Verificând de fiecare dată când nu ați spart nimic.

Nu trebuie să renunțați la o rescriere uriașă cu mii de modificări. Dar fie veți înțelege de ce este atât de important și veți documenta de ce este necesar, sau veți șterge codul mort așa cum ați dorit.

Puteți citi mai multe Aici despre Cod mort anti-model.

Proliferarea codului

Obiectele sau modulele comunică în mod regulat cu ceilalți. Dacă aveți o bază de cod curată, modularizată, va trebui adesea să apelați în alte module separate și să apelați funcții noi.

Proliferarea codului anti-model este atunci când aveți obiecte în baza de cod care există doar pentru a invoca un alt obiect mai important. Scopul său este doar ca intermediar.

Acest lucru adaugă un nivel inutil de abstractizare (adaugă ceva de care trebuie să vă amintiți) și nu servește altui scop decât să confundați oamenii care trebuie să înțeleagă fluxul și execuția bazei de cod.

O soluție simplă aici este doar să o eliminați. Mutați responsabilitatea invocării obiectului dvs. într-adevăr doresc obiectul apelant.

Puteți citi mai multe Aici despre Proliferarea codului anti-model.

Obiectul lui Dumnezeu

Dacă peste tot în baza de coduri aveți nevoie de acces la un obiect, ar putea fi un obiect al lui Dumnezeu.

Obiectele lui Dumnezeu o fac de asemenea mult. Aceștia sunt responsabili pentru ID-ul utilizatorului, ID-ul tranzacției, numele și prenumele clientului, suma totală a tranzacției, articolele pe care le cumpără utilizatorul … veți obține imaginea.

Uneori se numește Briceag anti-model, deoarece aveți nevoie de el doar pentru a tăia niște sfori, dar poate fi și o pila de unghii, ferăstrău, o pensetă, foarfece, deschizător de sticle și un șurub de plută

În acest caz, trebuie să separați și să vă modulați mai bine codul.

Programatorii compară adesea această problemă cu cererea unei banane, dar primesc o gorilă care deține o banană. Ai ceea ce ai cerut, dar mai mult decât ceea ce ai nevoie.

Principiile SOLID discută în mod explicit acest lucru în limbaje orientate pe obiecte, pentru a ne ajuta să ne modelăm software-ul mai bine (dacă nu știți care sunt principiile SOLID, puteți citi acest articol).

S din acronim înseamnă „Responsabilitate unică” – fiecare clasă / modul / funcție ar trebui să aibă responsabilitate asupra unei părți a sistemului, nu multiple.

Puteți vedea această problemă iar și iar, ce zici de interfața de mai jos?

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

Puteți vedea doar scanând pe scurt această interfață că responsabilitatea acesteia este mult prea largă și are nevoie de refactorizare? Orice implementează acest lucru are potențialul de a fi un obiect al lui Dumnezeu.

Ce zici de asta?


interface Animal {
        numOfLegs: string;
        weight: number;
        sound: string;
        claws: boolean;
}

interface Car {
        engine: string;
        model: string;
}

interface Bird {
        wingspan: string;
}

interface Transaction {
        customerId: string;
}   

Segregarea interfeței vă va păstra codul clar despre responsabilitățile și va înceta să forțeze cursurile care au nevoie doar wingspan pentru a implementa, de asemenea engine, customerId și model și așa mai departe.

Puteți citi mai multe Aici despre Dumnezeu obiectează anti-model.

Concluzie

În orice bază de cod mare există un echilibru constant între gestionarea datoriilor tehnice, pornirea unei noi dezvoltări și gestionarea unei cozi de erori pentru produsul dvs.

Sper că acest articol v-a dat un ochi pentru a observa când ați putea coborî în gaura de iepure a unui anti-model și câteva instrumente pentru a-l rezolva curat.

Îmi împărtășesc scrisul Stare de nervozitate dacă ți-a plăcut acest articol și vrei să vezi mai multe.