Code smell

Code smell (în traducere literală, „mirosuri de code”) sunt, în programarea calculatorelor, simptome ale codului-sursă al unui program, care pot indica o problemă mai profundă.^[1] Conform lui Martin Fowler^⁠(d),^[2] „un code smell este un indiciu la suprafață care corespunde, de obicei, unei probleme mai profunde în sistem”. Un alt mod de a privi code smell este în raport cu principiile și calitatea:^[3] „smellurile sunt anumite structuri în cod, care indică încălcarea principiilor fundamentale de design și au un impact negativ asupra calității designului”. Code smellurile nu sunt de obicei buguri—nu sunt incorecte din punct de vedere tehnic și nu împiedică programul să funcționeze. Ele indică în schimb deficiențe de proiectare care pot încetini dezvoltarea sau crește riscul de apariție a bugurilor sau a erorilor în viitor, și pot fi un indicator al unor factori care contribuie la technical debt.^[1] Robert C. Martin consideră că o listă de code smelluri constituie un „sistem de valori” pentru software craftsmanship.^[4]

Adesea, problema mai profundă sugerată de un code smell poate fi descoperită atunci când codul este supus la un scurt ciclu de reacție în care este refactorizat în pași mici și controlați, iar designul rezultat este examinat pentru a vedea dacă există în continuare code smelluri care să indice nevoia de mai multe refactorizări. Din punctul de vedere al unui programator însărcinat cu efectuarea refactorizării, code smellurile sunt euristici care indică momentul când trebuie făcută o refactorizare și ce tehnici de refactoring să se utilizeze. Astfel, un code smell este o metodă de conducere a refactorizării.

În 2015, un studiu^[1] ce utiliza analiza automată a o jumătate de milion de commituri și examinarea manuală a 9.164 de commituri găsite a prezenta „code smells” a constatat că:

Există dovezi empirice ale consecințelor „technical debtului”, dar există doar dovezi anecdotice privind cum, când, sau unde apare.
„Bunul simț sugerează că activitățile urgente de mentenanță și presiunea de a livra funcționalități, în condițiile acordării unei priorități mai mari vitezei de livrare față de calitatea codului sunt adesea cauze de astfel de smelluri”.

Termenul pare a fi fost introdus de Kent Beck pe WardsWiki spre sfârșitul anilor 1990. Gradul lui de utilizare a crescut după ce a apărut în cartea Refactoring: Improving the Design of Existing Code.^[5] Code smell este și un termen utilizat de programatorii ce folosesc metoda agile.^[6]

Determinarea a ce este și ce nu este un code smell este ceva subiectiv, și variază în funcție de limbaj, dezvoltator și metodologie de dezvoltare. Există unele unelte, cum ar fi Checkstyle, PMD și FindBugs pentru Java, care caută automat anumite tipuri de code smell.

Code smelluri comune[modificare | modificare sursă]

La nivelul aplicației:

Cod duplicat: cod identic sau foarte similar există în mai multe locuri.
Complexitate agravată: utilizarea forțată de design patternuri complicate acolo unde ar fi suficient un design mai simplu.

La nivel de clasă:

Clasă mare: o clasă care a crescut prea mult.
Feature envy: o clasă ce folosește excesiv metode ale unei alte clase.
Intimitate nepotrivită: o clasă care are dependențe de detaliile de implementare ale unei alte clase.
Refused bequest: o clasă ce suprascrie o metodă a clasei de bază în așa fel încât contractul clasei de bază nu mai este respectat de clasa derivată.
Lazy class / freeloader: clasă care face prea puțin.
Abuz de literali: în loc de literali ar trebui folosite în principal constante cu nume, pentru a ameliora lizibilitatea și pentru a evita erorile. Literalii ar trebui externalizați în fișiere de resurse, pentru a facilita localizarea software-ului dacă se dorește instalarea sa în regiuni sau contexte lingvistice diferite.
Complexitate ciclomatică: prea multe bucle și ramificări; aceasta poate indica faptul că o funcție trebuie divizată în funcții mai mici, sau că are potențial de simplificare.
Downcasting: un cast care rupe modelul de abstracție; abstracția poate fi refactorizată sau eliminată.^[7]
Variabilă orfană sau clasă de constante: o clasă care are o colecție de constante ce își au locul în altă parte, unde constantele ar trebui deținute de una dintre celelalte clase-membru.

