de Sihui Huang

Când trebuie refactorizat codul moștenit vs. când să vă concentrați asupra proiectului dvs. curent

Cand trebuie refactorizat codul mostenit vs cand sa va concentrati

Când lucrez la proiecte, întâlnesc adesea coduri vechi care pot fi îmbunătățite – pentru a fi mai lizibil, mai testabil sau mai compatibil cu stilul de codare actual. Îndemnul meu de refactorizare a codului este deosebit de puternic după ce am petrecut o bună perioadă de timp încercând să înțeleg o bucată de cod obscur. Codul ăsta mă rănește pe creierși nu vreau să se întâmple același lucru și cu alți dezvoltatori. Există (adaptarea) celebrului Boy Scout Rule: Lăsați codul mai bine decât l-ați găsit.

Dar, în același timp, vreau să rămân concentrat și să fac progrese în proiectele mele actuale. Îmi fac griji că s-ar putea să mă distrag și să petrec prea mult timp refactorizând.

Aceasta este o dilemă cu care mă confrunt deseori. Vreau să fiu bunul samaritean lăsând codul mai bine decât l-am găsit, un inginer transformând tot codul dezordonat pe care îl întâlnesc în ceva curat și elegant. Dar vreau, de asemenea, să rămân pragmatic și să transmit proiecte rapid.

Echilibrarea între refacerea codului vechi pe care o întâlnesc și rămânerea concentrată asupra proiectului meu actual poate fi dificilă.

O conversație recentă cu managerul meu pe această temă mi-a oferit îndrumări pentru a găsi acel echilibru. Iată câteva puncte pe care le consider utile.

ad-banner

Nu trebuie să faceți codul perfect. Mici îmbunătățiri sunt încă utile.

După ce am citit o bucată de cod vechi, creierul meu se gândește imediat la modul în care ar trebui să fie în mod ideal. Dar refactorizarea codului de la starea sa actuală la starea ideală necesită uneori o refactorizare extinsă. În cel mai bun caz, refactorizarea necesară poate necesita mult timp. În cel mai rău caz, se poate transforma într-o gaură de iepure care provoacă o întârziere mare în proiect.

Când mă confrunt cu astfel de cazuri, obișnuiam fie să-mi iau o șansă, fie să refac refacerea extensivă oricum, fie să mă țin de nas și să las codul să rămână puturos. Acum îmi dau seama că există un punct de mijloc fericit: Nu am codul perfect. Îmi pot petrece cât mai mult sau cât de puțin timp îmi permit să îmbunătățesc codul.

Micile îmbunătățiri pe care le fac pot fi încă utile pentru dezvoltatorii care vor urma. Și acei dezvoltatori ar putea avea timp să îmbunătățească în continuare codul, bazându-se pe îmbunătățirile pe care le fac.

(PS: Nu există nici un cod perfect, nici ideal. În momentul în care efectuați o modificare, vedeți mai multe îmbunătățiri pe care le puteți face.)

Cronometrează-ți refacerea.

Time-boxul este o tehnică excelentă pentru a evita găurile de iepure. Înainte de a începe refactorizarea, efectuați o estimare rapidă despre cât de mult timp puteți petrece pe refactorizarea codului vechi, fără a întârzia prea mult proiectul. Scrieți numărul respectiv.

Time-boxul refactorizării vă oferă liniștea sufletească știind că proiectul principal va rămâne pe drumul cel bun. Și asta face ca experiența de refactorizare să fie mai plăcută.

Coaceți timpul de refactorizare în estimarea proiectului.

Lucrurile pot fi și mai ușoare dacă încorporați timpul de refactorizare în estimarea proiectului înainte de a începe un proiect. În timp ce estimați cât timp ar putea dura un proiect, aruncați o privire rapidă asupra codului pe care trebuie să îl atingeți: când a fost scris prima dată? Cât de citibil și extensibil este? Cât de mult acoperă testul? Cu excepția cazului în care există o cerință grea cu privire la momentul în care proiectul trebuie livrat, ar trebui să includeți un timp de refactorizare în cronologia proiectului.

Dupa toate acestea, pe măsură ce continuăm să construim pe o bază de cod moștenită, refacerea acesteia pe măsură ce mergem este cel mai bun mod de a-l menține sănătos. Și o bază de cod sănătoasă, la rândul său, face ca construirea de noi funcții să fie mai rapidă și mai sigură.

Refactorizarea este educativă.

Refactorizarea unei bucăți de cod este cel mai bun mod de a o înțelege. În comparație cu a rămâne departe și a citi doar o bucată de cod, intrarea și modificarea acesteia vă oferă o relație mult mai profundă și intimă cu codul.

Când încercați să adăugați atingerea la cod, veți începe să observați lucruri pe care le-ați pierdut înainte. Este posibil să vedeți constrângerile și chiar să înțelegeți de ce autorul a scris inițial codul în acest fel.

Deși refacerea unei bucăți de cod nu pare să adauge o valoare imediată afacerii, este o oportunitate pentru dvs. de a obține o bucată de cunoștințe de domeniu pe care nu le aveți în prezent. Obținerea cunoștințelor de domeniu este de neprețuit atât pentru dvs., cât și pentru companie.

Refactorizarea este un mușchi pe care îl puteți construi

Cu cât o faci mai mult, cu atât devii mai repede. Un ultim motiv pentru refactorizarea codului vechi este acela de a-l folosi ca o oportunitate de a vă întări „mușchiul refactorizator”. Investiția în construirea „mușchiului refactorizator” are un efect compus auto-întăritor: cu cât refactorizați mai mult, cu atât sunteți mai bine la refactorizare, făcând următoarea refactorizare mai rapidă. Cu cât o faceți mai mult, cu atât este mai bună baza de cod, ceea ce face ca construirea funcțiilor viitoare să fie mai rapidă.

Din fericire, următorul meu proiect se referă la codul de acum aproape trei ani. Mă aștept să mă confrunt cu multe cazuri care să mă oblige să echilibrez între refacerea codului vechi și progresul în proiect. Voi împărtăși noile mele învățări blogul meu personal (NU mediu). Abonați-vă pentru a continua!

Planul meu de carieră pentru acest an este să devin un lider tehnologic. Sunt încântat de toate învățăturile viitoare și mi-ar plăcea să vă împărtășesc această călătorie într-un mod brutal și onest. Îmi voi împărtăși învățăturile săptămânale pe blog personal (NU mediu).

În următoarele câteva luni, mă voi concentra pe creșterea în următoarele domenii, astfel încât vă puteți aștepta să vedeți postări legate de acestea:

  • concentrându-se pe imaginea de ansamblu a proiectului în loc de detalii de implementare pe termen scurt;
  • echilibrarea eforturilor mele între proiecte de conducere și codare;
  • echilibrul dintre viața profesională și cea profesională pe termen lung;
  • latura umană a dezvoltării de software: asigurându-mă că toată lumea care călărește cu mine se bucură de plimbare și se simte împlinită și inspirată.

Publicat inițial la www.sihui.io pe 1 februarie 2019.