Există o mare de informații despre modul de scriere a codului sursă al programelor. În acest text veți găsi câteva sfaturi despre cum să îl ștergeți.
Această metodă poate părea evidentă, dar cred că acest lucru nu este cazul, deoarece dezvoltatorii folosesc multe alte modalități pentru a face acest lucru. Iată cum să ștergeți codul sursă:
Cei mai mulți dezvoltatori nu le place să facă acest lucru. Ei preferă să lase biți și bucăți de cod vechi oriunde, doar pentru că - din nou va fi nevoie din nou. Ei au muncit din greu și lung pentru a scrie acest cod. L-au depanat, și a funcționat. Și pentru că dezvoltatorii nu vor să scoată și să arunce vechiul cod.
Pentru astfel de dezvoltatori voi spune: "Folosiți sursa (controlul), Luke" [1]. Utilizarea sistemelor de control al versiunilor (cum ar fi CVS, Perforce sau Subversion) înseamnă că nu va trebui niciodată să vă faceți griji cu privire la lucrarea o dată făcută care poate dispărea pentru totdeauna. Vechiul cod vechi va fi în CVS, gata de reutilizare la prima cerere.
Dacă nu aveți un sistem de control al versiunilor (.) Sau pur și simplu nu aveți abilitatea de a sapa în revizuiri vechi, copiați bucata de cod într-un fișier separat și salvați-l într-o locație separată. Dar nu lăsați-l acolo unde nu aparține - în textul sursă.
Dacă aveți o bucată de cod pe care nu o aveți deja, atunci există un motiv bun pentru ao elimina, în loc să o lăsați într-o stare oprită: pentru a reduce confuzia și incertitudinea. Unii dintre cei mai răi dușmani ai dezvoltatorului sunt confuzia sau locurile incomprehensibile din codul său, deoarece acestea vor interfera și vor reduce eficacitatea lucrărilor ulterioare.
Partea cu handicap a codului generează direct o incertitudine. În mintea altor dezvoltatori, el ridică întrebări:
- De ce ați folosit o altă versiune a codului înainte?
- Care este noua implementare mai bună?
- Ar trebui să ne întoarcem la versiunea veche?
- În ce cazuri va trebui făcută?
// OldWayStepOne (fooey);
// OldWayStepTwo (gooey);
NewWay (fooey, gooey);
Dezvoltatorii viitori, după ce se uită la acest cod, vor vedea că vechea versiune a OldWay a fost folosită o dată, vor vedea de asemenea că noua versiune de NewWay funcționează acum, dar nu vor ști de ce vechea versiune a OldWay este lăsată lângă:
- Poate noua versiune a NewWay este doar un experiment? Dacă da, atunci ce este mai bun decât cel vechi? Cum și când ar trebui să se ia decizia finală: să o părăsești sau să te întorci la cea veche?
- Poate că versiunea veche este mai bună, dar cu ea ceva nu funcționează bine? Dacă da, ce anume este greșit? Iar motivul pentru aceste neînțelegeri constă în codul OldWay însuși sau în modul în care se numește acest cod? Când aceste neînțelegeri vor fi eliminate?
- Poate că proiectul sa schimbat, iar vechea versiune a lui OldWay nu funcționează în mod inutil?
Nu este mai bine să faci asta?
// OldWay a lucrat mai bine, dar prea ineficient și atâta timp cât
// nu va fi refăcut MumbleFrabbitz, vom folosi
// NewWay înainte de pasul M4.
// OldWayStepOne (fooey);
// OldWayStepTwo (gooey);
NewWay (fooey, gooey);
Cine poate spune astăzi, va fi MumbleFrabbitz realmente reproiectat pentru faza M4? Poate nu se va întâmpla. Acest lucru este normal; cine știe ce ne pregătește viitorul? Cel puțin această opțiune va ajuta dezvoltatorii să înțeleagă de ce codul vechi este lăsat unul lângă celălalt. Având informații cu privire la motivele pentru care au fost făcute schimbări și de ce vechiul cod este încă lăsat aici, dezvoltatorii vor putea să înțeleagă când vor putea trece în cele din urmă la o nouă versiune NewWay sau când vor reveni la o soluție mai bună.
#if 0
OldWayStepOne (fooey);
.
OldWayStepTwenty (hooey);
# endif
Pentru Python:
dacă 0:
OldWayStepOne (fooey)
.
OldWayStepTwenty (hooey)
Nu dezactivați codul cu directive compilaționale condiționate, fără a explica de ce.
Dacă trebuie să utilizați preprocesorul C pentru a elimina codul, atunci "# 0" va fi cea mai bună opțiune, deoarece cel puțin arată clar că acest cod nu ar trebui să fie niciodată compilat.
Printre sursele pentru programul Lotus Notes conținea o mulțime de fragmente de cod, folosind directivele deconectat „# ifdef Later“, bazat pe ipoteza (corect) că simbolul Preprocessor „Later“ este definit nicăieri. Această opțiune este o formă foarte slabă de documentare; arată că codul nu este încă pregătit pentru compilare, dar va fi gata mai târziu. Dar când? Printre dezvoltatori a fost o glumă despre necesitatea de a defini simbolul "LATER" și a vedea ce va veni din el!
Dacă utilizați simboluri nedefinite pentru a șterge codul, lăsați-l neclar în mintea dezvoltatorilor: ce înseamnă acest simbol. Poate că aceasta este configurația codului, numită "LATER", iar în acest caz, această opțiune va trebui luată în considerare.
Să presupunem că aveți o clasă excelentă care are o mulțime de metode. Într-o zi, descoperiți că nu mai este chemată o anumită metodă. Îl veți lăsa sau îl veți șterge?
În acest caz, nu există un răspuns simplu la această întrebare, deoarece depinde de clasă și de metodă. Răspunsul depinde de presupunerea că această metodă poate fi necesară din nou în viitor. Răspuns dur ar putea fi aceasta: În cazul în care această clasă este o parte a cadrului, apoi se lasă, dar dacă el este parte a cererii, se șterge. (Intenționez să scriu un articol separat despre diferențele dintre cadre și aplicații).
// (Aici a fost utilizat un alt algoritm care a utilizat hash
// și a lucrat mai repede, dar a avut probleme cu sincronizarea. Dacă el
// aveți nevoie de el, atunci este în revizuirea 1.16 sau mai devreme în fișierul ThingMap.java în CVS.)
Un simplu acord ca acesta:
De asemenea, puteți utiliza această abordare pentru secțiuni mari de cod:
#if 0 // Cred că nu este necesar dacă utilizați FooBar
OldWayStepOne (fooey);
.
OldWayStepTwenty (hooey);
# endif
Atunci când eliminați codul inutil, este probabil ca stubs phantom din versiunea anterioară să rămână. Încercați cât mai mult posibil să puneți totul în ordine. De exemplu, dacă ștergeți un apel OldWay în următorul cod:
Este tentant să lăsăm un astfel de cod însoțitor, deoarece este greu de înțeles dacă este sau nu necesar. Dar dacă lăsați acest bloc condițional gol, atunci un alt programator care o însoțește o să se poticnească într-o zi cu privire la acest cod, să se uite la el și să înțeleagă că există ceva în neregulă aici. Și va trebui să exploreze totul până la capăt. Și pentru a înțelege scopul unui bloc condițional gol, îi va lua mult mai mult timp decât să îl eliminați.
Acționați puternic și ștergeți codul vechi. Nu-i vei pierde.
- Cale de coduri eronate goale. despre erori la programarea codului de securitate.
- Corelați mai întâi erorile. pe cât de important este faptul că managerul de eroare funcționează întotdeauna cel mai bine.
- Blogul meu. care discută alte probleme similare
Articole similare
Trimiteți-le prietenilor: