My 20 Year Career is Technical Debt or Deprecated

Internet De Citit / De Vizionat
21

Da, l-am intalnit la incarcare de fisiere in object storage, incearca sa incarci un folder urias cu poze in S3 sincron.
L-am intalnit la microservicii, primesti ceva mesaj asincron pe redis/message bus si trebuie sa faci ceva si emiti si tu un mesaj, procesezi o plata/ o imagine/ un video, dai status intermediar, trimiti fiecare pas intr-un server de log/tracing, salvezi intr-o baza de date, salvezi si intr-o alta baza de date ceva id de referinta, trimiti la gateway raspunsul pentru client, trimiti un email, l-am intalnit la validare de formulare care iau date de la 5 servicii diferite prin dropdown-uri.

L-am intalnit la API-uri precum Google Sheets, care limiteaza numarul maxim de date pe un request, trebuie sa faci batching asincron ca sa nu atingi limitele si sa fie in timp util.

In cazul notion.so iei/scrii datele din pagina pe linii.

Stiu ca si php avea curl, are guzzle, dar eu fara sa ajung in afara php-ului nu cred ca le intelegeam nici pana azi. In special daca scriam plugin-uri la wordpress… Sigur ca exista solutii, dar trebuie sa iesi in afara sferei in care e 80% din domain knowledge in PHP si sa te duci inspre ce e si la altii, by default, de mult.

1 Like
22

link direct pe slide-ul cu raspunsul

4 Likes
23

eu am inteles astea cu folosind php. chiar destul de repede.
probabil problema nu-i la limbajul de programare in sine.

24

Dupa cum am scris in primul raspuns, eu am renuntat la PHP din cauza proiectelor, nu prea inveti lucruri dificile, nu prea aveam de la cine invata. Am invatat cateva lucruri interesante de pe forumuri de hacking, dar cam atat, nu cod frumos sau cum se scrie/intretine o aplicatie. Standardele/composer au aparut dupa 2 ani dupa ce eu eram mare fan JS/m-am apucat de invatat JS/Express/Node.JS.

E un limbaj de coders, voi posibil il folositi la un nivel mai inalt, dar mie nu mi-a placut in ce trebuie sa ma bag ca sa fac si bani din PHP. (ecommerce era cancer ca si domeniu si restul nu prea plateau) Daca treci de la C++ la PHP, da e un limbaj ok, dar daca e primul limbaj pe care l-ai invatat nu te prea invata nimic bun, era foarte foarte practic si accesibil cu LAMP, atat.

25

Eu nu înțeleg cum omul ăsta crede că el este definit de codul pe care îl scrie. Codul are o logică în spate, care poate fi implementată într-un fel sau altul în alte limbaje. Este evident că dacă lași câțiva ani să treacă peste cod fără să-l actualizezi, într-un final o să fie deprecated.
Văd că s-a pornit aici o dispută php-vs-world. PHP este un limbaj vechi dar încă folosit. Indiferent cât nu le place unora (nici mie în mod deosebit), o să mai fie prin zonă o perioadă bună…

I’m sorry but I don’t consider myself deprecated, now nor in the future…

4 Likes
26

Explorez varianta de a scrie un proiect cap coadă, site în speță, de o dimensiune mai mică… Ghici ce, în python nu este fezabil, este overkill. PHP este cel mai bun pentru asta.

I don’t care about the language, I just want to get the job done, și preferabil să nu-mi expire buletinul în acest timp.

27

Da, chiar am trecut de la C++ la PHP. De la HWND, hInstance, wParam si lParam si, God forbit, MFC.

28

Unrelated, dar prima versiune de Redis

Cod din 2009, dar poate functioneaza si acum :grin:
Discutia hn

29

Cred că ar trebui clarificat ce înseamnă tehnologie moartă.
In principiu nicio tehnologie nu moare, dar la începutul unor noi proiecte mai serioase unele nu mai sunt luate in calcul.

30

Important este sa ai un plan de dezvoltare durabil, de lunga durata. De multe ori am intalnit proiecte dezvoltate de care nimeni nu se mai atinge pe urma x ani si care “se strica” in timp iar dupa 5 ani se ajunge la un rewrite de la zero care din punctul meu de vedere e mai costisitor decat sa faci mentenanta periodica (practic distribui timpul de rewrite pe o perioada mai lunga si ai codul la zi la o calitate inalta, ca si timp nu cred ca se face prea multa economie in nici una din variante).

Aceeasi problema am observat si la proiectele facute cu fonduri de europene, de exemplu se face un proiect pentru un parc, totul e ok dar nimeni nu gandeste/bugeteaza intretinerea parcului pe urmatorii 5 ani si ajunge ca totul sa se distruga foarte repede.

Dezvoltarea durabila este cheia.

31

offtopic: problema principala acolo e de fapt ca nu ai voie sa faci modificari un nr de ani dupa.
deci nici dezvoltari utile.
da, asta nu modifica intentia celor care le fac (si care nu e mereu cea mai buna).

1 Like
32

