Aplicatia pe care lucrez are un codebase destul de senior good enough. Imi ofera posibilitatea sa vad practicile bune de scriere de cod si design in viata reala 
Cel putin ce inseaman pentru mine code good enough pentru mine(opinie personala):
oricum pari cam verde dupa cum vorbesti, peste cativa ani o sa intelegi ca nu conteaza asta mult codul ci ce faci cu el, poti sa ai cel ai cel mai frumos cod din lume, dar daca e un feature / produs no one gives a shit about, degeaba, insa au fost ridicate imperii pe ugly/spaghetii code.
Bafta la scris spaghete! 
Eu zic sa nu te grabesti la concluzii, @Cosmin_Popescu. Asa ziceam si eu acum niste ani. Intre timp am mai vazut si alte codebase-uri si concluzia pe care as putea sa o trag astazi e ca toate proiectele comerciale de un oarecare success, gen mai mult de 100 de useri sa zicem, si care au depasit de ceva vreme faza de CRUD sau MVP sau POC, au codebase de rahat. 
Cum definesc “de rahat”? Sunt subiectiv, dooh, dar pentru mine numarul si frecventa bugurilor in productie raportat la nr de developeri e o metrica relevanta.
Apoi, cine face on-call. devii? Sysadminii? oameni dedicati de support? Nimeni?
Daca devii sunt raspunsul, cam ai o indicatie clara despre cum arata acel codebase.
Ca sa mai diluez putin treaba, stiu ca multi de aici faceti support on-call si sunteti devi. Asta nu inseamna ca proiectul vostru nu e unul de succes. Doar ca din experienta mea, e un indicator clar ca ceva nu functioneaza acolo si nu ar trebui sa ne mintim singuri in legatura cu calitatea codebase-ului.
Foarte slab articolul, zici ca e scris de o influenceritza de mana a 10-a care a auzit si ea acum de programare si s-a bagat la un articol, ca toti stim despre programare, fotbal, politica si mai nou medicina.
Peste 50% din codul din orice companie e un gunoi, care oricum se rescrie, se sterge in continuu, pe masura ce apar noi functionalitati si alea facute pe graba ca trebuie livrate, strict partile critice ale proiectului primesc investitii de refactorizare, re-arhitecturare, etc, in rest este o bila de namol care se rostogoleste pentru ca banii vin din vanzari nu din arta facuta in cod.
Toti folosim gunoi in cod, v-ati uita vreodata ce este in pachetele alea de npm, composer, sau ce mai folositi voi? Sunt niste jeguri ordinare, spaghetti code, dar au milioane de instalari si duc in spate proiectele noastre curate de seniori care aplica toate bunele practici.
Din experienta mea evolutia codebase-ului e mai importanta decat starea lui curenta.
Ai lucrat la un proiect nou, sa facut lansarea si multe greseli pe partea de implementare si ajungi cu proiectul in productie, in ce directie o iei de aici?
Din punct de vedere al code quality poti sa mergi:
daca faci doar site-ulete sau aplicatii CRUD merge brici si cu o platforma CMS care are un codebase foarte bun. Dar realitatea o arata ca softturile care raman in piata vin cu features noi care nu mereu au legatura cu acel core codebase si daca tu legi bine feature-ul de codebase de care mai legi 2-3 features… o sa iti iasa un miriapod pe care nu vei mai stii de unde sa il iei. Desi microserviciile sunt un pas catre simplificarea codebase-ului, partea nasoala e ca la o aplicatie mare ajungi sa pierzi mai mult timp legand si dezlegand microservicii decat sa codezi…
Ok!
M-am convins!
Mare parte din cod este o mizerie care se rescrie sau se sterge! :))
insa au fost ridicate imperii pe ugly/spaghetii code.
Apropo de codebase bun: ia, care e parerea voastra de WP, are sau nu codebase bun?
Este o opera de arta in linii de cod 
Eu as fi foarte sceptic sa lucrez la o companie cu un clean overenginered codebase, inseamna ca nu prea au utilizatori, business model viabil daca au timp de chestii din astea.
In absolut dezacord cu aceasta opinie. Putem accepta faptul ca pe piata exista o multime de programe scrise repede, sa rezolve treaba si cum s-a priceput fiecare dar de precizat ca in marea majoritate a acestor cazuri sunt programe cu o multime de probleme de la cele de functionalitate pana la cele de aspect, documentatie si ergonomie, adica sunt programe proaste intr-un fel sau altul. Nu as vrea a dau exemple, dar am vazut o multime de programe populare scrise la graba de astfel de amatori care efectiv chinuie utilizatorii. Putem sa ne inchipuim ce cod au si mai putem sa ne inchipuim ce inseamna sa vi dupa unii din astia sa faci ceva in codul ala in aceeasi maniera…
Daca putem accepta faptul ca din anumite motive la inceput ai un codebase scris pe genunchi, e inacceptabil din punctul meu de vedere ca dupa un timp de maturizare codebaseul sa nu intre intr-o faza de engineering care sa il faca colaborativ, mentenabil, etc (adica refactory). Totusi, daca ma intrebi pe mine, cred ca ce incepe prost, de regula, tot asa si continua…
Povestile aste cu codebaseul varza dar care face treaba este in companiile mici/medii care nu au notiunea de engineering bine structurata si implementata (a se revedea aici topicurile alea controversate programator vs software engineer). Personal nu am lucrat in mega corporatii dar sunt convins ca nu te lasa aia sa scrii bazaconii…
Cei care scriu programe bune stiu sa faca arhitecturi bune, cod bun, interfete bune, documentatii bune si bani buni… ceilalti sunt si ei pe acolo, poate fac si bani dar hai sa nu le facem apologia ca nu cred ca cineva isi doreste si ii place sa sa lucreze undeva unde toate sunt vraiste…
si la corporatii sunt multe proiecte varza, google lanseaza multe proiecte care sunt minunatii tehnice dar se inchid dupa un timp pentru ca nu au utilizatori indeajuns, ce crezi ca se intampla cu echipe alea? Exemplu recent Scadia.
Felul cum vb imi aduce aminte de o annecdota, niste developeri se certau tot asa pe o implementare, care mai fancy, si i-a intrebat un PM cine cred ei ca ii plateste si au zis banca. Asa de deconectati pot fi cu businessul, programele vazute de tine scrise de amatori, poti sa le vezi ca exista si nu a stat nimeni luni de zile sa arhitectureze un sistem modular, cu nu stiu ce ierarhie de clase, si servicii separate NoSQL + SQL, layer de distributed in memory caching, sau mai nou, messaging queues, pub-sub workers, etc.
Stiu ca exista, am si spus asta mai sus, idea e sa nu incurajam si sa sustinem ca ele reprezinta o buna practica pentru ca nu este.
Chiar atat de usor este sa credem asta ? De ce ar putea fi greu de crezut ca exista si exemple de best practices ?
Sunt destule companii in care exista un coding guideline, code review facut de 2 developeri, reguli clare care sunt respectate in toate echipele.
Prea mult timp petrecut in companii mediocre sau care fac outsourcing, dauneaza.
Obviously nu trebuie sa imi amintesti ca “nu toti sunt asa”, desigur vorbeam in general, nu ma refer la 100%, mereu se gaseste unu cu remarca asta si altu cu gramatica pe forumuri.
Orice proiect dezvoltat in Agile ajunge in situatia in care technical debt-ul nu conteaza pentru product owner pentru o perioada lunga de timp. Desigur ca in acest timp ai nevoie de refactor pentru performanta, pentru arhitectura, pentru testare, pentru actualizare setari, pentru build process si trebuie sa aduci de acasa ca sa poti imbunatati aceste lucruri fiindca tu trebuie sa livrezi feature-urile cerute si nu le poti bloca cu un refactor in sprint.
E plin de programatori care vor sa livreze cu orice pret si nu le pasa ca nu e eleganta solutia (le pasa la inceput, dupa ce vad ca nu le iese si ca trebuie sa plateasca chiria/ratele pun un minus in css la o proprietate, pun cod doar cu teste tautologice fara sa vada ce s-a facut mai inainte si care-i best practice si cumva scot ceva functional). Nu degeaba exista definition of done, cat timp indeplinesti criteriile poti livra.
Cel care iti da salariul se uita doar daca tu ai un burndown chart si ca inchizi sprint-ul cu story-urile inchise cu PO sign-off.
Nici code review-urile nu sunt de incredere daca nu exista integrator cu experienta si standare inalte ci doar prieteni care iti dau approve daca nu cade build-ul.
Doar un proiect greenfield poate fi visul oricarui programator, orice alt proiect care face bani necesita inginerie si are si parti frumoase si parti urate cu spume. (aici sunt mici exceptii cand toti din echipa scriu cod in Haskell/OCaml si au facut doctorat in fizica cuantica fiindca s-au plictisit dupa doctoratul in informatica)
Wow!
Nu am ajuns inca la OCaml, Haskell si fizica cuantica 
Eu ma refer la chestii de bun simt ca sa zic asa.
Exact!
Avem un set de recomandari pt scrierea codului. Facem code review. Chiar am primit code review (pe Teams) pentru niste modificari etc
Ceva care se înrudește cu această discuție https://blog.pragmaticengineer.com/the-developer-culture-test/