Top 5 erori de programare in Java
Top 5 erori de programare in Java
Toata lumea greseste. Chiar si programatori foarte competenti. Uneori acest lucru se intampla din neatentie sau un API neclar. Insa acest gen de greseli sunt rare. Cele mai comune greseli de programare sunt cauzate de cunostinte insuficiente sau abilitati care nu sunt suficient dezvoltate.
12 Apr 2016
3492
Other articles
Object-relational Mapping folosind JPA, Hibernate si Spring Data JPA. Persistence cu JPA
Cum sa interogam Kafka Streaming Data?
Procrastinarea. Care sunt avantajele ei?
Object-relational Mapping folosind JPA, Hibernate si Spring Data JPA
Procrastinarea
Cerinte. De ce avem nevoie de ele?
Dezvolta-ti abilitatile cu training-urile noastre
Programarea reactiva Java. Implementari
Testarea software. Intrebari tipice si raspunsuri. Continuare
Testarea software. Intrebari tipice si raspunsuri
Toata lumea greseste. Chiar si programatori foarte competenti. Uneori acest lucru se intampla din neatentie sau un API neclar. Insa acest gen de greseli sunt rare. Cele mai comune greseli de programare sunt cauzate de cunostinte insuficiente sau abilitati care nu sunt suficient dezvoltate.
In acest articol voi discuta despre cele mai comune greseli de programare pe care le-am intalnit in cariera mea. Sper ca experientele mele sa va ajute sa reduceti numarul de buguri in proiectele voastre.
Prima eroare despre care vreau sa vorbesc este modul in care sunt denumite elementele de cod. Fiecare variabila, metoda, clasa sau pachet ar trebui sa aiba un nume clar care sa arate rolul ei. Cum putem sa verificam asta? Poti sa te uiti peste un cod pe care l-ai scris acum 6 luni si pe care nu l-ai mai verificat. Poti sa iti amintesti ce face fiecare element din cod?
Un nume sau identificator eficient este usor de facut. Foloseste aceleasi cuvinte pe care le-ai folosi ca sa descrii elementul de cod. Spre exemplu:
Cat de repede iti dai seama ce face aceasta bucata de cod? Poti sa o folosesti? Cum ar trebui sa il implementezi? Raspunsul la aceste intrebari nu are cum sa apara daca nu cunosti autorul codului. Insa toate aceste intrebari dispar daca scrii codul asa:
Cea de-a doua eroare comuna consta in nerespectarea unuia dintre principiile OOP – incapsularea. Nu trebuie niciodata sa accesezi atributele altor obiecte – direct sau indirect. Singura exceptie pentru aceasta regula este prezentarea datelor pentru layerul UI sau trimiterea catre layer-ul DAO. Spre exemplu:
Chiar daca apelam getters si nu accesam campurile din clasa User, nu respectam procesul de incapsulare. Nu trebuie niciodata sa poti sa vezi prezentarea datelor interne din alte clase. In schimb ar trebui sa stii ce operatiuni ofera aceasta clasa si cum sa o folosesti.
Cea de-a treia eroare este lipsa sigurantei codului tau. Sa ne uitam la exemplul de mai jos:
Ati scris un simplu cod de formatare a procentajelor. Este sigur? Da, nu da nici o exceptie ca rezultat. Ce facem insa daca cineva tasteaza -1, spre exemplu. Aceasta metoda produce un rezultat invalid. Ce ar fi daca am modifica astfel codul?
Nu va produce niciodata un rezultat invalid. Insa pur si simplu ascundem o eroare. Faptul ca avem un parametru invalid este semnul unei alte erori de programare din afara clasei. Daca avem al doilea tip de eroare nici nu vom stii acest lucru.
Cea de-a patra eroare este absenta automatizarii testarii. Oricand scrii un cod care ar trebui sa scrie un test care verifica acel cod. Daca lucrezi cu proiecte complexe sau cu sisteme legacy fara tests atunci ar trebui sa scrii teste cel putin pentru cele mai critice / folosite parti din sistemul tau.
Ultima eroare este duplicarea codului sau nerespectarea principiului DRY. De fiecare data cand copiezi o parte a codului intr-un nou loc trebuie sa tii minte ca este necesar sa modifici ambele blocuri de cod simultan. Ce faci daca ai 10 sau 100 de blocuri de acest gen? Cum poti sa le gasesti usor? Cum poti sa le gasesti daca modifici ceva minor la ele?
Ce inseamna 1 aici? Inseamna ca daca delta este 2 indexul trebuie sa fie 2? Valorile hard-code sunt uneori denumite numere magice si sunt o dovada ca undeva exista un duplicat.
Acestea sunt din punctul meu de vedere cele mai importante 5 erori de programare pe care le-am descoperit lucrand cu Java. Sper ca experienta mea sa va ajute sa evitati aceste provocari pe viitor.
Sergey Morenets
Software Development and Java Specialist
In acest articol voi discuta despre cele mai comune greseli de programare pe care le-am intalnit in cariera mea. Sper ca experientele mele sa va ajute sa reduceti numarul de buguri in proiectele voastre.
Prima eroare despre care vreau sa vorbesc este modul in care sunt denumite elementele de cod. Fiecare variabila, metoda, clasa sau pachet ar trebui sa aiba un nume clar care sa arate rolul ei. Cum putem sa verificam asta? Poti sa te uiti peste un cod pe care l-ai scris acum 6 luni si pe care nu l-ai mai verificat. Poti sa iti amintesti ce face fiecare element din cod?
Un nume sau identificator eficient este usor de facut. Foloseste aceleasi cuvinte pe care le-ai folosi ca sa descrii elementul de cod. Spre exemplu:
Cat de repede iti dai seama ce face aceasta bucata de cod? Poti sa o folosesti? Cum ar trebui sa il implementezi? Raspunsul la aceste intrebari nu are cum sa apara daca nu cunosti autorul codului. Insa toate aceste intrebari dispar daca scrii codul asa:
Cea de-a doua eroare comuna consta in nerespectarea unuia dintre principiile OOP – incapsularea. Nu trebuie niciodata sa accesezi atributele altor obiecte – direct sau indirect. Singura exceptie pentru aceasta regula este prezentarea datelor pentru layerul UI sau trimiterea catre layer-ul DAO. Spre exemplu:
Chiar daca apelam getters si nu accesam campurile din clasa User, nu respectam procesul de incapsulare. Nu trebuie niciodata sa poti sa vezi prezentarea datelor interne din alte clase. In schimb ar trebui sa stii ce operatiuni ofera aceasta clasa si cum sa o folosesti.
Cea de-a treia eroare este lipsa sigurantei codului tau. Sa ne uitam la exemplul de mai jos:
Ati scris un simplu cod de formatare a procentajelor. Este sigur? Da, nu da nici o exceptie ca rezultat. Ce facem insa daca cineva tasteaza -1, spre exemplu. Aceasta metoda produce un rezultat invalid. Ce ar fi daca am modifica astfel codul?
Nu va produce niciodata un rezultat invalid. Insa pur si simplu ascundem o eroare. Faptul ca avem un parametru invalid este semnul unei alte erori de programare din afara clasei. Daca avem al doilea tip de eroare nici nu vom stii acest lucru.
Cea de-a patra eroare este absenta automatizarii testarii. Oricand scrii un cod care ar trebui sa scrie un test care verifica acel cod. Daca lucrezi cu proiecte complexe sau cu sisteme legacy fara tests atunci ar trebui sa scrii teste cel putin pentru cele mai critice / folosite parti din sistemul tau.
Ultima eroare este duplicarea codului sau nerespectarea principiului DRY. De fiecare data cand copiezi o parte a codului intr-un nou loc trebuie sa tii minte ca este necesar sa modifici ambele blocuri de cod simultan. Ce faci daca ai 10 sau 100 de blocuri de acest gen? Cum poti sa le gasesti usor? Cum poti sa le gasesti daca modifici ceva minor la ele?
Ce inseamna 1 aici? Inseamna ca daca delta este 2 indexul trebuie sa fie 2? Valorile hard-code sunt uneori denumite numere magice si sunt o dovada ca undeva exista un duplicat.
Acestea sunt din punctul meu de vedere cele mai importante 5 erori de programare pe care le-am descoperit lucrand cu Java. Sper ca experienta mea sa va ajute sa evitati aceste provocari pe viitor.
Sergey Morenets
Software Development and Java Specialist