moștenirile nu mor niciodată: cum să gestionezi Codul moștenit

când apare termenul „Cod moștenit”, acesta este de obicei spus sau primit cu o tentă de dispreț. O căutare preliminară pe Google pentru „meme de cod vechi” aduce sute și sute de macro-uri de imagine ale oamenilor care își sfâșie părul, se uită amețit sau extrem de dezamăgit.

când am început să lucrez ca dezvoltator de software 6 luni în urmă, am avut nici o idee ce Cod legacy a fost sau ceea ce a implicat de lucru cu ea.în timpul celei de-a patra luni ca dezvoltator junior, mi s-a cerut să adaug un modal de filtrare a căutării la o aplicație construită de unul dintre colegii mei acum doi sau trei ani. Mi s-a părut destul de ușor; mi-am petrecut majoritatea ultimelor patru luni lucrând la o aplicație incredibil de complexă pentru un alt client care implică stiva noastră standard: TypeScript/React/Redux/Redux-Saga. Am rezolvat deja multe probleme unice și m-am simțit încrezător în capacitatea mea de codificare suficient pentru a face un modal simplu pentru a trece parametrii de interogare în backend.

după cum probabil ați ghicit, nu a fost aproape atât de simplu. Dar de ce?

ce este codul vechi și de ce poate fi dificil să se ocupe de

codul vechi este codul moștenit de la un alt dezvoltator sau echipă care utilizează tehnologii mai vechi care nu mai sunt acceptate sau au fost înlocuite de o versiune mai nouă. Mulți programatori spun că „codul devine cod vechi de îndată ce este scris”. Diferența funcțională dintre codul” obișnuit ” și Codul vechi ar putea fi pur și simplu că are convenții diferite în comparație cu ceea ce sunteți obișnuit să lucrați.

în cazul meu, aplicația am fost atribuit utilizat flux, mai degrabă decât TypeScript, și nu a fost la fel de puternic tastat ca am fost obișnuit să. Acest lucru a făcut un pic mai greu pentru mine să înțeleg structura datelor care au fost preluate din backend. Niciun tip nu însemna că mă confruntam cu TypeErrors în timpul rulării mult mai frecvent, ceea ce poate fi dificil de depanat atunci când scrieți o caracteristică mare. În plus, aplicația a folosit o versiune mult mai veche a React, care trebuia reconciliată cu o versiune compatibilă a bibliotecii de componente pe care am vrut să o folosesc pentru a construi Modalul.

înainte de a intra în nitty-curajos de cum să se ocupe de codul legacy cu un sentiment de echilibru și raționalitate, vreau să adaug un disclaimer că legacy code nu este tot rău și de lucru pe un proiect legacy nu trebuie să fie teribil. Dimpotrivă, lucrul la legacy code m-a învățat să fiu flexibil, răbdător și, mai presus de toate, experiența mi-a permis șansa de a rezolva problemele cu o nouă perspectivă într-un context nou.

de fapt, m-a făcut un dezvoltator mai bun decât eram înainte de a începe să lucrez prin baza de cod menționată mai sus și, sperăm, proiectul tău legacy te poate învăța și tu ceva.

cum să se ocupe cu codul legacy la nivel tehnic

fotografie de Jeff Sheldon pe Unsplash

citiți documentația și comentariile codului atunci când este posibil

într-o lume perfectă, fiecare bază de cod are un README robust care conține explicații concise despre modul în care funcționează Proiectul, comentarii de cod care explică logica exactă a autorului original și întreaga aplicație are sens perfect. Cu toate acestea, acest lucru este rareori cazul. Multe READMEs nu se actualizează pe măsură ce proiectele se dezvoltă, oamenii uită să scrie comentarii, presupun că logica lor este evidentă pentru un nou dezvoltator sau pur și simplu rămân fără timp pentru a avea grijă de aceste lucruri.

Uită-te la codebase ca un întreg

dacă sunteți pierdut și nu știu de unde să încep, întrebați-vă aceste întrebări:

• care este scopul aplicației?
• cum curge datele prin aplicație?
• cum se încadrează funcția dvs. în aplicație?

când puteți obține un sentiment de imagine de ansamblu, este mai ușor să dau seama cum cel mai bine pentru a aborda problema. Poate că trebuie să creați un fișier nou și să creați o componentă nouă. Poate că trebuie să scrieți o funcție de utilitate și să o testați. Oricare ar fi cazul, înțelegerea contextului mai larg al problemei dvs. este un prim pas bun pentru crearea unei soluții.

