Legacy code, cum il definim

https://leejo.github.io/2016/02/22/all_software_is_legacy/

cel mai mult mi-a placut punctarea faptului ca acel cod scris de newbies devine cel mai repede legacy

“The shiny new can be attractive, however the newer you are the quicker your software becomes legacy because you don’t yet know what you don’t know”

3 Likes

Do you think Google, Facebook, et al, would have grown to their size and domination had they anticipated the size of their business a year, five years, a decade down the line and spent extra time designing the systems to deal with that? “We can’t use php, mysql, whatever, because it won’t scale to a billion users?” No, they make it scale and if they can’t they will replace it with something else that can, later.

Chestia asta e foarte potrivită în contextul ăsta. Cred că ar trebui printată pe cartonașe date cadou în stânga și în dreapta.


Feathers zice în introducere¹ că orice cod care nu e însoțit de teste este legacy.

Eu cred că tot codul ajunge să fie legacy, chiar și prin prisma traducerii mot-a-mot. Cod scris de mine acum un an? Legacy, pentru că într-un an am învățat o grămadă. Cod scris de Patel, Rajes sau Amit ieri? Legacy, din motive evidente. :smiley:

The important thing is that we learn from that and we make sure the future legacy is easy to understand. Write clean interfaces, good tests, descriptive commit messages.


¹ Încă n-am trecut de introducere :smiley:

Din pacate mult prea des vad cod legacy scris de oameni cu foarte mare experienta. Nu cred ca important este daca esti junior sau senior, conteaza cat de mult iti pasa sa ai un sistem cum spune Michael Feathers, usor de inteles, bine modularizat si care sa aiba un cost mic de schimbare.

De asemenea daca juniorii scriu cod nepotrivit, inseamna ca la nivelul organizatiei nu exista mentoratul potrivit pentru a ii invata repede cum ar fi mai eficient sa scrie cod. Un cod scris intr-un mod nepotrivit nu afecteaza doar echipa curenta, ci are efecte majore pentru mentenanta codului.

Eu am preluat definitia de la Michel despre Legacy Code si cred serios ca orice cod neacoperit de teste este legacy code. Incerc sa vorbesc mai putin despre legacy code si mai mult de cod care nu are un test coverage suficient pentru scopul in care a fost creat. Una este coverage pentru un modul experimental unde nu stiu inca ce fac (aici pot sa scriu teste putine sau deloc la inceput pentru ca nu stiu exact ce trebuie sa fac), alta este o zona core a codului care daca ar pica mi-ar muri tot sistemul (aici as vrea sa am 60-80% test coverage).

Testele mici, in izolare forteaza un design decuplat si usor de schimbat. Pe masura ce dobandim experienta ne dam seama si fara teste ca ceva nu e decuplat bine, putem sa aplicam modele si reguli. Dar cu toata experienta uneori este foarte greu sa ne dam seama ca anumite concepte trebuie impartite in alt fel, si aici daca ascultam testele putem sa generam un cod care are un design potrivit, usor de schimbat. Un cod care este un “happy legacy”.

6 Likes

Mai mult sau mai putin in serios …

git commit -m "Gata taskul" && git push = legacy code

1 Like

Calitatea sunetului nu este ideala, dar workshopul de la Agile Vancouver acopera si mai frumos partea de legacy, in sensul de a-l eplica mai larg.

Eu sunt in mare acord cu @Adi legat de acoperirea cu teste. Abordarea mea e putin diferita, pentru ca in viata reala am observat niste probleme ale developerilor legate de TDD.

In echipe exista oameni care nu sunt asa religiosi cu privire la modul de munca, si de multe ori am gasit frustrare si nefericire din partea unor colegi care sunt pusi in mediu agile+tdd. Si trebuie sa ne facem treaba ca echipa, nu putem schimba totul in jurul nostru, doar cate un lucru o data. Am observat ca cel mai bine se introduce metodologia BDD, in sensul in care un developer e mai dispus sa isi cover own ass cu un BDD test care acopera functionalitatea dpdv top-down decat sa stea sa faca design emergent din TDD. In felul acesta el poate sa livreze functionalitate in modul in care e deja obisnuit si totusi sa aiba test coverage.

Dupa cateva iteratii in care vede cum il salveaza BDDul, acelasi developer va fi mult mai receptiv la TDD si design emergent in locul abordarii sale, si va fi mai usor de introdus concepte.

Probabil cam asa ceva :slight_smile:

1 Like