Insa pierzi un mic detaliu si anume faptul ca nu in mod necesar good pratices iti fac codul mai usor de debuggerit ci experienta acumulata i.e. cum, daca si unde alegi sa le aplici.
Daca tot suntem la capitolul anecdote vin si eu cu cateva:
La un mom. am sugerat sa folosim Presenters intr-un proiect unde era clar nevoie de astfel de clase. Cateva ore mai tarziu un programator junior adauga un titamai gem pentru ce de fapt se rezolva in cinci linii de cod.
Acum cateva zile, citeam cateva clase/module scrise de un programator “senior” care erau atat de over engineered incat literalmente imi venea sa ma duc sa-i sun la usa si sa-l plesnesc. De ce a facut asta? Pentru ca este cool si prin over-engineering iti poti etala your skills.
Tot recent, cineva a emulat un feature din Rails creat specific pt. a decupla codul pt. ca nu stia de el sau ceva de genul. i.e. before abstracting your framework away - read what the heck it can do for you that’s why you bloody use it in the first place.
etc.
tl;dr: I would prefer code written with humility every day against something that is 100% Uncle Bob approved and ticks all the patterns and acronyms.
Filosofia mea de lucru e f simpla: first we make it work, then we make it pretty.
Dar intotdeauna o facem si pretty. Nu fac niciodata overengineer de la inceput. Adica si eu incep cu un big blob of code in controller, care face ce trebuie. Apoi incet-incet creez modelul, care face cate o bucatica , etc, pana ce imi trec iar testele behat (nu alea phpunit ca 99% din cazuri nu e timp de ele).
Cred ca avem metode diferite de a ajunge la acelasi rezultat. Musai sa facem cumva sa schimbam idei si tehnici si la bere, sa nu mai spamam threadurile legitime in care ceilalti vor sa vada high-level decision in alegerea unui fw.
heh cu cat we split hairs incepi sa convergi. Una este sa zici ^ vs.:
Semantic nu sunt echivalente.
Iar discutia nu este pointless, cel putin pentru mine si nu cred ca am spamat pe nimeni la cate anecdote si pareri from the trenches au iesit la iveala
Sa presupunem că suntem o echipă și avem și o nouă aplicație de scris pentru un anumit client pentru care avem o anumită descriere a ceea ce ar trebui să fie această aplicație. Ce opțiuni avem?
Prima opțiune ar fi următoarea, luăm de bună toată documentația primită și spunem că în 2 săptămâni este gata și folosim framework-ul nostru preferat, facem totul crud-ish și database oriented , nici un fel test și dacă avem noroc ne ținem de cuvânt. Și mai presupun, că atunci când clientul testează aplicația este mulțumit.
Dacă aici se termină totul, am scăpat. Dar dacă, în timp, o să vină noi modificări sau adăugiri atunci va fi o problemă când nu vom mai putea livra la fel de repede și bine din cauză că avem un o aplicație unde nimeni nu vrea să se aproprie pentru că este foarte posibil să o stricăm și e foarte greu de înțeles atât pentru membri mai vechi dar și pentru noi membri care s-au alăturat pe parcurs.
A doua opțiune ar fi să nu ne bazăm pe documentația primită, ci să avem un dialog, să purtăm o conversație bazată pe exemple care produc valoare pentru clientul respectiv. Adică înainte de a deschide un ide și începe a lucra cu framework-ul preferat, să alocam un timp și analizei problemei aplicației și în urma căreia să rezulte scenariile și work flow-ul aplicației. Pe scurt să aplicam principii din bdd/ddd, astfel încât codul nostru să aibă o arhitectură potrivită, să aibă intent și un cost de translație cât mai mic față de limbajul folosit în analiza problemei iar framework-ul sa fie folosit doar la sfârșit pentru infrastructură . Dar pentru asta atât echipa cât și clientul trebuie să comunice, să avem feedback, să avem câteva întruniri de brainstorming gen impact mapping, user story mapping sau event storming și altele asemenea pentru a descoperi ce anume aduce valoare atât pentru client de exemplu o aplicație care este folosită și produce efectul de afacere pentru care a fost construită cât și pentru echipă: living documentation, ușurință în înțelegere și modificare/adăugare de noi funcționalități.
cu cat we split hairs incepi sa convergi. Una este sa zici ^ vs.: