pentru că un request amărât acum înseamnă peste 6 luni logică de genul „back-off retry” sau logging mai avansat pe request-response pentru că API-ul extern nu se comportă cum trebuie și tot așa.
Nu mi se pare ok sa pleci mereu de la premisa ca peste 6 luni vei avea nevoie de mai mult sau de alt ceva. Depinde de scope-ul aplicatiei si de planurile cu ea. Sa te apuci sa dezvolti de la inceput o solutie super-scalabila si super-extensibila de multe ori poate fi timp si efort irosit.
Exemplu: comunicarea intre micro-servicii. Ai nevoie sa integrezi comunicarea cu un microserviciu (idk, scrii niste date, trimiti o notificare). Acum comunicarea se face prin api si te apuci sa faci o solutie super-ultra-mega cea-mai-cea. Peste x luni vine echipa care intretine acel microserviciu si iti zice ca ei de acum vor sa le arunci mesajele intr-o coada de unde ei le consuma.
MEREU tind să pic în capcana „oh, dar dacă va fi nevoie să… ceva?”. De ceva timp - să fie 2 ani - încerc doar să scriu codul cât să fie rezonabil de extensibil (e.g. încerc să extrag interfețe[1] doar dacă există mai mult de o implementare; de cele mai multe ori NU este).
Am aflat relativ recent că Storm are Extract Interface, care merge excelent ↩︎
Nu sunt de acord. Nu este nimic gresit sa folosesti cod facut de altii in proiectele tale cum nu este nimic gresit sa nu te intereseze ce este in spate (black box) pentru ca probabil scopul este aplicatia ta si nu o oarecare librarie. Oricum, la lucrurile serioase nu se foloseste chiar orice iti pica in mana si se face vendoring. Deci chiar daca pot sa fac o astfel de librarie nu inseamna ca trebuie sa si pierd timpul sa re-descopar roata. Asta se face ori daca scopul tau e invatatul ori in cazuri speciale de optimizare, altfel, da, poate fi o satisfactie personala dar nu e productiv si nu aduce plus valoare muncii tale.
Si uite asa devenim expert beginners in laravel sau alte shto-uri fara sa ne mai intereseze exact cum functioneaza shandramaua pe dedesubt.
Sa stii CURL mi se pare o chestie de baza. E un skill transferabil in orice tehnologie care are de a face tangential cu HTTP. Sa stii Guzzle insa, nu. Pentru ca azi lucrezi in PHP, maine poate lucrezi in Java sau GO? Ia vezi daca poti sa importi Guzzle si acolo.
“Nu e niciodata un request amarat”…Nu prea ai de unde sa stii asta. Si oricum nu inseamna ca nu poti refactoriza ulterior, daca chiar ajungi in situatia aia. Insa m-am saturat sa lucrez la abstractizari de care proiectul nu are nevoie niciodata.
Da, sa folosesti guzzle aici este premature optimization. Sa gandesti ca poate la un moment dat intr-un viitor incert aplicatia va avea nevoie de back-off si retry iar e premature optimization.
Lasa lasa nu fii rau, (@iamntz also @tacheshun ) ca m-am referit exact si foarte specific la nivelul de detalii pe care vrei sau nu vrei sa le treci in CV. A stii CURL unora li se pare important de trecut, altora nu, iar eu am subliniat doar faptul ca atunci cand treci in CV asa ceva e pentru ca nu stii mai mult. Am citit destule CV-uri cu formulari de genul “stiu CISCO” doar pentru ca au avut la facultate o materie in care se pomenea de asa ceva. Ca sa ma fac inteles, trebuie sa stii CURL cand esti intrebat, nu e si un detaliu de mentionat in CV. E mai clar asa ?
Eu insa ma refeream la urmatoarea situatie pe care am intalnit-o deja de cateva ori:
am de implementat un call catre x endpoint. Si in loc sa il fac repede incep sa analizez pe toate partile ca nu e doar un call amarat si hai sa facem si functionalitate de back-off and retry ca poate ne trebuie la un moment dat.
Chestia asta naste niste mici monstruleti in cod. Ca tot vorbim de technical debt atat de mult, complexitate esentiala + complexitate accidentala, etc.
Multi or sa zica ca e best practice. Ca e mai ok asa pe termen lung. Ca nu ne ia mult, etc. Dar extrapoleaza taskul de mai sus la 20-30 de use-case-uri cate are o aplicatie medie si imagineaza-ti ca la fiecare use-case din asta aplici aceeasi reteta.
La asta m-am referit. Sa imi fie cu iertare dar e de la caldura. Ne vedem la bere vineri.
