9 moduri de a stăpâni codul îngrozitor, fast

vi s-a dat sarcina de a implementa o nouă caracteristică pe o bază de cod veche, dar codul arată îngrozitor. Cum poți înțelege cât mai repede posibil? Iată câteva comenzi rapide pentru a ajuta la învățarea părților importante ale noului Cod fără a se pierde în detaliile irelevante.

ca programatori, de multe ori trebuie să ne alăturăm proiectelor noi, iar calitatea codului poate fi peste tot. Chiar și cu o echipă organizată, menținerea consecventă a calității codului pe parcursul unui proiect de dimensiuni medii până la mari este o provocare.

de aceea, înțelegerea rapidă a codului slab poate fi o abilitate valoroasă. Te poate ajuta să devii foarte productiv într-un timp scurt și să reduci stresul care vine de obicei cu a fi noul tip și a trebui să joci catch-up. A fi într-o conversație cu un coleg de muncă și a nu ști despre ce vorbește acea persoană jumătate din timp este un sentiment teribil.

pe de altă parte, aceasta este o primă oportunitate pentru a arăta clientului sau șefului dvs. valoarea dvs. și că puteți ajunge rapid la viteză și să-i impresionați. Majoritatea dezvoltatorilor durează săptămâni până la luni pentru a deveni cu adevărat productivi cu o bază de cod pe care nu au construit-o singuri.

Iată cum să stăpânești rapid codul îngrozitor.

cere ajutor. Este cea mai eficientă strategie

alți oameni au învățat deja cum funcționează codul, așa că de ce să nu-i întrebi despre asta? S-ar putea să credeți că vă face să arătați ca un începător, dar manifestarea curiozității poate avea un impact puternic asupra imaginii dvs. ca angajat. Dacă așteptările șefului tău au fost ca tu să devii productiv rapid fără a pune întrebări, aceasta este o judecată greșită din partea ei.

toată lumea are nevoie de timp pentru a ajunge la viteză. Puneți întrebări și veți impresiona oamenii care au atitudinea potrivită pentru munca în echipă.

în multe cazuri, dezvoltatorii originali vor fi luat decizii ciudate sau neașteptate, iar aici vorbirea despre Cod va fi mult mai valoroasă decât citirea acestuia. Acest lucru se întâmplă și mai mult dacă documentația lipsește. Amintiți-vă, dezvoltatorii existenți au cunoștințe valoroase de proiect care nu sunt scrise nicăieri.

faceți o listă de concepte care nu au sens pentru dvs.

ar putea exista concepte de afaceri care sunt noi pentru dvs. sau care sunt prea complexe. Este important să obțineți clarificări despre ele înainte de a încerca să lucrați la codul care gestionează aceste concepte, pentru a evita neînțelegerile care ar putea dura ceva timp pentru a afla.

ar putea fi chiar cazul ca aceste idei să fie etichetate greșit sau reprezentate într-un mod neașteptat într-o bază de date. Așa că evitați să vă stresați să vă înfășurați creierul în jurul acestuia și mergeți la sursă și întrebați-vă colegii despre asta.

în aceeași ordine de idei, pot exista module, clase sau entități care nu au nume adecvate. Notează-le. Elementele slab numite pot duce la o mare confuzie, așa că documentați-le devreme, precum și orice altceva care vă va afecta negativ capacitatea de a vă gândi la modul în care funcționează codul.

face mai ușor de a reproduce bug-uri

prin adăugarea de versiuni de cod și o mașină virtuală, cum ar fi Docker sau Vagrant, va reduce foarte mult timpul necesar pentru a reproduce un bug și pentru a testa munca pe o nouă caracteristică.

orice fel de neînțelegere cu privire la modul în care funcționează codul te-ar putea duce pe o cale de a construi un lucru greșit, fie pentru că ceea ce construiești ar putea fi deja acolo și nu l-ai văzut, fie pentru că lucrurile pur și simplu nu funcționează așa cum ai crezut.

în acest moment, doriți să aveți controlul versiunii Git în proiectul dvs. În acest fel, veți putea să vă întoarceți la o eliberare stabilă sau chiar să lucrați doar pe ramuri separate care pot fi aruncate dacă este necesar.

