Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

Internet De Citit / De Vizionat
1

Pe serverul nostru de Discord a apărut link-ul ăsta.

Cred că toți am moștenit la un moment dat proiecte care să te facă să exclami: „cine ți-a lucrate dom’ne aici, că și-a bătut joc de mata”. (dacănu ai pățit așa, cel mai probabil tu ești cel care aduce proiectele în stadiul ăsta… :sweat_smile:).

O lectură interesantă, cu soluții care variază de la „dă-ți demisia” și „rescrie-l de la zero”, la sfaturi practice și utile despre cum ar putea aduce îmbunătățiri.

Profit de ocazie să recomand (iar) cartea asta, care a devenit gratuită de ceva timp.

7 Likes
2

Daca ignoram lista mare de defecte tehnice, ce spune autorul defapt?

  • Proiectul produce bani
  • Un singur backend dev, si acela junior

Ce nu spune autorul:

  • Cat e de mare proiectul? E vechi, e prost scris, dar daca se multumesc cu 1 backend dev n-o fi atat de mare…
  • Care e problema pe care o vrea managementul rezolvata? Sigur nu calitatea codului
    • Scad veniturile si nu stiu cum sa opreasca asta?
    • Vor sa se extinda?

Autorul se gandeste la tot felul de probleme tehnice. O parte poate reuseste sa le rezolve usor, dar… cu cine?

  • Zice ca e un fel de manager, n-a fost mutat ca dezvoltator acolo sa faca curat.
  • Backend devul actual ce se complace sa lucreze pe asa cod n-o sa inceapa brusc sa scrie cod curat. Poate daca maine ar pleca si ar lucra apoi pe proiecte sanatoase ar avea sanse sa fie devina dev decent.
2 Likes
3

Interesant. Provocarea cea mai mare este cum să motivezi devii existenți care au tot know-how-ul să se implice în îmbunătățirea aplicației fără să-și ia tălpășița. E clar că trebuie development paralel cel puțin o perioadă până se introduce versionare și staging.

4

O varianta ar fi sa faca refactoring la orice poate fi transformat in microservice, dar si aia e complicat.

Nu cred ca nimeni nu o sa ii poata da un raspuns bun, pentru ca nu se vede codul, cum e PHP sa il muti pe ceva ca si Laravel sau Symfony, ar fi o gramada de lucru. ( → microservices iar )

N-ai nici cum sa faci full re-write, nici sa nu il faci, pentru ca, daca faci full rewrite, poti ajunge in scenariul in care 1.x creste si se face development mai repede decat 2.x, si, pentru ca “core-ul” e atat de prajit, poate arunci un feature in 1.x in cateva ore, care in 2.x arhitectura trebuie schimbata toata sa il permite, si face un backlog de +20 ore.

Am facut full re-write la pluginuri de WordPress, 100,000+ randuri, nu poti sa il faci in pasi, doar daca faci cateva iteratii de rewrite la rewrite.

Daca ar fi sa ii fac eu rewrite, fac un folder _old arunc tot acolo, si incep cu DB-ul, presupun ca, daca n-au GIT, n-au nici migration system la DB.

Cel mai probabil o sa faca un produs nou ( 2.0 sau cat o fi ), din 0, fara re-write, cu toate functionalitatile de baza critice, si incep sa mute useri, apoi continua development-ul de features, e mult mai productiv la nivelul ala de rulaj + usage, problema e ca, e o decizie de marketing mai degraba decat development sa faca alternativa asta.

2 Likes
5

probabil n-are nici teste deci bafta cu rewriteu. Mai sigur bagi un sprint pe teren minat

6

E o chestiune de resurse disponibile, eu cel mai probabil faceam un split de echipa, una care sa se ocupe de development si support pe codebase-ul existent si una care sa se ocupa de rewrite pe o aplicatie noua. Mergi cu doua aplicatii in paralel si inlocuiesti bucati de aplicatie (rute) cu noile functionalitati, DB e cea mai mare problema pe care o vad aici ca daca incepi development pe o structura care nu e optima nu va fi bine.