La nivel de metodă:

Prea mulți parametri: o listă lungă de parametri este greu de citit și complică apelarea și testarea metodei. Poate sugera că funcția este slab concepută și că codul ar trebui refactorizat pentru a atribui responsabilitățile într-o manieră mai limpede.
Metodă lungă: o metodă^⁠(d), funcție sau procedură ce a devenit prea mare.
Identificatori excesiv de lungi: în particular, utilizarea convențiilor de denumire^⁠(d) pentru dezambiguizare ar trebui să fie ceva implicit în arhitectura software^⁠(d).
Identificatori excesiv de scurți: numele unei variabile trebuie să reflecte funcționalitatea ei dacă nu este ceva evident; de exemplu, variabilele de o singură literă sunt frecvente în manuale și în exemplele didactice și devin o practică încetățenită la începători, dar în proiectele practice rolul lor nu mai este înțeles atunci când codul este reanalizat în procesul de mentenanță
Retur excesiv de date: o funcție sau metodă care returnează mai mult decât are nevoie codul apelant.

Referințe[modificare | modificare sursă]

^ ^a ^b ^c Tufano, M.; Palomba, F.; Bavota, G.; Oliveto, R.; Di Penta, M.; De Lucia, A.; Poshyvanyk, D. (1 mai 2015). „When and Why Your Code Starts to Smell Bad” (PDF). 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering (ICSE). 1: 403–414. doi:10.1109/ICSE.2015.59.
^ Fowler, Martin. „CodeSmell”. http://martinfowler.com/. Accesat în 19 noiembrie 2014. Legătură externa în |website= (ajutor)
^ Suryanarayana, Girish (noiembrie 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-0128013977. Accesat în 19 noiembrie 2014.
^ Martin, Robert C. (2009). „17: Smells and Heuristics”. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. ISBN 978-0-13-235088-4.
^ Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.
^ Binstock, Andrew (27 iunie 2011). „In Praise Of Small Code”. Information Week. Arhivat din original la 2 iulie 2011. Accesat în 27 iunie 2011.
^ Miller, Jeremy. „Downcasting is a code smell”. Arhivat din original la 16 februarie 2019. Accesat în 4 decembrie 2014.

[:0-1] Tufano, M.; Palomba, F.; Bavota, G.; Oliveto, R.; Di Penta, M.; De Lucia, A.; Poshyvanyk, D. (1 mai 2015). „When and Why Your Code Starts to Smell Bad” (PDF). 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering (ICSE). 1: 403–414. doi:10.1109/ICSE.2015.59.

[2] Fowler, Martin. „CodeSmell”. http://martinfowler.com/. Accesat în 19 noiembrie 2014. Legătură externa în |website= (ajutor)

[3] Suryanarayana, Girish (noiembrie 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-0128013977. Accesat în 19 noiembrie 2014.

[4] Martin, Robert C. (2009). „17: Smells and Heuristics”. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. ISBN 978-0-13-235088-4.

[5] Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.

[In_Praise_Of_Small_Code-6] Binstock, Andrew (27 iunie 2011). „In Praise Of Small Code”. Information Week. Arhivat din original la 2 iulie 2011. Accesat în 27 iunie 2011.

[7] Miller, Jeremy. „Downcasting is a code smell”. Arhivat din original la 16 februarie 2019. Accesat în 4 decembrie 2014.

[1]

[2]

[3]

[4]

[5]

[6]

[7]