Continuare offtopic: am fost in Bulgaria recent sa vad o pestera si acolo era un panou cu “audioguide la adresa …ro”. Am dat play pe pagina web si… nimic, nu functioneaza playerul. Pe pagina sunt si 2 butoane faine, show/hide left side si right side, prima oara cand am vazut asa ceva, care arata/ascunde coloanele cu reclame. Proiect facut prin fonduri europene, din 2016, de o firma din Slatina, si care a costat 700000eur. La o cautare rapida am dat de un document despre tiparirea unor pliante pentru proiectul in cauza, castigat de aceeasi firma, pentru 80000 eur, iar ofertantului nu i s-a cerut garantie pentru participare, nici pentru buna executie, nici dovada ca are capacitate profesionala. Cam asa se fac proiectele cu statul.

1 Like
33

Eu sincer cred ca eventual, cu o versiune viitoare de PHP, vom avea cel putin o naveta spatiala care sa foloseasca PHP pentru a zbura. Chiar daca doar ca un proiect proof-of-concept.

Dupa parerea mea, technical debt sau deprecated nu conteaza, atata timp cat ai rezolvat o problema existenta si ai adus un plus-valoare. Sigur, ideal ar fi sa facem produse care sa fie usor de intretinut si reparat pe viitor, cu cat mai multe comentarii relevante, si cat mai multe elemente plug-and-play pentru a evita vendor-locking si pentru a putea repara mai usor unele probleme.

Dar, din pacate, idealul ala costa mai mult, si uneori poate duce la un plus-valoare negativ, sau mult mai mic decat daca se ignora problema si se trece la alt sistem peste ceva timp (inclusiv rescriind aplicatia de la zero, daca e nevoie). Uneori e mai profitabil si sanatos ca pur-si-simplu sa trecem peste. Si, cum s-a mai spus, daca nu dezvolti platforme, sau aplicatii mai si populare pentru consumatori (i.e. wordpress), cel mai probabil nu o sa te poti lauda la pensie (sau peste ceva ani) ca “am facut cutare aplicatie” sau “am facut cutare functionalitate pentru cutare aplicatie”.

Click aici pentru a citi: Ceva text aproape off-topic, totusi partial on-topic. Ar mai fi si posibilitatea creeri de straturi de traducere (translation layers), precum Proton traduce instructiunile de Windows pentru Linux, spre exemplu, care sa se dezvolte constant pentru limbaje de programare, astfel incat sa se poata rula cod mai vechi in versiuni mai noi ale limbajului (i.e. php5 ruland in php8 cu modificari minore (i.e. schimbatul extensiei, adaugarea de require_once-uri, etc.), ideal), care ar putea evita ca un cod sa devina deprecated. Dar deja dau in off-topic, asca ca ma intorc on-topic.

Aici ar mai putea fi o solutie, care cred eu ca va aparea peste cativa ani, si anume inteligente artificiale care sa poata repara/updata codul respectiv. Vazusem intr-un video ca ceva developeri de la OpenAI ziceau ca ChatGPT 3.0 (prima la care a avut publicul acces) ar avea varsta psihologica de 6 ani, versiunea de 4.0 ar avea varsta de 9 ani (de unde si incercarile de manipulare) si ar intelege (in sfarsit) matemtica, ambele fiind direct corelate cu numarul de neuroni virtuali (aka. parametrii). Cred eu ca se va ajunge in cativa ani la varste psihologice de sute de ani, motivul principal pentru intarziere putand fi o crestere exponentiala a numarului de neuroni virtuali necesari si complexitatea algoritmilor necesari ca AI-ul sa inceapa sa inteleaga si sa produca imagini si video-uri.

Si inainte sa ziceti, nu, nu am generat textul asta cu ChatGPT, chiar l-am scris eu.

1 Like
34

Mi se pare ca incurci termeni si nici nu inteleg prea bine ce vrei sa spui.

35

Comentariul acesta va fi mai lung, asa ca probabil veti vrea sa sariti complet peste el.

Pe scurt: Noi rezolvam probleme, sau “scriem cod frumos”? Pentru ca, de multe ori, mai ales la scala mica, cele doua sunt incompatibile, sau cel putin incompatibile cu cerintele de timp si fonduri/bani ale clientului.

Pe lung:

Technical Debt si Deprecation apare ca parte a procesului de rezolvare a problemelor, indiferent de domeniu. In unele domenii, avansul tehnologic si trendurile operationale rezulta in schimbari mai mari decat in alte domenii.

Spre exemplu, in agricultura, mai nou se foloseste drip-irrigation, in loc de umplerea cu apa a unor canale in fiecare zi sau o data la cateva zile. Astfel, canalele de irigare, care folosesc mai multa apa decat drip-irrigation, dar care nu folosesc furtunuri de plastic, genereaza technical debt diferit fata de drip-irrigation. Picurarea genereaza technical debt prin necesitarea intretinerii furtunurilor de plastic, a legaturilor dintre mai multe furtunuri de plastic (joins/junctions), si a motorului. Canalele de irigatie genereaza technical dept prin necesitarea intretinerii canalelor, pentru a asigura ajungerea apei la toate plantele din jurul canalului de irigare, a motorului, a “portilor” canalelor de irigare (daca se folosesc in locul lasarii furtunului in canalul/santul de irigare), si a furtunelor care duc apa de la pompa pana in canalul de irigare.

