Hai mă, las-o dracului de treabă. Uneltele se schimbă când n-ai ce face și testezi toate rahaturile hip de care nimeni de pe internet nu-și va aminti peste un an (dar tu va trebui să oferi mentenanță la codul ăla)
Te referi la tooling: ce anume se schimbă? Editoarele? Mediul de dezvoltare?
Te referi la limbaj sau framework? Ce faci, schimbi le schimbi mid-project?
Ce patterns au devenit antipatterns (în decurs de șase luni)?
Folosesti o librarie de tabel, libraria se poate extinde cu plugin-uri, dupa 6 luni vrei sa ii faci update fiindca exista lucruri de care ai nevoie. Bad luck, au scos plugin-urile.
Creezi un proiect cu netflix stack, dupa 6 luni-1 an netflix abandoneaza stack-ul si spune sa folosesti kubernetes dns pentru service discovery. Netflix stack era the holy grail ani de zile pe Java, gata nu mai e.
Pe FE framework-urile adopta signals, inainte era set/get, rxjs, hooks…
Tooling-ul pe FE se schimba categoric, nu mai folosesti webpack, folosesti vite, nu mai folosesti vite, folosesti rpack…
Editorul se muta in cloud, proiectul trebuie setat in kubernetes, cu remote la IDE in cloud…
Da, par frustrari, dar sunt reale si vor fi si mai multe in viitor.
Inca mai sunt chestii care nu-s asa de hyped.
Mai sunt multe de rumegat, pana la ce zici tu
cunosc oameni care alearga la orice apare nou, dar cunosc si oameni cu tipare spre ex: php si jquery sau .NET si SQLServer pe viata 
altceva nu fac.
My dude, tot ce ai scris acolo nu îmi contrazice spusele, ba chiar mi le întărește.
Dacă ai proiect pe webpack, rămâne pe webpack. Este nevoie de un incentive serios pentru a aloca ore migrării. Și de (prea) multe ori „compilează de x ori mai repede” nu este o motivație serioasă pentru management (i.e. cei care te plătesc).
Idem și pentru restul.
Două întrebări, că-s oarecum pe lângă cu FE:
evident, nu este vorba doar despre signals ci despre orice „the next big thing” efemer. ↩︎
- ești obligat să folosești signals? Sau ți se sugerează? Ce se întâmplă dacă nu o faci?
esti exclus din comunitatea programatorilor trendy care n-au pus nimic in productie.
eu nu inteleg goana asta dupa ultima tehnologie. am proiecte care inca-s live de acu 10 ani, cu aceleasi tehnologii de acu 10 ani si produc bine mersi. se incarca rapid, nu pica, nu trebuie schimbari.
inteleg nevoia la un proiect nou, dar la un proiect vechi la care tot adaugi feature-uri si faci mentenanta chiar nu se preteaza. uneori schimbarile sunt atat de drastice incat e mai simplu sa refaci de la 0.
ps: eu vad programatorii moderni ca niste copii care invata sa potriveasca diferite forme. nu prea inteleg ce fac, da dupa multe incercari functioneaza. nu zic ca-i rau sa stii sa folosesti diferite tehnologii, doar ca majoritatea n-au idee de ce se invarte.
Depinde de tipul proiectului, de durata lui, de rigurozitatea cerintelor pentru lansare, de ce vrei sa atingi, de viteza de dezvoltare, daca esti la faza incipenta, daca esti in dezvoltare de mai mult timp, daca esti in mentenanta.
Daca esti pe un proiect in faza incipienta normal ca nu vei incepe proiectul cu framework-ul/ librariile vechi de 2 ani fiindca pe alea le stii. In majoritatea cazurilor versiunile sunt legate intre ele, iei ultima librarie de care depind alte librarii si vezi ca ceva mai vechi nu merge cu ceva mai nou, deci totul trebuie sa fie nou. Foloseai rxjs si acum sunt signals, bad luck sau o librarie inainte era cu plugin-uri si acum e cu setare declarativa, bad luck. Documentatia la libraria veche dispare sau e mai greu de gasit…
Daca esti pe un proiect in dezvoltare, ai cateva provocari in functie de marimea proiectului, in special pe CI/CD. Cu cat creste mai mult cu atat iti dai seama ca la un anumit punct devine un chin si te muti pe alt proiect sau cauti solutii precum schimbarea webpack-ului cu vite/esbuild…, tool-uri care iti ruleaza testele doar pe ce s-a schimbat s.a.m.d.
E posibil sa ai un proiect la care niciodata sa nu dai de probleme folosind aceeasi librarii, dar e posibil sa vina un feature unul dupa altul la care mai bine treci pe o versiune noua ca oricum trebuie sa implementezi acelasi lucru… (e.g. se scot plugin-urile dar tot ce faceai tu cu plugin-uri custom s-a inclus in librarie intr-un mod sau altul)
Dar e posibil si sa ai un proiect care inainte sa fie livrat clientului va fi scanat de un tool automat care cauta vulnerabilitatile/bug-urile la fiecare dependinta si nu iti da ok-ul pana nu le rezolvi pe toate. Ce faci ? Iti dai demisia ca nu mai poti livra sau devii frustrat ca inveti ceva nou la n luni (mai bine zis random, ca poti sa ai probleme saptamanal daca faci release des) ?
Toate proiectele care platesc bine au oameni responsabili de cybersecurity/code quality si nu iti vor permite sa dai clientului ceva ce are vulnerabilitati. (si de multe ori sunt breaking changes chiar daca semver spune diferit)
Daca ai un tool precum RenovateBot pe proiect o sa vezi ca iti face un MR automat cam zilnic fiindca s-a schimbat ceva. Daca trec testele poti sa dai merge, dar daca nu trec faci refacturare sau il ignori. (daca poti, ca poate vine ordin de mai sus ca toate dependintele sa fie up to date)
Cel mai dureros pe backend e kubernetes, stiu ca sunt echipe care nu sunt obligate sa il foloseasca, dar cam toate proiectele mari il implementeaza si nu e neaparat rau, dar e complicat si schimba total arhitectura in cazul microserviciilor. Plus fiecare cloud are ceva specific si se tot schimba, nu poti sa ai un singur deployment pentru toate.
Iar nu in ultimul rand ai factorul uman, mereu exista riscul ca sa angajeze pe cineva mult mai senior ca tine care a lucrat cu o anumita librarie/tehnologie si nu e un lucru rau, dar se schimba iarasi uneltele/tehnologiile fiindca asa vrea technical lead-ul/management-ul… Cateodata nu se schimba uneltele ci pur si simplu trebuie tu sa inveti ceva diferit de ce faceai inainte, cam mereu cand vine cineva nou in echipa. Bine daca esti in aceeasi echipa de 10 ani nu se pune problema.
Nu înțeleg de ce vă mai bateți capul. Oricum o să rezolve ChatGPT totul în curând
Acum, serios vorbind…
Dacă lucrezi într-o echipă în care se schimbă totul la fiecare 6 luni sau mai repede cred că se ajunge destul de repede la burnout sau îți iei adio de la viața personală.
Dacă lucrezi într-o companie în care nu se schimbă nimic de la an la an, pleacă înainte să devii irelevant pe piața muncii.
Am lucrat în agenții în care adăugam ceva nou fiecare 2-3 luni, dar de obicei noutatea era o mică parte din tot procesul. Nu schimbi totul dintr-o dată. Și proiectele vechi rămâneau pe tehnologia veche, că nu plătea nimeni upgrade-ul. Era destul de obositor și ajungeai repede să ignori ce nu era în zona ta de interes (lucrai backend și ignorai tot ce schimba pe front că era prea mult să mai ții pasul, învers era la fel). Sau tratai totul cu superficialitate, că nu aveai cum să aprofundezi nimic…
La firma actuală e la fel, doar că lucrurile se mișcă ceva mai încet. Nu suntem agenție, avem proiecte proprii (micro-servicii). Schimbăm tehnologii majore și rescriem rar, însă cam o dată pe an avem ceva total nou. Toate proiectele care funcționează bine și n-au nevoie de schimbări sunt ținute la zi cu dependințele și eventuale bug-fix-uri, dar în mare parte le lăsăm în pace.
Personal sunt împotriva schimbărilor radicale dese din mai multe motive:
Mă încântă foarte mult proiectele făcute fără briz-briz-uri, unde faci update la dependințe ani de zile și nu e nevoie să faci nimic altceva. Dacă ți-e frică să faci update-uril la dependințe, atunci fie implementarea e de rahat (nu urmează best-practice-urile pentru tehnologia respectivă), fie dependințele sunt de rahat (imature).
Până la urmă dacă vrei să urmărești tot ce trendy, treaba ta, însă trebuie să ținem cont că fiecare din noi are o toleranță diferită pentru asta și poți face viața nasoală colegilor dacă nu sunteți pe aceiași lungime de undă.
Un raspuns foarte bine articulat, se vede ca ai experienta cu proiecte enterprise.
Se schimba mult prea des.
Cand am inceput colaborarea cu ultimii clienti trebuia sa lucram cu CakePHP 2. De ce? Pentru ca erau multi programatori ieftini angajati si cumva trebuia clientul sa-i oblige sa lucreze “la fel”.
Cu timpul s-a demonstrat ca nu conteaza limbajul sau framework-ul, un programator habarnist tot va face o mare porcarie. Dar deja compania se baza pe o seama de aplicatii care erau scrise in CakePHP 2. Si atunci apare Cake 3. Bibliotecile incep sa migreze catre noua versiune si noi trebuie sa ne conformam desi clientii nu prea inteleg de ce trebuie schimbat ceva care merge.
Apoi apar versiunile 3.1, 3.2, 3.3 - fiecare schimba cate ceva si tot apar metode definite ca deprecated. Dupa ce ne-am chinuit sa refacem totul, acuma felul in care se incarca modele se schimba, locul unde definim constantele se schimba, felul in care se incarca plugin-urile incepe sa difere. Si tot asa.
Apoi trecem de la MariaDB la MySQL 5.6. Dar mai incolo trecem de la 5.6 la 8. Nu mai merge autentificarea la fel, nu mai merg query-urile cu GROUP BY la fel. Alt timp pierdut pentru a ne adapta la versiunile noi.
De anul trecut un coleg ne-a fortat sa facem proiectele in Angular. De atunci au aparut cel putin 3 versiuni diferite de Angular. Colegul a plecat dar noi am ramas cu niste produse uriase care acum neaparat trebuie facute in Angular.
E groaznic. Mai ales ca nici o schimbare nu e relevanta pentru lumea reala. S-a schimbat felul cum functioneaza ORM-ul. Pai, nu-mi pasa ca pot scrie query-urile de mana. Ca uite ce usor e sa faci relatii intre tabele si apoi sa faci query-uri complexe. Nu am nevoie, stiu sa scriu RIGHT/LEFT/INNER/OUTER JOIN-uri singur. Nu am nevoie de logging, caching, tot felul de repo-uri pentru constante, le pot scrie eu.
De fapt cele mai rezistente aplicatii au fost cele scrise fara nici un framework. Alea au rezistat zeci de ani. Mi-am facut eu controller-ele, modele, view-urile, caching, logging, etc. si alea nu le-a mai schimbat nimeni.
Suportul pentru o versiune, in general, nu se limitează la perioada de timp cât este cea mai recentă.
Heroku are o metodă foarte bună prin care își lasă utilizatorii să stie la ce se pot aștepta. La NodeJS au un support plan bine definit.
Cine vrea să schimbe o librărie doar pentru că e nouă si e mai bună decât cea integrată, din punctul meu de vedere greșește.
Mi se pare mai bine să extinzi o librărie la care ești expert decat să o înlocuiești cu una noua, mai bună, dar la care nu știi exact la ce să te aștepți.
Nu se gasesc dependinte cu long term support care sa nu se schimbe radical in cateva luni?
Vezi ca depercated nu inseamna hype sau ca se schimba prea repede. O metoda depercated iti functioneaza in continuare asa cum te astepti. In Java sunt metode depercated destul de batrane. Chiar si evolutia limbajului este facuta cu a pastra niste lucruri compatibile. Cel putin 2 ani de la anuntul ca X o sa fie scos.
La MySQL daca treci de la 5.7 la 8. da. Acolo s-ar putea sa ai probleme cu niste lucruri. Si noi am ne-am lovit de acele lucruri
Din punctul meu de vedere toate aceste schimbari sunt motivate de necesitatea de a pastra ecosistemul respectiv viu. Cam toata lumea a trecut la cicluri de dezvoltare cu un release major la fiecare 6/12 luni cel mult si astea de obicei implica modificari/ajustari in codul propriu, vezi si platformele traditionale enterprise gen C#/.net de la .net core au accelerat ritmul si au o cadenta bine definita cu tot felul de chestii noi adaugate la fiecare release major.
Acuma ca e bine sau rau asta nu stiu dar e o directie clara in care se indreapta industria.
Pentru mine e o problema. Limbajul de programare si framework-ul, daca e “sa ajuti”, trebuie sa fie batute in cuie si sa nu se mai modifice pentru vreo 10 ani cel putin.
Ciclul de dezvoltare a unei aplicatii e de minim un an, pana iei primii clienti sunt 2 ani si pana ajunge sa fie matura sunt vreo 5 ani. Daca in timpul asta tot se schimba ajungi doar sa scrii cod sa inglobezi modificarile si partea de business ajunge la un amarat de 20% din dezvoltarea propriu-zisa.
Ca aplicatiile single-page arata si se misca repede, nu comentez, dar la o aplicatie unde sa ai 100 de clienti business inseamna ca esti deja miliardar, timpul de generare a unei pagini e de ordinul a cateva milisecunde in PHP de exemplu - sunt niste baze de date minuscule. Asa ca SPA-ul e overkill de departe.
Avem un panou de control, are vreo 60 de entitati si cea mai mare baza de date e de 13 MB - si aia e tabelul de jurnalizare a operatiilor efectuate.
Pune-ți ideile într-o carte sau ceva, să fie mai structurate și mai contextualizate.
Cred ca pe la 30% din efort e facut sa tii ecosistemul in viata si compatibil cu versiunile componentelor sale. Incepand cu distributia de linux care se schimba prea des si pachetele care nu mai merg pe versiunea veche, ca e greu sa intretii un pachet pt x versiuni. Apoi versiunea noua de x nu e compatibila cu versiunea lui y, dar daca updatezi y nu ze mai pupa cu z. Si toooot asa.
Si eu inca am o oarecare aversiune fata de toate rahaturile sclipitoare care apar si dispar dupa o vreme. Nu introduc tehnologii de dragul noutatii.
Pe clientul final, daca merge si ii rezolva problema, il doare fix la basca daca e scris in fortran, assembler, rust sau e o maimuta care scrie repede un html cand apasa el un buton.
Ce exemple aveti de tehnologii/versiuni ce a trebuit sa le schimbati dupa prea putin timp? Si care nu au fost usor de innoit.
Nu cred ca ar trebui sa ne sperie schimbarile. Daca ni se potrivesc si ne simtitm siguri pe noi le adoptam, daca nu, mergem mai departe cu ce avem. In cadrul oricarui proiect e mai importanta stabilitatea proiectului si mai putin stabilitatea unei tehnologii. Proiectele trebuie sa functioneze, iar cei responsabili de stabilrea unei directii in proiect trebuie sa isi asume schimbarea doar cu sprijinul echipei de lucru. Pana la urma totul este bazat pe alegeri si fiecare e liber sa decida pentru el. Eu mereu am incurajat pe cei care au idei bune si inovative.
