Prefața traducătorului: După ce ai citit acest articol, s-ar putea să fii surprins sau chiar supărat. Da, am fost și noi surprinși: autorul se presupune că nu auzise niciodată despre ierarhia în echipă, despre stabilirea sarcinilor cu statutul „fă-o repede și fără raționament”. Da, așa e, acesta este un text puțin ciudat. Într-adevăr, autorul sugerează ca programatorul să-și asume rolul unui arhitect de sistem - atunci de ce ai nevoie de un arhitect? Dar toate aceste obiecții nu ar trebui să vă orbească față de principalul lucru - de ce totuși am luat și tradus acest text. El nu vorbește despre roluri. Acest text este despre o abordare și conștientizare profesională. Adevărul este că atâta timp cât „fă ceea ce ți se spune” fără să te gândești la semnificația acțiunilor tale, nu vei deveni niciodată un programator grozav.
Spune nu codului inutil. Tot ce trebuie să faci este să pui trei litere împreună și să spui cuvântul. Să încercăm să facem asta împreună: "Nuuuu!"
Dar asteapta. De ce facem asta? La urma urmei, sarcina principală a unui programator este să scrie cod. Dar trebuie să scrieți vreun cod care vi se cere? Nu! „Înțelegerea când nu trebuie să scrie cod este probabil cea mai importantă abilitate pentru un programator.” .
Amintim: pentru toți cititorii „Habr” - o reducere de 10 de ruble la înscrierea la orice curs Skillbox folosind codul promoțional „Habr”.
Skillbox recomandă: Curs practic .
Programarea este arta de a rezolva probleme. Și voi sunteți maeștri în această artă.
Uneori, în efortul de a începe munca cât mai repede posibil, nu ne gândim la nimic altceva decât la finalizarea sarcinii pe care o avem. Și acest lucru poate cauza probleme și mai grave.
La ce închid programatorii ochii?
Tot codul pe care îl scrieți trebuie să fie înțeles de alți dezvoltatori și trebuie testat și depanat.
Dar există o problemă: orice ai scrie, îți va complica software-ul și probabil va introduce erori în viitor.
Potrivit lui Rich Skrent, . Iată ce scrie el:
„Codul este rău pentru că începe să putrezească și necesită întreținere constantă. Adăugarea de noi funcții necesită adesea modificarea codului vechi. Cu cât este mai mare, cu atât este mai mare probabilitatea de apariție a unei erori și cu atât este nevoie de mai mult timp pentru compilare. Este nevoie de un alt dezvoltator mai mult timp pentru a-și da seama. Și dacă este nevoie de refactorizare, atunci cu siguranță vor exista fragmente care merită schimbate. Codul mare înseamnă adesea flexibilitate și funcționalitate reduse a proiectului. O soluție simplă și elegantă este mai rapidă decât un cod complex.”
De unde știi când să nu scrii cod?
Problema este că programatorii exagerează adesea numărul de funcții de care are nevoie aplicația lor. Ca urmare, multe secțiuni de cod rămân neterminate sau nimeni nu le folosește, dar complică aplicația.
Trebuie să înțelegeți clar de ce are nevoie proiectul dvs. și ce nu.
Un exemplu este o aplicație care rezolvă o singură sarcină - gestionarea e-mailului. În acest scop, au fost introduse două funcții - trimiterea și primirea scrisorilor. Nu ar trebui să vă așteptați ca managerul de e-mail să devină un manager de activități în același timp.
Trebuie să spuneți ferm „nu” propunerilor pentru a adăuga funcții care nu au legătură cu sarcina principală a aplicației. Acesta este exact momentul în care devine clar că nu este nevoie de cod suplimentar.
Nu pierdeți niciodată focalizarea aplicației dvs.
Întrebați-vă întotdeauna:
— Ce funcție ar trebui implementată acum?
— Ce cod ar trebui să scriu?
Întrebați ideile care vă vin în minte și evaluați sugestiile venite din exterior. În caz contrar, codul suplimentar poate ucide pur și simplu proiectul.
Știind când să nu adăugați lucruri inutile, vă va ajuta să vă mențineți baza de cod sub control ferm.
La începutul căii, programatorul are doar două sau trei fișiere sursă. E simplu. Compilarea și lansarea aplicației necesită un timp minim; Este întotdeauna clar unde și ce să cauți.
Pe măsură ce aplicația se extinde, apar tot mai multe fișiere de cod. Ei umplu catalogul, fiecare cu sute de rânduri. Pentru a organiza corect toate acestea, va trebui să creați directoare suplimentare. În același timp, amintirea ce funcții sunt responsabile pentru ce și ce acțiuni le provoacă devine din ce în ce mai dificilă; prinderea insectelor necesită, de asemenea, mai mult timp. Managementul proiectelor devine, de asemenea, din ce în ce mai complex; nu unul, ci mai mulți dezvoltatori trebuie să țină evidența tuturor. În consecință, costurile, atât monetare, cât și de timp, cresc, iar procesul de dezvoltare încetinește.
Proiectul devine în cele din urmă uriaș, iar adăugarea fiecărei funcții noi necesită tot mai mult efort. Chiar și pentru ceva foarte nesemnificativ trebuie să petreci câteva ore. Corectarea erorilor existente duce la apariția altora noi, iar termenele limită de lansare a aplicațiilor sunt ratate.
Acum trebuie să luptăm pentru viața proiectului. De ce?
Faptul este că pur și simplu nu ați înțeles când nu ar trebui să adăugați cod suplimentar și ați răspuns „da” la fiecare sugestie și idee. Erai orb, dorința de a crea lucruri noi te făcea să ignori fapte importante.
Sună ca un scenariu de film de groază, nu?
Este exact ceea ce se va întâmpla dacă tot spui da. Încercați să înțelegeți când nu trebuie adăugat codul. Eliminați lucrurile inutile din proiect - acest lucru vă va face viața mult mai ușoară și va prelungi durata de viață a aplicației.
„Una dintre cele mai productive zile ale mele a fost când am șters 1000 de linii de cod.”
— Ken Thompson.
Este dificil să înveți când să nu scrii cod. Dar este necesar.
Da, știu că tocmai v-ați îmbarcat pe calea unui dezvoltator și doriți să scrieți cod. E bine, nu pierde acea prima impresie, dar nu pierde din vedere factorii importanți din cauza entuziasmului. Am realizat totul prin încercări și erori. De asemenea, vei face greșeli și vei învăța din ele. Dar dacă poți învăța din cele de mai sus, munca ta va deveni mai conștientă.
Continuați să creați, dar știți când să spuneți nu.
Skillbox recomandă:
- Curs aplicat online .
- Curs online .
- Curs practic anual .
Sursa: www.habr.com