Fiecare din acele parti are o rata diferita de degradare (decay), fiecare necesita altfel de mentenanta (inclusiv motoarele, deoarece irigarea prin picurare necesita un motor mai mic), si fiecare se va strica diferit. In functie de cum organizezi canalele de irigare sau furtunurile de picurare, iti va fi mai usor sau mai greu sa obtii recolta, si schimbarea modului de recoltare si plantare poate cauza, de asemenea, probleme.

In mod similar, in programare apar limbaje noi, probleme noi, solutii noi, erori noi, fix-uri noi, trenduri noi (i.e. framework-uri noi), etc. Similar, in mecanica auto apar diferite parti, diferite necesitati (i.e. calculatorul de bord care sa controleze si coordoneze partile mecanice si electrice), diferite probleme si solutii, si diferite trenduri.

Din acest motiv spuneam ca technical debt apare ca urmare a rezolvarii unei probleme. Pana si pe vremea epocii de piatra, aparitia de tehnologii noi (precum agricultura) a dus la schimbari majore si technical debt (daca nu intretineai terenul agricultural, puteai sa nu obtii recolta.

De-asta cred ca nu ar trebui sa ne concentram atat de mult pe a nu crea technical debt, sau produse deprecate, cat ar trebui sa ne concentram pe a comenta suficient (cu risc de a comenta excesiv) codul produs, pentru a scadea costurile asociate cu repaprarea codului deprecated sau codului cu technical debt.

Iar aici intervine conceptul de vendor-locking. Daca ne structuram codul astfel incat sa fie mai usor sa eliminam sau inlocuim bucati majore de cod, inca de la inceput, cresc sansele ca aplicatiile create sa fie structurate mai “curat”, mai usor de inteles, mentinut, reparat, refactorizat, si chiar refacut folosind technologii moderne.

Si acum revenim la ce a zis mai sus @isti37 :

Cu alte cuvinte, putem scrie cod “cu picioarele” indiferent de limbaj si framework. Unele limbaje si framework-uri fac mai usoara standardizarea codului si urmarea unor standarde de calitate, insa nu asigura aceste lucruri.

Totusi, atata timp cat dezvoltatorii pun accent pe urmarea standardelor de organizarea a codului in mod citibil si usor de inteles, mentenanta si repararea devin mai usoare, portarea de la un vendor la altul (i.e. trimiterea de mail prin MailChamp in loc de Gmail SMTP) devine mai usoara, si tot asa.

Problema e ca, in viata reala, urmarea standardelor acelora costa atat timp cat si bani. Iar daca urmarea standardelor duce la pierderi mai mari decat castigurile cauzate de codul creat/modificat, atunci devine mai economic sa scriem cod “cu picioarele”, si sa il rescriem de la 0 atunci cand nu il mai putem repara. Mai ales daca produsul produce din ce in ce mai multi bani in timp, astfel punand la dispozitie fonduri mai mari pentru mentenanta/intretinere/reparare, astfel scazand investitia necesara inaintea lansarii produsului si inaintea recuperarii investitiei initiale a produsului.

Degeaba scriem cod care ruleaza si azi fara probleme, daca nu e folosit de nimeni VS degeaba scriem cod care rezolva probleme la timpul lor, daca nu ruleaza si azi fara probleme.

Daca inca nu ai inteles, presupun ca ar fi mai eficient sa discutam pe privat, ca sa nu umplem aceasta discutie cu mesaje irelevante sau doar marginal relevante.

36

@Sapioit_throwaway_01 niște chestii:

  1. contul @Sapioit este deblocat de cel puțin un an, poți reveni cu încredere la ăła
  2. nu este nevoie să ai păreri despre orice, în blocuri interminabile de text, despre noțiuni pe care nu le stăpânești sau nu le cunoști decât din cărți.
  3. orice comentariu scris de tine cu mai mult de 2-3 paragrafe sau de o lungime ne-rezonabilă va fi șters.
37

Apropo, un proiect bazat pe ceva nedorit de oameni noi moare fiindca nu mai gasesti oameni care sa lucreze la ceva in buget si la un moment dat tragi linie si refaci totul de la 0. Am o oarecare presimtire ca si multe proiecte vor muri o data ce noua generatie de programatori vrea doar React…

Asta fara sa fie absolut nici o problema cu limbajul/frameworkul/etc. Pur si simplu daca ii spui cuiva care a terminat facultatea acum de PHP la interviu o sa sara la urmatorul interviu.

Nu e vorba doar de PHP, e valabil la orice framework de JS mai vechi, orice nu e in trend si nu e platit regeste.

Mi-am dat seama ca omul e principalul motiv pentru care ceva ajunge deprecated, in special cand vorbim de cod cu multe teste, bine gandit…

2 Likes