Cand ai vreo 3 oameni disponibili nu vad asa ceva realizabil, cel mai posibil ar fi sa se mentina structura curenta si cam atat.

7

Am experienta pe asemenea proiecte.

E drept, nu php ci varza de C & C++. Proiecte incepute in 1900 toamna prin Australia, vandute si revandute pana au ajuns prin USA, cu fork la un moment dat devenind doua proiecte separate destul de diferite (de ex unul folosea Oracle, celalalt Ms Sql Server). Erau urme de cod pe-acolo de pe vremea Wingoz 3.0.
Nu prea foloseau multe biblioteci ‘din afara’, pur si simplu erau implementari proprii folosind winapi & crap. Pana si raportarea era implementare proprie, era o adevarata distractie sa lucrezi la rapoarte.
Eu am adaugat ceva destul de cool 3d cu DirectX, dar in general interfata arata ca si cum ar fi fost tehnologie de secol trecut.

Avantajul era ca mergea rapid.

Codul era plin de buguri si de portiuni nefunctionale. Exista un tester sau doi plus ce se raporta de la clinici si de la o universitate (sau mai multe?) ce folosea unul dintre programe (erau ceva pe domeniu medical).
Programatori erau doar cativa. Mult prea putini pentru proiectele alea gigantice.

Programatorii se ocupau in principal de rezolvarea de buguri si de adaugarea de functionalitati cerute de catre clienti. Chestia cu tabelele noi imi suna foarte cunoscuta, cam asa se intampla si cu proiectele astea, nu prea vrei sa alterezi multe tabele la fiecare versiune noua in baze de date imense din productie…

Eu am primit si taskul de a ‘porta’ un proiect la .net si chiar am reusit treaba asta… pana si eu am fost surprins ca am reusit :slight_smile:
In ciuda faptului ca interfata arata mai bine, clientii au preferat varianta non .net, pentru ca bloatwareul & crapwareul .net adaugat chiar se simtea, aplicatia nu mai era asa de ‘snappy’ ca varianta nativa.

Cu asemenea aplicatii gigantice, cu putini programatori… nu se mai poate face nimic. Se poate teoretiza la nesfarsit despre solutii, cum se poate face… dar practic nu se poate face nimic.
E imposibil de rescris. A durat zeci de ani sa ajunga acolo, cine crede ca ia doi programatori si reimplementeaza totul in doi ani viseaza la cai verzi pe pereti. Poate in doi ani ajung aia sa inteleaga cat de cat ce se intampla prin proiectul ala… nici vorba sa si implementeze din nou.

2 Likes
8

Astia care zic ca “rescriu” n-au rescris niciodata o aplicatie mare. Nici macar nu ai cum estima vag un astfel de task.

6 Likes
9

Îți trebuie un om cu papagal care să explice timp de 2-3 ani clientului că luna viitoare va fi gata feature-ul pe care îl așteaptă de 3 ani la rewrite fără să fie dat afară.

Când îl ai te apuci de rewrite.

După iți trebuie un product owner care să zică ce se vrea și ce nu se vrea. Plus designer care să cosmetizeze totul ca să se poată vândă clientului sfantul graal, un design frumos la aplicația veche.

1 Like
10

Motivația asta e folosită si in mod imoral.
Începătorii sau cei cu mai puține cunoștințe ar prefera să o ia de la zero și să folosească tehnologiile cunoscute de ei.
Așa că o bagă p-asta clienților.

In cazul de față, dat fiind că afacerea e profitabilă, autorul trebuie să se adapteze.

Am avut cod propriu care era spaghetti si l-am făcut treptat modular.

In cazul lui, problema e că trebuie să pună echipa varză să facă treaba corect.

Cred că a fost ca o avalanșă. Toți care au venit în echipă s-au resemnat si au mers pe spaghetti.