Ce faci gresit si cum sa devii un programator mai bun
Stefanescu Mihai 2 years ago Clean CodeCu totii avem obiceiuri proaste de care incercam sa scapam. In acest articol am sa trec in revista o serie de obiceiuri proaste pe care trebuie sa le cunoastem, examinam si corectam cat mai repede.
In viata oricarui programator exista momente cand deschide un proiect, se uita la cod si se gandeste ca cel care a scris codul respectiv era prost sau incepator, dar din experienta mea nu intotdeauna este cazul. Sunt momente cand un programator poate scrie cod groaznic, nu din cauza faptului ca este prost sau incepator, ci si in momentele in care incearca sa gaseasca o scurtatura sau este presat de timp si este nevoit sa gaseasca o scurtatura.
In acest articol am sa vin cu o serie de idei astfel incat sa nu ajungi si tu in aceasta situatie.
Fa-ti un plan inainte de a scrie cod
Inainte de a scrie prima linie de cod, ia-ti cateva minute si gandeste-te cum vrei sa arate si sa functioneze ceea ce trebuie sa faci.
Pornind la lucru cu un plan bine pus la punct vei putea sa iti mentii codul cat mai curat si organizat astfel incat mai tarziu, peste 2 saptamani, 1 luna sau 5 luni cand vei deschide acel cod sa vezi ce se intampla sa intelegi exact ce e acolo si de ce e asa, ca sa nu mai spun ca la fel de mult va ajuta si urmatorul programator ce va deschide acel cod.
O metoda ce pe mine m-a ajutat mult a fost aceea de a incepe cu un fisier, o clasa sau chiar o functie cu comentarii in care am pas cu pas scris ce trebuie sa fac:
<?php
// Include fisierele necesare
// Conecteaza-te la baza de date
// Include markup-ul pentru header
// Defineste variabilele paginii
// Ia-ti datele necesare in baza de date conform variabilelor de mai sus,daca este cazul
// Itereaza prin datele aduse din db
// Formateaza datele ce urmeaza sa fie afisate
// Afiseaza datele
// Include markup-ul din footer
Dupa cum poti observa, fara a scrie macar o linie de cod deja stiu exact cum va arata fisierul meu si ce va face. Ba chiar mai mult, aici am dat ca exemplu o simpla pagina dintr-o aplicatie, dar folosind acest mod putem avea o idee clara cum pot arata clase intregi, ba chiar o intreaga aplicatie.
Nu lasi comentarii
In clipa de fata sunt putin contrariat legat dea cest subiect, dar consider ca de-a lungul timpului m-a ajutat asa ca am sa il trec aici.
Am zis mai sus ca sunt putin contrariat de lasarea comentariilor pentru ca am ajuns la concluzia ca ceea ce scrii trebuie sa fie suficient de simplu de urmarit in cat sa nu fie nevoie sa lasi comentarii, dar am avut o perioada in care lasam comentarii la fiecare functie, ba chiar mai mult la fiecare variabila la care simteam nevoie de a explica ce face.
Sa luam de exemplu, urmatorul cod:
$pieces = explode('.', $image_name);
$extension = array_pop($pieces);
Din ce se poate observa, poate nu este chiar clar ce se intampla in aceasta bucata de cod (am sa vorbesc mai mult despre asta intr-un articol viitor despre nameing).
Acum, poate va intrebati ce e $pieces sau ce e stocat in avriabila $extension
// Iau extensia imaginii
$pieces = explode('.', $image_name);
$extension = array_pop($pieces);
Acum este ceva mai clar.
Sacrificam claritatea pentru rapiditate sau pentru a arata ca stim sa folosim ceva anume
Am sa incep aceasta mica sectiune cu experienta personala in minte, am avut momente cand ma gandeam la tot felul de micro-optimizari cand venea vorba de codul meu, fara sa imi dau seama ca astfel codul meu va deveni mai greu de citit in viitor, iar acele micro-optimizari erau pur si implu inutile. Suntem intr-un punct in care micro-optimizarile aproape nu mai conteaza pentru ca avem atat de multa putere de procesare incat nu trebuie sa ne facem griji daca folosim " sau ', daca concatenam in felul asta 'string' + $variabila sau "string {$variabila}".
Am sa dau un exemplu cat se poate de simplu, dar trebuie sa tii minte ca foarte usor de poate ajunge sa ai cod foarte greu de citit:
$items = [
[
'name' => 'item 1',
'category' => 'cat1',
],
[
'name' => 'item 2',
'category' => 'cat2',
],
[
'name' => 'item 3',
'category' => 'cat1',
],
];
$itemsFromSecondCategory = array_filter($items, function($item){
return $item['category'] == 'cat2';
});
Gandeste-te ce se poate intampla daca pe langa array_filter mai trebuie sa folosim si array_pop, explode, and so on.Daca am avea codul scris asa ne-ar fi mult mai simplu sa citim si sa mai adaugam chestii fara sa il complicam
$items = [
[
'name' => 'item 1',
'category' => 'cat1',
],
[
'name' => 'item 2',
'category' => 'cat2',
],
[
'name' => 'item 3',
'category' => 'cat1',
],
];
$itemsFromSecondCategory = [];
foreach($items as $item){
if ($item['category'] == 'cat2'){
$itemsFromSecondCategory[] = $item;
}
}
Nu urmezi un standard de programare
Alege un standard, si urmeaza-l.
Poate iti scrii o metoda si ti se pare interesant sa formatezi codul intr-un anumit fel, poate iti ti-a venit un nume foarte tare pentru o variabila si vrei sa il folosesti pentru ca ti se pare amuzant (greseli facute de mine: $lord, $needed, $items, $data..din ce observi, nu ai nicio idee ce inseamna aceste variabile, ce date contin sau la ce folosesc).
Cand vine vorba de scris cod, nu trebuie sa ai propriul stil, gandeste-te ca acest cod este exact ca o limba pe care o vorbesti si ceilalti trebuie sa te inteleaga fara probleme, nu sa se chinuie.
Cod duplicat
Arunca o privire la codul scris de tine, gasesti aceasi bucata de cod, identica in mai mult de 2 locuri? Atunci faci ceva gresit, ia bucata respectiva de cod si extrage-o intr-o metoda separata pe care o apelezi din toate locurile in care este necesare.
Nu urmezi un pattern
In orice bucata de cod pe care o scrii trebuie sa ai o structura bine definita.Nu vreau sa spun ca e absolut necesar sa folosesti o structura MVC sau fiecare clasa sa implementeze un anumit tipar, mai de graba spun ca spun ca trebuie sa ai un tipar astfel incat codul sa fie usor de inteles si urmarit, astfel incat daca intru in orice clasa din proiect sa aiba o structura asemeneatoare cu restul de tipul ei si sa inteleg usor ce a vrut sa spuna autorul.
Nu te da destept
Sunt multe momente cand ai de rezolvat o problema, vezi din prima ce-a mai simpla solutie (de suficient de multe ori este si ce-a mai buna), dar totusi te apuci sa complici lucrurile.
Acum am sa iti dau un exemplu destul de interesant, pe care fie ca ma crezi fie ca nu vine dintr-o aplicatie care care era in productie.
Aveam o metoda care facea un api call, isi lua un array de date, le baga in obiecte de tipul stdClass pe care le trimitea catre view, iar acolo le transforma in array pentru a le folosi. Am refactorizat bucata de cod, astfel incat array-ul sa fie trimis catre view, am sters bucata de cod din view care transforma din stdClass in array si codul a functionat fix la fel, dar sincer sa fiu cu voi, nici in zia asta, aproape 4 ani mai tarziu nu stiu ce a vrut sa faca acolo persoana care a scris acel cod.
Nu ramane blocat in timp
Programarea nu functioneaza ca alte domenii de activitate, ci este un domeniu in care trebuie sa inveti in mod continuu si sa incerci cat mai mult sa tii pasul cu evolutia tehnologiei. Cand spun asta nu ma refer neaparat la modul ca trebuie sa inveti absolut fiecare nou framework, fiecare noua librarie ci ma refer mai mult la modul ca trebuie sa inveti si metodolii noi si tehnici diferite.
Vin din nou cu un exemplu din experienta mea, am intalnit oameni carora le ziceam "Uite, ca sa ajung rezultatul asta pot folosi aceasta tehnica si scriind aceste 3 linii si codul va fi usor de citit, inteles si optimi din punct de vedere al performantei" si ma loveam de raspunsuri precum "Cand am invatat eu programare treaba asta o faceam asa ..., deci trebuie sa o facem la fel", chiar daca veneam cu argumente si explicam de ce nu trebuie sa fie facut asa.
Iesi din zona de comfort
Daca nu faci ceva care sa te scoata din zona de comfort, mergi pe drumul gresit. Faptul ca lucrezi la chestii complicate si ca intalnesti probleme noi, probleme cu care nu te-ai mai intalnit ar trebui sa te atraga.
Intreaba-te urmatoarele:
- Exista o tehnologie noua ce poate fi folosita aici?
- Exista un mod mai bun de a rezolva aceasta problema?
- Exista o practica cunoscuta pe care trebuie sa o aplic?
Tine minte, nu ma refer la cresterea complexitati unde nu este cazul.
In cariera mea, am avut multe momente in care m-am trezit intr-o zi si mi-am zis "Am invatat codul asta perfect, nu mai reprezinta un challange pentru mine, trebuie sa merg mai departe."
Nu discuti codul cu alti programatori
Una dintre cele mai bune moduri de a iti imbunatati codul este sa discuti despre el cu alti programatori, fie colegi de munca, prieteni sau pur si simplu oameni de pe net (facebook, reddit, forumuri, etc)
Nu ai proiecte personale
Sunt de parere ca daca vrei sa inveti ceva nou, cel mai bine o faci pe cont propriu. Nu trebuie sa te gadnesti la proiectele personale ca la pierdere de timp, nu trebuie sa te gandesti ca nu are niciun rost faptul ca scrii un cod pe care numai tu il vezi. Eu unul am avut multe proiecte care nu au vazut lumina zilei, am scris aplicatii de desktop, mobile si site-uri pe care numai eu le-am folosit.
Daca te regasesti in lista de mai sus, e momentul sa iti reevaluezi modul de a scrie cod si sa incerci sa devii mai bun. Eu unul, cel putin in primele mele zile de lucru ca si programator, m-am regasit in majoritatea punctelor de mai sus si rand pe rand am incercat sa imi rezolv problemele.
Spor!
