5 erori de programare in Java
5 erori de programare in Java
Chiar si cei mai calificati software developeri gresesc uneori. Uneori acest lucru se intampla din cauza lipsei de atentie sau a unui API neclar. Insa acest tip de greseli sunt rare. Cele mai comune erori de programare sunt determinate de lipsa cunostintelor sau a expertizei.
20 Jul 2016
3242
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
Chiar si cei mai calificati software developeri gresesc uneori. Uneori acest lucru se intampla din cauza lipsei de atentie sau a unui API neclar. Insa acest tip de greseli sunt rare. Cele mai comune erori de programare sunt determinate de lipsa cunostintelor sau a expertizei.
In acest articol vom analiza cele mai frecvente erori de programare pe care le-am intalnit in proiecte. Speram ca aceste experiente va vor ajuta si pe voi sa reduceti numarul de bug-uri din proiectele voastre.
Prima eroare despre care vrem sa vorbim este denumirea incorecta a elementelor de cod. Fiecare variabila, metoda, clasa sau pachet ar trebui sa aiba o denumire precisa. Cum poti sa verifici asta? Poti sa treci in revista un cod pe care l-ai scris acum 6 luni si pe care nu l-ai mai revizuit. Poti sa iti amintesti ce facea exact fiecare element din acel cod?
Nu este chiar atat de greu sa ai o denumire buna a elementelor de cod – pur si simplu utilizezi aceleasi cuvinte pe care le-ati folosi pentru a-l descrie intr-o conversatie. Putem sa luam ca exemplu codul de mai jos:
Ce inseamna acest cod pentru tine? Poti sa il folosesti? Cum ar trebui sa il implementezi? Aceste intrebari raman fara raspuns daca nu il stii pe autorul codului. Toate aceste intrebari vor disparea insa daca il rescrii asa:
Cea de-a doua eroare este incalcarea unuia dintre principiile OOP - incapsularea. Nu trebuie niciodata sa accesezi atributele altor obiecte – direct sau indirect. Singura exceptie de la aceasta regula tine de prezentarea datelor pentru layer-ul UI sau trimiterea catre layer-ul DAO (data access object). Spre exemplu:
Chiar daca apelam getters si nu accesam campurile User class, incalcam principiul incapsularii. Nu trebuie niciodata sa fim constienti de prezentarile interne de date din alte clase. In schimb, ar trebui sa stim ce operatiuni ofera aceasta clasa si cum sa le folosim.
Cea de-a treia eroare este lipsa sigurantei codului. Sa ne uitam la exemplul de mai jos:
Am scris un cod foarte simplu de formatare a procentajului. Este sigur? Da, niciodata nu are ca rezultat o exceptie. Insa ce facem daca cineva foloseste o valoare negativa, -1. Aceasta metoda produce un rezultat invalid. Putem sa modificam acest cod?
Nu va produce niciodata un rezultat invalid. Insa doar ascundem eroarea. Faptul ca cineva foloseste un parametru invalid semnalizeaza de fapt o alta eroare de programare in afara clasei noastre. Daca avem ultima eroare de care vorbeam nu ne vom da seama de acest lucru.
Cea de-a patra eroare este absenta test automation. De fiecare data cand scriem un cod care ar trebui sa scrie un test care sa verifice un cod. Daca ai proiecte cu milioane de linii de cod sau un sistem legacy fara teste atunci ar trebui sa scrii teste cel putin pentru cele mai critice si utilizate parti ale sistemului tau.
Cea de-a cincea eroare este incalcarea principiului DRY. De fiecare data cand copiezi o parte din cod intr-o zona noua, ar trebui sa tii minte ca trebuie sa modifici ambele code blocks simultan. Ce faci insa daca ai 10 sau 100 de astfel de code blocks? Cum poti sa le gasesti rapid? Cum poti sa le gasesti daca schimbi doar o parte din ele?
Ce inseamna 1 aici? Inseamna ca daca delta e 2 index-ul trebuie sa fie tot 2? Hard-codes values mai sunt cunoscute si ca numere magice si semnalizeaza faptul ca undeva lucrurile se dubleza.
Acestea sunt, in opinia mea, cele mai importante 5 erori de programare pe care le-am intalnit in Java. Sper ca va fie de ajutor.
Sergey Morenets
Software Development and Java Specialist
In acest articol vom analiza cele mai frecvente erori de programare pe care le-am intalnit in proiecte. Speram ca aceste experiente va vor ajuta si pe voi sa reduceti numarul de bug-uri din proiectele voastre.
Prima eroare despre care vrem sa vorbim este denumirea incorecta a elementelor de cod. Fiecare variabila, metoda, clasa sau pachet ar trebui sa aiba o denumire precisa. Cum poti sa verifici asta? Poti sa treci in revista un cod pe care l-ai scris acum 6 luni si pe care nu l-ai mai revizuit. Poti sa iti amintesti ce facea exact fiecare element din acel cod?
Nu este chiar atat de greu sa ai o denumire buna a elementelor de cod – pur si simplu utilizezi aceleasi cuvinte pe care le-ati folosi pentru a-l descrie intr-o conversatie. Putem sa luam ca exemplu codul de mai jos:
Ce inseamna acest cod pentru tine? Poti sa il folosesti? Cum ar trebui sa il implementezi? Aceste intrebari raman fara raspuns daca nu il stii pe autorul codului. Toate aceste intrebari vor disparea insa daca il rescrii asa:
Cea de-a doua eroare este incalcarea unuia dintre principiile OOP - incapsularea. Nu trebuie niciodata sa accesezi atributele altor obiecte – direct sau indirect. Singura exceptie de la aceasta regula tine de prezentarea datelor pentru layer-ul UI sau trimiterea catre layer-ul DAO (data access object). Spre exemplu:
Chiar daca apelam getters si nu accesam campurile User class, incalcam principiul incapsularii. Nu trebuie niciodata sa fim constienti de prezentarile interne de date din alte clase. In schimb, ar trebui sa stim ce operatiuni ofera aceasta clasa si cum sa le folosim.
Cea de-a treia eroare este lipsa sigurantei codului. Sa ne uitam la exemplul de mai jos:
Am scris un cod foarte simplu de formatare a procentajului. Este sigur? Da, niciodata nu are ca rezultat o exceptie. Insa ce facem daca cineva foloseste o valoare negativa, -1. Aceasta metoda produce un rezultat invalid. Putem sa modificam acest cod?
Nu va produce niciodata un rezultat invalid. Insa doar ascundem eroarea. Faptul ca cineva foloseste un parametru invalid semnalizeaza de fapt o alta eroare de programare in afara clasei noastre. Daca avem ultima eroare de care vorbeam nu ne vom da seama de acest lucru.
Cea de-a patra eroare este absenta test automation. De fiecare data cand scriem un cod care ar trebui sa scrie un test care sa verifice un cod. Daca ai proiecte cu milioane de linii de cod sau un sistem legacy fara teste atunci ar trebui sa scrii teste cel putin pentru cele mai critice si utilizate parti ale sistemului tau.
Cea de-a cincea eroare este incalcarea principiului DRY. De fiecare data cand copiezi o parte din cod intr-o zona noua, ar trebui sa tii minte ca trebuie sa modifici ambele code blocks simultan. Ce faci insa daca ai 10 sau 100 de astfel de code blocks? Cum poti sa le gasesti rapid? Cum poti sa le gasesti daca schimbi doar o parte din ele?
Ce inseamna 1 aici? Inseamna ca daca delta e 2 index-ul trebuie sa fie tot 2? Hard-codes values mai sunt cunoscute si ca numere magice si semnalizeaza faptul ca undeva lucrurile se dubleza.
Acestea sunt, in opinia mea, cele mai importante 5 erori de programare pe care le-am intalnit in Java. Sper ca va fie de ajutor.
Sergey Morenets
Software Development and Java Specialist