Sindromul Nu a fost inventat aici

Acum cativa ani am scris cateva articole scurte legate de tiparele de comportament pe care le intalnim in industria IT&C: Technical Debt, Refactoring Syndrome si The Second-System Effect. A venit momentul sa discutam despre un subiect apropiat si probabil unul dintre cele mai comune comportamente: sindromul Nu a fost inventat aici.

Mar 4, 2016 1813
Acum cativa ani am scris cateva articole scurte legate de tiparele de comportament pe care le intalnim in industria IT&C: Technical Debt, Refactoring Syndrome si The Second-System Effect. A venit momentul sa discutam despre un subiect apropiat si probabil unul dintre cele mai comune comportamente: sindromul Nu a fost inventat aici.

Sunt foarte putini programatori care sa aprecieze cu adevarat codul altora. Are prea multe linii, este greu sa iti dai seama care este esenta lui, se citeste greu etc. Insa a construi ceva de la zero este o poveste diferita: sistemul este dezvoltat in etape, stii ce compromisuri au fost facute la fiecare pas si intelegi de ce au fost luate anumite decizii. Inveti pentru ca informatiile despre sistem iti sunt familiare. Dar in momentul in care apare altcineva sansele sunt destul de mari ca acesta sa nu iti aprecieze efortul si sa vrea sa rescrie totul.

Insa cei care vor sa refaca totul de la zero au si ei motivele lor.

In primul rand, dezvoltarea de la zero este mult mai distractiva! Este mult mai distractiv sa dezvolti o colectie concurenta, propriul message exchange manager sau propriul ORM! Este o modalitate foarte utila de a invata in detaliu. Insa atunci cand utilizezi ce au dezvoltat altii nu e la fel de distractiv.

Sindromul Nu a fost inventat aici.jpeg


In al doilea rand, s-ar putea sa nu stii de existenta unei solutii gata facute. Daca nu stii ca exista librarii pentru parsarea arborilor cu expresii sau arbori cu expresii in .Net, este evident ca vei incerca sa iti dezvolti propria solutie. Exemplul de mai sus este exagerat dar scopul este sa arate modul in care propriile noastre limitari ne conduc spre solutii necorespunzatoare sau spre dezvoltarea de solutii noi.

In al treilea rand, reutilizarea solutiei dezvoltate de altcineva poate sa fie mai dificila decat dezvoltarea propriei solutii. Nimeni nu vrea sa foloseasca codul altcuiva daca asta inseamna ca ai nevoie de 3 arhive noi, descarcarea a inca doua programe pentru a le asambla si abia apoi poti incepe sa te uiti peste cod ca sa intelegi ce se intampla. Atunci cand aceste provocari minore de utilizare, actualizare sau diagnosticare a erorilor incep sa se acumuleze vor afecta munca oricarui developer!

In al patrulea rand, s-ar putea sa crezi ca tu vei dezvolta o solutie mai buna. Nimeni nu poate sa dezvolte o colectie concurenta asa cum poti tu. Nimeni nu poate sa implementeze un key-value score cum o faci tu! Ai studiat diferite implementari si stii in mod clar care sunt problemele lor si cum sa le eviti. In acest caz solutia ta nu va include greselile din solutiile vechi. Nu utilizezi codul existent dar in mod cert utilizezi experienta ta si a altora. Astfel s-ar putea sa ajungi la o solutie utila pentru tine si cei din jur (Roslyn este un exemplu excelent pentru acest tip de abordare).

Dar de cele mai multe ori situatia se intampla diferit: ai auzit ca cineva a lucrat cu o serie de colectii imuabile si ceva nu a fost ok. Si fara sa incerci sa intelegi de ce exista acele probleme intr-o librarie gata facuta, scrii propria solutie. Rezultatul in majoritatea cazurilor este o supa reincalzita. Un tratament temporar care permite solutiei sa functioneze.

Reutilizarea vs reinventarea rotii este o situatie comuna pentru developeri. In Microsoft exista 4 sisteme diferite pentru colectarea si analizarea datelor telemetrice, o duzina de clone IL code analyzers si mii de implementari. Si astfel de situatii se gasesc in orice companie.

Este destul de dificil sa gasim echilibrul perfect intre aceste doua abordari. Sindromul Nu a fost inventat aici poate fi vazut ca un caz de reutilizare a unei componente vs. duplicarea codului. In unele cazuri este mai bine sa duplicam codul fara sa introducem alte tipuri de relatii iar in alte cazuri este mai bine sa rezumam si sa dezvoltam o componenta reutilizabila.

Popularitatea NuGets si a altor sisteme de management al pachetelor duce la o utilizare mai facila a componentelor third party si ajuta la reutilizare. Insa aceasta combinatie intre pesimism (toti programeaza gresit) si optimism (dar eu voi face mai bine) nu va permite acestui sindrom sa dispara. Ceea ce s-ar putea sa nu fie chiar atat de grav.

Sergey Teplyakov
Expert in .Net, ++ and Application Architecture

Daca iti place acest articol, distribuie-l si prietenilor tai!




Mai ai intrebari?
Contacteaza-ne.
Thank you.
Your request has been received.