este chiar posibil să obțineți o reproductibilitate mai mare cu Git, deoarece puteți utiliza stash pentru a adăuga cod de testare sau depanare în timp ce săpați într-o problemă greu de urmărit.

pentru a afla mai multe despre arhitectura proiectului dvs., preluați din timp sarcinile de configurare și documentare.

același lucru se poate spune despre VMs și reproductibilitate. Au devenit omniprezente pentru orice echipă de dezvoltare modernă, dar cu siguranță veți rula în proiecte care nu le folosesc sau chiar sunt gata să ruleze în interiorul unuia. Uneori, primul pas ca nou membru al echipei este să documentați pașii pe care i-ați făcut pentru a obține un mediu de lucru și, în cele din urmă, să transformați acești pași într-un script de configurare VM.

construiți o diagramă a componentelor

o hartă mentală a conceptelor de afaceri, o diagramă entitate-relațională (ERD) a tabelelor bazei de date și o diagramă simplă a componentelor codului pot ajuta foarte mult la reducerea durerii de a înțelege noul cod. Nu-ți amintești cum funcționează ceva? Ține ERD-ul deschis.

de fapt, orice instrument grafic care vă ajută să digerați rapid informațiile și să aveți o vedere de zece mii de picioare a unui proiect va fi valoros. Alte exemple de instrumente care vă pot ajuta există grafice de dependență, jurnale și o hartă a stivei tehnologice a proiectului.

unul dintre cei mai mari consumatori de timp în dezvoltare este punctul de integrare între sisteme. Având o viziune globală asupra peisajului proiectului vă va ajuta să identificați ce puncte de integrare sunt interesante de examinat. Acestea sunt locurile care au cel mai mult de lucru pus în ele, și cele mai multe bug-uri.

pe de altă parte, tehnologia se mișcă rapid și ar putea exista oportunități de a înlocui părți mari ale bazei de cod cu soluții mai moderne și integrate corespunzător. Un cadru vechi ar fi putut dezvolta un mod nou și oficial de a rezolva o problemă sau o bibliotecă complet nouă ar fi putut fi dezvoltată având în vedere o mai bună compatibilitate.

utilizați instrumente de vizualizare și modelare pentru a vizualiza imaginea de ansamblu.

pregătiți-vă pentru testarea automată

înainte de a începe să spargeți lucrurile, este întotdeauna prudent să adăugați teste unitare relevante. Problema cu testarea și Codul slab este că codul slab este de obicei strâns cuplat și greu (dacă nu imposibil) de testat. Nu puteți izola componente care sunt interconectate și indivizibile.

în aceste cazuri, faceți un pas înapoi și testați de la distanță. De obicei, asta înseamnă a face teste de integrare, pentru care există multe instrumente disponibile. Aplicațiile Web pot fi testate împotriva cererilor HTTP, deci este cel puțin posibil să se verifice dacă sistemul va răspunde în același mod la aceleași intrări.

testarea integrării are performanțe mult mai slabe decât testele unitare. Ori de câte ori puteți, implementați teste unitare, astfel încât să puteți avea un feedback mai rapid cu privire la modificările Codului. Dacă acest lucru nu este posibil, atunci optați pentru testarea funcțională sau chiar de integrare.

acest pas ar trebui să arunce o lumină asupra părților codului care au nevoie de lucru. Dacă există o cantitate mare de cod strâns cuplat, aceasta este o țintă bună pentru refactorizare după efectuarea testelor de integrare și apoi pentru testarea unității mai târziu.

identificați strategii de codificare neobișnuite sau inadecvate

este timpul să începeți să faceți unele refactorizări, dar de unde începeți?

de obicei, cel mai bun loc este în cazul în care lucrurile arata ciudat, sau în cazul în care cele mai bune practici de dezvoltare nu au fost urmate. Pentru dezvoltarea web, asta ar putea însemna controlere de grăsime cu cod de model strâns cuplat.

rețineți că aceleași strategii ar putea fi folosite în altă parte. Deci, dacă, de exemplu, identificați că controlerele de grăsime sunt prezente, atunci este probabil ca dezvoltatorii anteriori să nu încerce să aibă controlere subțiri. Vă puteți aștepta să vedeți aceeași problemă și în alte controlere, deoarece aceasta reflecta stilul sau deficiențele procesului de dezvoltare până acum.