testați aplicația manual și cu teste unitare ori de câte ori este posibil

ruperea temporară a unei aplicații în timp ce adăugați o caracteristică nouă este o inevitabilitate, indiferent de nivelul de dezvoltator pe care îl aveți. Acest lucru este normal și de așteptat, mai ales dacă sunteți nou la locul de muncă, lucrați într-o bază de cod veche cu o stivă necunoscută sau o combinație a celor două.

cel mai bun mod de a preveni aceste rupturi de a deveni probleme pe termen lung este de a testa aplicația bine cu ambele teste unitare și teste manuale. Având aceste teste la locul lor și știind exact ce fel de acoperire veți ieși din ele, veți economisi mult timp dvs. și viitorilor Dezvoltatori. În plus, testele riguroase fac aplicația mai scalabilă și, de asemenea, vă oferă o grabă de dopamină litte de fiecare dată când testele dvs. sunt curate.

pentru testarea unității, puteți utiliza cadre de testare precum Jest sau Jasmine.

pentru testele manuale, veți dori să dezvoltați o matrice de testare și să vă asigurați că documentul este accesibil viitorilor Dezvoltatori. Pentru matrice, veți dori să definiți un set de acțiuni, comportamentul așteptat, comportamentul real atunci când îl testați și orice alte detalii importante, cum ar fi:

voi acoperi modul de implementare eficientă a ambelor tipuri de testare în fluxul dvs. de lucru într-o viitoare postare pe blog.

cereți ajutor

presupunând că proiectul dvs. a fost scris de un angajat actual sau fost la locul de muncă, altcineva probabil știe ce se întâmplă în aplicație sau cel puțin știe suficient pentru a vă dezlipi. A învăța să-ți înghiți mândria și să întrebi pe altcineva este un un pas incomod pentru unii, dar unul necesar pentru a crește ca dezvoltator și poate colegul tău te poate învăța câteva trucuri noi.o modalitate buna de a utiliza eficient timpul tau (si al lor) este de a formula Intrebari informate. Încercați să reveniți la căutarea bazei de cod în ansamblu și să descoperiți lacunele din înțelegerea dvs. Nu numai că îi va ajuta să înțeleagă mai bine care este problema dvs., dar arată că ați luat inițiativa de a încerca mai întâi să rezolvați problema pe cont propriu.

știți când să vă reduceți pierderile

dacă petreceți prea mult timp încercând să vă puneți piciorul în ușă și nu ați făcut niciun pas serios spre implementarea funcției după ce ați încercat pașii de mai sus, ar putea merita să refactorizați codul în jurul funcției. Nu renunțați prea ușor, dar rețineți și care sunt termenele limită și ce așteaptă managerul de proiect de la dvs.

acestea fiind spuse, există dezavantaje în a merge în acest fel:

• rescrierea codului poate introduce erori, deși acest lucru poate fi oarecum eludat cu o testare unitară bună.
• rescrierea codului poate elimina funcționalitatea ascunsă, deși acest lucru poate fi eludat și cu teste unitare bune.
• dacă sunteți presat de timp, scrierea de cod în afara funcției dvs., în plus față de caracteristica dvs., ar putea fi de fapt mai consumatoare de timp decât construirea în jurul acesteia.

în general, folosește-ți cea mai bună judecată. Există argumente pro și contra pentru fiecare alegere și totul depinde de circumstanțele dvs. individuale și de bugetul proiectului.

cum să se ocupe de codul legacy la nivel psihologic

fotografie de Simon Migaj pe Unsplash

acum, că am acoperit aspectele tehnice ale tratării codului legacy, să vorbim despre cum să ne ocupăm de el folosind abilitățile noastre soft. La urma urmei, dezvoltatorii sunt oameni, nu doar roboți de codificare, și care se ocupă cu probleme provocatoare pe proiecte care necesită creativitate și autor poate fi emoțional de impozitare, nu numai pentru tine, dar pentru colegii de muncă, precum și.

Fii umil și amabil

