Vorbește despre vendor lock-in.
Vendor lock-in e cel mai ignorat antipattern din păcate.
Păcatul crește cu atât mai mult cu cât unii își pun la bătaie nu doar produsul, ci și cariera.
“Programator wordpress”, " programator angular", s.a.m.d., o groază de bălării.
Când le spun novicilor să tragă frumos un anticorruption layer între business logic și framework/library/cms, orbiți fiind de dragostea față de scula lor preferată, zic că sunt nebun.
Ontopic: E foarte bine ca a scris chestiile astea, ca sa le putem imprastia si noi la cei care intra plini de entuziasm in lumea developmentului si sunt pe cale sa pacatuiasca in felurile in care, pana la urma, am facut-o si noi.
Offtopic: imi place de @iamntz cand pune linkuri, are surse bune.
Am scris și pe blog și pe forum cum găsesc articole. 
Provocarea constă în a alege ce pun și ce nu pun pe forum; dacă aș pune tot ce găsesc, aș transforma forumul într-un director de link-uri 
Abstractizand framework-ul in care lucrezi, pierzi nu numai sansa de a-l invata, dar mai incurci lucrurile si cu un alt layer, deseori inutil. 80% din cazuri nu merge sa fii intr-atat de defensiv. Mai mult strici. Layer peste layer peste layer de “dar daca…”.
Nu e vorba neapărat de un layer peste layer peste un alt layer.
Programând exclusiv în limbajul X sau Y tot un fel de vendor lock in este. Uite aici un astfel de exemplu.
Nu zice nimeni să fii cel mai bun în zece limbaje, dar măcar să poți scrie câteva linii de cod în 3-4 limbaje tot ar fi util.
iamntz, etern impaciuitorul.
O gramada de lucruri ajung sa devina asa ceva. Voi folositi “vendor lock-in” peiorativ, dar uitati ca asta e miezul specializarii. E “specializare” cand totul merge bine, si devine “vendor lock-in” cand s-a dovedit ca ai ales prost (ele fiind mereu aceleasi).
Acum reformulam, folosind sinonimul: ca sa evitam specializarea, abstractizam acel lucru, il debarasam de specificitati, si ramanem cu un lucru mai general. Ok, in cazul asta, cine pana mea mai devine specialist? Sau promovati crearea unor jack-of-all-trades buni in totul si nestiutori in nimic, a la romanica?
Lipsa de moderatie este, prin definitie un lucru negativ: tre sa sa compromiti intre abstractizare si specializare - tehnologic si carieristic. De ex, sa pui un layer de abstractizare in marea majoritate a aplicatiilor wordpress este ridicol dpdv functional, si este la fel de ridicol - dar acum dpdv pedagogic - sa ceri asta juniorilor. In librarii extensibile, acolo-i invers.
Imi imaginez ca asa s-a spus si despre cei specializati in C: “Invata mai multe limbaje, ca nu se stie”. Bullshit. De 2 decenii incoace, pure, unadulterated bullshit.
Internetul (si lumea) e plina de oameni inteligenti care spun lucruri inteligente, dar ele nu sunt neaparat corecte sau aplicabile tuturor.
Din formularea ta deduc ca nu vezi un astfel de anticorruption layer in fata ochilor, cod concret. Caci daca ai vedea, nu ai emite astfel de afirmatii fara sens.
Nu o sa iti explic tie ce si cum, pentru ca esti indragostit si nu vei vedea oricum mizeria.
O sa explic pentru cei care risca sa creada afirmatiile fara sens pe nemestecate:
Cand scrii un anticorruption layer, ai nevoie de expertiza cu acel framework/tehnologie. Ceea ce inseamna un astfel de layer este pur si simplu o interfata (sau o colectie de interfete) ce formeaza o “membrana” care protejeaza biblioteca ce implementeaza business logic (cea care aduce plus valoare intr-o afacere) de alti actori externi care incearca sa te domine, sa te controleze.
De priceput tot trebuie sa te pricepi la acel framework/library, dar nu as numi specialist pe cineva care stie un API. Pentru mine specialist e cel caruia ii pui in brate orice tehnologie, si el e capabil sa se adapteze in functie de cerinte.
Ce fel de specialist e ala care stie sa exprime idei doar in PHP, si daca ii pui Java in brate, il faci K.O.? Pentru mine valoarea unui astfel de specialist e zero barat.
Foarte adevarat.
Ce spun eu nu este fezabil pentru freelancerul care lucreaza pe firmituri, care scrie la gramada o solutie pentru o problema, si apoi nu-l mai intereseaza nimic, ci pentru programatorul care trebuie sa isi menteneze si sa isi extinda creatia pe parcursul a zeci de ani.
Cu totii suntem victima unui vendor lock-in, problema e la ce nivel de abstractizare stopezi controlul pe care altii il au asupra ta?
Daca tu lasi modul de abordare al unui framework sa-ti domine business-ul, unde mai ai tu loc liber de manevra, de inovatie?
De acord - ala de stie sa faca API-ul trebuie sa cunoasca humusul, dar restul care ii vor folosi API-ul ce vor invata? Acel API. Si iata un alt vendor lock in. Sau o specializare in acel custom API. Primul a invatat mult. Restul dupa el, daca invata ceva, invata cum sa faca si ei layer-e, sa incarcereze alti viitori si fraieri colegi. Si uite cum ajugem la lovitura sub centura a carierei despre care vorbeai. Numai ca acum am ajuns la ea prin layer-ul tau de care si tu te-ai indragostit (e plin de love forumul asta :P).
Ah, ok. N-am stiut ca thread-ul asta foloseste “expert in orice” ca definitie pt “specialist”. Tu spui ca un specialist stie orice? Asta-i contradictie. Intr-un proiect PHP, un specialist Java nu valoreaza prea mult. Ar fi valorat “zero barat” daca PHP si Java n-ar fi fost asa asemanatoare. Cu cat devii mai generic, cu atat notiunea de specialist devine superflua, fiind in opozitie.
Calmeaza-te, ca esti in mind lock si nu mai reusesti sa citesti cu mintea clara ceea ce scriu:
Incerci sa pictezi in mod gresit ideea de a sti mai multe (bine) ca “a nu sti de nici unele”.
Un om apt dpv intelectual poate stapani lejer mai multe paradigme de programare, mai multe limbaje, mai multe framework-uri, si poate invata destul de rapid orice alt limbaj/framework/paradigma.
Stiu, omule. Eu vorbeam despre extremele de a invata fie ceva prea generic, fie ceva prea specializat.
Niciuna nu-i buna. A abstractiza cand trebuie sa inveti si a fi low-level cand trebuie sa protejezi de schimbari sunt ambele urate.
PS: Mi-am dat seama de-o chestie scriind asta: cei mai norocosi, cei-din-ambele-lumi, sunt darlaii care sunt la inceputul unui proiect care foloseste un framework/cms. Ei trebuie sa creeze custom shit, API-uri si layer-e peste fw/cms. Astfel, invata si sub-sistemul, si lucruri generice. Restul, care ajung mai tarziu, nu rumega decat lucrul primilor. Cel layer protejeaza numai business-ul, nu cunoasterea. Dar cui patron ii pasa de a doua? Aka “Uiti sql folosind Doctrine, dar tipii care au facut Doctrine is specialisti in sql. Unii au lock pe doctrine. Altii au lock pe mysql”.
Cand ii tragi un anticorruption layer peste (hai sa ii zicem caciulita), dai nume de interfete/metode relevante pentru business. Acele nume (ubiquitous language in termeni DDD) raman valabile pe durata intregii vieti a businessului, indiferent de celelalte biblioteci folosite.
Sa zicem ca ai un shop online, si o biblioteca magica apta sa iti spuna plecand de la o colectie de produse, ce alte produse va dori sa cumpere clientul. Lui anticorruption layer ii pasezi o instanta de tipul Cart, si restul colegilor vor folosi acel Cart pentru a interactiona prin prisma lui anticorruption layer cu acea biblioteca magica.
In interiorul implementarii acelui anticorruption layer specific librariei date trebuie in continuare sa fii specialist in lucrul cu acea biblioteca, dar nu si in afara: colegii pot folosi layer-ul.
Da, ai in continuare nevoie de experti “la acea biblioteca”, dar in biblioteca centrala care apeleaza acea vendor library nu esti strict legat de acel vendor, daca dai de ceva mai bun, poti inlocui acea librarie cu o alta, si scrie un nou adapter pentru noua biblioteca, fara a modifica nimic in biblioteca centrala.
Te poti debarasa usor de vendor, putand sa inovezi mai usor, sa combini si sa recombini componente in functie de cele mai noi inovatii.
Adaptabilitatea aceasta aduce plus valoare, vendor lock-in aduce technical debt.
Vendor lock-in nu are treaba cu technical debt. Lockin nu este in sine un lucru rau, ci este promisiunea unui lucru rau, din cauza ca aplicatia ta este rigida. Dar, daca cea rigiditate se bazeaza pe un sub-sistem super mega omg de stabil, pentru o perioada cel putin, nu-i nicio problema. Perioada asta poate sa insemne 2 luni sau 15 ani.
Si tocmai acea extensibilitate despre care vorbesti si cu care sunt adesea de acord, iti face aplicatia flexibila. Dar sa-ti pui caciulitza inseamna sa pierzi timp si bani. Si uneori nu este deloc profitabil. Sa faci acel “PossibleProducts” layer extensibil, cand in 90% din cazuri, stim cu totii ca nu sunt sanse realiste sa se schimbe implementarea originala, nu inseamna decat… cum ii spunea… premature optimization?
… La ceea ce am spus se mai adauga si testabilitatea. Vendor lock-in ingreuneaza destul de mult testabilitatea.
Tu vorbesti aici despre software in domenii putin competitive, nu despre software in care concurenta ridica mereu bara si ori te adaptezi ca business, ori esti mancat de viu.
Adaptabilitatea este un principiu economic la fel de valid precum este si “hai sa scoatem produsul mai repede”, despre care sunt sigur ca ai auzit. Aka deadline. Dar majoritatea intreprinzatorilor nu vor sa auda de adaptabilitate, fiindca aia inseamna schimbare. Schimbarea inseamna risc, timp si bani. In schimb toti vor sa auda ca vei termina aplicatia maine.
Si, cel putin pt marea majoritate a serviciilor, schimbarile tehnologice sunt niste detalii de implementare de care ei nu sunt afectati. Pt a-si vinde produsul, ei au nevoie de un site, nu de un site in angularjs. Vreau sa spun ca sunt sanse mult mai mari sa gasesti un client refractar in a crea layer-e de protectie, si receptiv in a termina mai repede. Neglijeaza adaptabilitatea pe barba lui. Nici nu conteaza, fiindca, din cate am citit, marea majoritate a companiilor dau coltzul in 5 ani. Ce rost mai are sa fie flexibili? Ei tre sa fie profitabili, NOOOOW! Yesterday!
Cred ca voi abordati problema din perspective diferite, de aceea si divergenta de opinii.
Exista oameni care fac site-uri. Mari, mici, nu are importanta. Asa vad ei problema. Fac delivery si apoi se muta la urmatorul proiect/client. Fac si mentenanta la ce au scris, dar nu traiesc cu munca aceea zi de zi in urmatorii x ani. In general ei sunt contractori sau angajati la o firma care se comporta ca un contractor cu clientii. Eu numesc acest tip de programare “siteuri la metru”, si nu o fac deloc din rautate, ci dintr-o concizie a exprimarii. Se alege o tehnologie specifica problemei (sa zicem Drupal pt CMS, sau Wordpress pt siteuri mici, sau Magento pentru shopuri), se antreneaza oamenii sa o stapaneasca, si se imperecheaza unul-doi developeri cu un designer, se livreaza proiectul, move on.
Alti oameni fac dezvoltare in-house. Adica sunt acolo, cu nevoia de business, 24 din 24, timp de luni si chiar ani de zile pana isis schimba jobul.Pe ei ii doare in fiecare zi o decizie tehnica nefericita, ei se lupta in fieccare zi cu technical debt. Si atunci vad altfel lucrurile, incearca sa prioritizeze diferit munca de zi cu zi si sa abordeze diferit modul de a scrie cod.
Eu, spre exemplu, nu pot fi contractor, nu am reusit niciodata sa intru in acel mindset. Adica mai “fac cate un site”, dar il abordez altfel decat cei care le fac la metu. Si imi ia si mai mult timp. In schimb am fost developer in-house in diverse locuri in ultimii 11 ani, si empatizez mai bine cu @flavius cand face unele afirmatii in acest thread. Nu vreau sa tragem concluzia ca un tip de tekkies sunt mai buni ca altii, vreau doar sa constientizam ca ei sunt diferiti. Si recomand calduros tuturor o experienta in-house de macar an, ca sa vedeti cat de diferita e lumea aceea.
Tu spui de fapt ca flexibilitatea este necesara in perioada de mentenanta, cand produsul s-a lansat. Adevarat. Produsele in-house au procesul de mentenanta mai intens. Dar inainte de lansare este munca de creare efectiva, unde, din pacate sau nu, lansarea rapida devina prioritara, din considerente economice. Nu este eficient sa te aperi a priori, ci iterativ, dupa lansare, si cand devine necesar. Cand costurile acelei defensive sunt neglijabile, se poate face dinainte, dar cand te apuci sa abstractizezi de dragul lui “dar daca…”, pierzi bani.