la început, lucrați la o sarcină mică

remedierea unei mici erori pe o caracteristică care este conceptual simplă va fi foarte edificatoare și vă va ajuta să vă simțiți productivi de la început.

aceasta este o idee similară cu ceea ce Andy Hunt și Dave Thomas numesc “gloanțe de urmărire” în programatorul Pragmatic. Logica de bază este aceeași: lucrați la ceva end-to-end pentru a vă dovedi că este posibil și apoi îmbunătățiți progresiv acea lucrare inițială.

abordarea “glonțului trasor”. Credit: programatorul Pragmatic

un bun exemplu de îmbunătățire simplă pe care o puteți face este să faceți pași mici de refactorizare cu cod simplu. Identificați o practică comună de programare care nu este urmată și aplicați-o.

unul dintre preferatele mele pentru acest lucru este blocurile condiționale care nu cuibăresc. Deci, în loc să aveți mai multe blocuri if-if-if, unul în interiorul celuilalt, anulați primul și reveniți și faceți același lucru pentru toate verificările de tip validare pe care le puteți găsi. Acest lucru poate fi la fel de simplu ca inversarea unei verificări “dacă” și mutarea unui cod, astfel încât riscul este aproape inexistent, iar codul plat va fi mai ușor de citit.

asigurați-vă că lucrați mai întâi la funcțiile de refactorizare ușor de testat, deoarece, deși modificările sunt cu risc scăzut, este întotdeauna o idee bună să vă puteți valida codul înainte de a-l trimite la producție.

intrați pe un teren familiar înainte de a aborda codul critic

aflați întotdeauna cum este configurat mai întâi proiectul și abia apoi scufundați-vă în partea arhitecturală. Cele mai critice piese de afaceri și Codul de integrare sunt cele mai greu de înțeles și de a modifica. Evitați să intrați în probleme devreme.

ca regulă generală, evitați problemele de afaceri care ar necesita să știți mai multe decât faceți în prezent despre proiect sau despre partea de afaceri. Asta înseamnă, de obicei, să stați departe de tranzacții, plăți sau coduri grele de matematică până când începe să devină un teren familiar.

odată ce sunteți productiv, sunteți confortabil cu stilul de codificare pentru proiect și nu aveți probleme în rezolvarea problemelor simple, este timpul să lucrați la lucrurile mai grele—dar nu înainte.

chiar dacă există o urgență pentru rezolvarea problemelor de plată, de exemplu, acest tip de sarcină poate fi incredibil de riscantă. O greșeală ar putea costa scump proiectul și asta va fi și pe tine. Refuzați absolut să lucrați la sarcini cu risc ridicat din timp, dacă este posibil.

cum să se ocupe cu o stivă Tech necunoscut

pentru ultimul punct, o problemă comună am rula în este că fiecare proiect nou include, de obicei, unele tehnologii care nu sunt familiarizați cu.

când se întâmplă asta, am câteva strategii care mă ajută să mă ridic rapid la viteză. Calea evidentă pentru învățare este citirea documentației și familiarizarea cu noua tehnologie. Dar, în timp ce veți învăța multe despre structură, acea cale nu vă va ajuta să învățați cazurile de colț, care vin de obicei cu experiență. (“Caz de colț” este un termen de inginerie care se referă la o situație care apare în afara parametrilor normali de funcționare.)

o modalitate de a accelera acest proces de a câștiga experiență este de a lua resurse bazate pe întrebări, cum ar fi Stack Overflow și Quora și de a le citi ca o carte. Găsiți cele mai populare întrebări despre biblioteca pe care o învățați și vedeți ce fel de probleme întâmpină de obicei alte persoane. Nu veți intra neapărat în ele, ci doar să știți ce este posibil este ca și cum ați străluci o lumină strălucitoare pe harta mentală a acestor idei noi.

Leverage Stack Overflow întrebări pentru a câștiga experiență rapid. Credit: Stack Overflow

pentru o abordare mai direcționată, găsiți informații despre caracteristicile bibliotecii utilizate în mod specific în noul dvs. proiect. Uită-te în cele care sunt noi pentru tine și să le învețe înainte de timp, înainte de a avea de a atinge acest cod, la toate.

Împărtășește-ți ideile