acesta este un lucru pe care voi recunoaște că trebuie să-l practic mai mult. Când am fost atribuit primul proiect modal filtru, am fost destul de vocal cu privire la modul janky și neatrăgătoare codul a fost de a face cu în timp ce autorul original al Codului a fost așezat 15 metri distanță de mine. Am intenționat comentariile mele să fie o glumă, dar în retrospectivă recunosc că am fost arogant și jignitor, și că ar fi trebuit să fiu mai empatic.

există o mulțime de factori care pot duce la codul de moștenire în căutarea „off”, care ar trebui să ia în considerare înainte de a începe să critice autorul sau să își asume cel mai rău despre ei (acest lucru este vag legat de eroarea de atribuire fundamentală!).

este posibil ca autorul original să fi avut motivele lor pentru a scrie codul așa cum au făcut-o.

constrângerile de timp și constrângerile tehnologice pot determina o persoană să scrie cod care funcționează, dar nu are neapărat cea mai bună convenție. Dacă vă imaginați-vă într-o situație cu nu suficient timp, instrumente învechite, și o listă todo o milă lungă, probabil că nu ar scrie cel mai bun Cod, fie!

convențiile se schimbă.

în proiectele Olio Apps mai vechi, Convenția pentru cod folosește ghilimele simple pentru a declara șiruri, iar două spații erau egale cu o filă. Am avut mai multe componente mici React imbricate în interiorul unui singur fișier. În convenția noastră actuală, folosim ghilimele duble și patru spații și fiecare componentă React, oricât de mică, trăiește în propriul său fișier .tsx din Directorul component. Și peste câțiva ani, sunt sigur că și asta se va schimba.

tot codul devine în cele din urmă legacy

acest lucru se leagă înapoi la punctul anterior: codul dvs. va fi în cele din urmă legacy. Pe măsură ce vă deplasați pe scara vechimii, noii dezvoltatori vor fi angajați și vor trebui să vă mențină vechiul cod. S-ar putea să scrieți un cod curat, fără cusur, uscat, dar odată ce convențiile se schimbă sau tendințele se schimbă, acei noi dezvoltatori ar putea vizualiza codul dvs. în același mod în care vizualizați codul vechi al altora.

fii mândru de micile succese

nu este ușor să lucrezi în afara convențiilor tale obișnuite; există un motiv pentru imensul tezaur de meme și glume despre tratarea codului moștenit. Dacă ați învățat vreodată o limbă în afara limbii materne, știți cum se simte să uitați un cuvânt sau un termen în a doua limbă, dar amintiți-vă în limba maternă și să nu puteți traduce peste decalaj. Același lucru este valabil și pentru schimbarea convențiilor moderne și moștenite. Uneori durează doar un minut pentru a-ți recâștiga rulmenții.

pentru a putea naviga cu succes în codul vechi, vă arătați capacitatea de a fi adaptabil, ceea ce este o abilitate importantă care vă avantajează la locul de muncă actual și la toate locurile de muncă viitoare, indiferent dacă aceste locuri de muncă sunt în domeniul tehnologiei sau nu. Legacy code este locul de joacă perfect pentru a practica această abilitate.

în concluzie:

folosiți acest timp pentru a vă susține propria scriere de cod

acum, că ați avut experiența de a lucra într-o bază de cod moștenită, ar trebui să vă îndepărtați de ea cu o mai bună înțelegere a ceea ce vă place și nu vă place în ceea ce privește instrumentele și convențiile. Acestea sunt lucruri pe care le puteți continua în proiectele viitoare și vă pot face mai bine să revizuiți codul altora, să oferiți critici constructive și să oferiți mentorat.

dezvoltați aplicații pentru utilizator și viitorul Dezvoltator

indiferent dacă ați avut experiența documentației excelente și a comentariilor de cod sau nu aveți documentație sau comentarii de cod, puteți vedea cum atât documentația, cât și comentariile sunt instrumente puternice pentru a ajuta viitorii Dezvoltatori să navigheze în proiect. Împărtășiți un obiectiv comun de a dori o aplicație lină, funcțională și uscată; menținerea documentației și lăsarea în urmă a comentariilor informative ale codului este o modalitate bună de a reduce acest decalaj.

amintiți-vă că codul dvs. va fi legacy într-o zi prea

am menționat acest lucru de câteva ori deja, dar este important să reiterăm că codul dvs. va fi și legacy, indiferent cât de uscat și curat este codul și logica dvs.

cel mai important este să fii flexibil, umil și că poți învăța cu siguranță trucuri noi din Codul vechi.