Ai dreptate ca cele 2 perspective difera in primul rand dpdv al mentenantei.
Dar mentenanta facem si inainte de lansarea produsului, atunci cand am codat pe scurtatura o anumita functionalitate si apoi trebuie sa facem o mica modificare.
Practic sunt scoli diferite de gandire. De aceea recomand stapanirea ambelor, pentru ca expunerea de argumente doar dintr-o singura perspectiva nu e benefica celui care o face. Pierde mai mult decat isi da seama.
Aplicatii mici actualizate rar, unde platesti technical debt rar, si in general il platesc altii. In general siteuri de prezentare, mici CMSuri.
Aplicatii medii si mari, care rezolva o problema de business din piata, care sunt intr-o continua miscare pentru ca trebuie sa ne adaptam la cerintele pietei. Aici e mai putin vorba de mentenanta, cat de nevoia afacerii de a pivota pentru a se mentine la suprafata.
Pentru astfel de aplicatii e chiar bine sa faci vendor lock-in, pentru ca il tii mai aproape pe client. E ca intr-o lupta corp la corp, in care il iei in brate pe inamic.
Cand vinzi firmituri, e chiar o tactica eficienta de a ii crea clientului nevoia de tine.
Depinde din ce perspectiva privesti, daca tu esti vendorul, sau daca tu esti vendor-uitul. Sau mai bine zis: care e raportul dintre cat de vendor esti, si cat de vendoruit esti de altii, caci toti suntem intr-o oarecare masura ambele.
Ceea ce spun eu e simplu: programatorii care sunt mai mult vendoruiti de altii, si vendoruiesc ei insisi mai putin, sunt programatori care isi pun cariera la bataie, pentru ca tind sa nu se adapteze asa de usor ca cei care sunt pur si simplu programatori “generici” capabili sa inghita orice vendor “dintr-o miscare”.
Iar un anticorruption layer este un astfel de mecanism care inlesneste inghitirea altui vendor, in loc sa te inghita el pe tine.
@flavius Anti-Corruption Layer pentru un framework/librarie? really?
Direct din DDD de Evans:
a) argumentul principal ce reiese de mai jos este ca utilitatea pattern-ului este pt. legacy systems
When a new system is being built that must have a large interface with another, the difficulty of relating the two models can eventually overwhelm the intent of the new model altogether, causing it to be modified to resemble the other system’s model, in an ad hoc fashion. The models of legacy systems are usually weak, and even the exception that is well developed may not fit the needs of the current project. Yet there may be a lot of value in the integration, and sometimes it is an absolute requirement.
b) exemplul dat este la fel - legacy software
Initially, the ANTICORRUPTION LAYER will accept the objects representing a shipment, convert them, pass them to the legacy system and request a booking, and then capture the confirmation and translate it back into the confirmation object of the new design. This isolation will allow us to develop our new application mostly independently of the old one, though we’ll have to invest quite a bit in translation.
Care este legatura intre Anti-Corruption si un framework? Iarasi imi suna a over-engineering si chiar sunt curios ce argumente ai pentru a implementa asa ceva din start sau cumva doar folosesti incorect terminologia.
La un moment dat Evans zice acelasi lucru:
An ANTICORRUPTION LAYER can become a complex piece of software in its own right.
P.S.:
software system - is a system of intercommunicating components based on software forming part of a computer system (a combination of hardware and software). It “consists of a number of separate programs, configuration files, which are used to set up these programs, system documentation, which describes the structure of the system, and user documentation, which explains how to use the system”
vs
software framework - In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or solution.
@dakull - un layer agnostic este bun nu numai pt un legacy, ci si pt a te feri de riscurile schimbarii.
Faptul ca acel strat este automat considerat in legacy-uri rezulta din tocmai acel fapt: urmeaza o schimbare majora.
Dar, in acelasi timp, acel layer poate fi considerat si inainte, tocmai pt a preveni nu numai un vendor lockin, ci si… legacy lockin(?) unde costul upgradarii devine mult prea riscant/costisitor.
Si tocmai aci-i legatura dintre layer si librarii: acelasi layer abstractizand mai multe librarii. Ce-i asa greu?
Crearea celui layer prematur este alta poveste. Costisitoare. Avantajelele unui strat protector sunt evidente. Serios. Lumea asta-i creata pe generalitati: de la regnul animal la the witcher 3. Dar l-am vazut de prea putine ori in munca efectiva sa-l consider pragmatic. Si din acelasi motiv pe care flavius il arunca impotriva mea: rapiditatea competitiei. Gotta get shit done. Il las pe flavius sa abstractizeze wordpress lucrand in wordpress.
PS: Conteaza prea putin daca a nimerit sensul lui “anti-corruption” layer sau nu. Stii la ce s-a referit.
My points is - daca tot urci la nivel de our glorious saviour un anume pattern macar foloseste termenul corect si citeste de unde a provenit apoi sell it as the next best thing since sliced bread.
Exista o gramada de small patterns pt. a face asta fiecare depinzand de context.
De vreo 10 mesaje încoace habar n-am despre ce vorbiți…
Mă bucur pentru voi că, în sfârșit, (credeți că) ați găsit un context în care să folosiți niște termeni pompoși pe care i-ați descoperit în nu-știu-ce cărți scrise de nu-știu-ce geniu, dar nu sunteți la un interviu de angajare și nu trebuie să impresionați pe nimeni.
Nici măcar nu este interesantă direcția pe care a luat-o discuția. Mult tam-tam pentru nimic, pentru că, la urma urmei, acel Anti-Corruption Layer nu este dect un termen pompos pentru wrapper. În alte contexte e numit Driver, în altele Adapter, dar la bază toate sunt același lucru: ascunzi sub preș gunoiul lăsat moștenire de alții.
Cât despre vendor lock-in, teoretic este de evitat deși în practică s-ar putea să fie mai rentabil în unele situații să faceți un compromis, așa că nu mai încercați s-o pictați albă sau neagră când situația este clar gri.
@IonutBotizan practic ai reiterat ceea ce am zis si eu in alta forma. /GG
on topic: atata timp cat inveti conceptele de baza din spatele programarii nu vei avea probleme in viitor ca dev. hello Cpt.Obvious! oricum tangentele au fost interesante
@dakull a mai explicat inca o data ce ziceam eu, in special partea cu axa timpului pe care celalalt antevorbitor o ignora - anticorruption layer devine anticorruption layer in timp.
Nu e ca si cum trebuie sa faci un efort in plus pentru asa ceva, o faci oricum cand respecti principii ca SOLID si code to an interface.
Ideea de wrapper e inrudita, dar nu e wrapper ci poate fi o intreaga colectie de interfete (de aici layer), deoarece asta iese cand respecti interface segregation din SOLID si code to an interface.
Un wrapper sau un adapter e o singura clasa.
Oricum s-a spus tot ce era de spus din punctul meu de vedere. Nu consider ca discutia a deraiat, ci articolul din postarea initiala a fost privit dintr-una din celelalte posibile perspective constructive.
Imi place dezbaterea, insa sunt in dezacord cu @IonutBotizan deoarece nu cred ca singurul moment cand folosim termeni de specialitate e acela in care trebuie sa facem impresie buna. E ca si cum am zice unui meserias sa foloseasca nivela doar atunci cand da proba de angajare.
Cred ca terminologia pe care o folosim exprima corect ceea ce trebuie sa transmitem, si ca nu trebuie sa coboram nivelul doar pentru a fi intelesi de mai multi cititori. Aceasta terminologie nu provine din nevoia de show-off a unora, ci din dorinta de a facilita comunicarea, prin denumirea exacta a unui context/situatie/solutie/etc. Pur si simplu nu mai inventam si noi aceeasi roata.
citind ce scrie aici as putea sa jur ca ar trebui sa vad doar cod care sa-mi depaseasca cu mult cunostintele. cumva totusi 70% din codul pe care-l vad e scris cu picioarele. nici macar banalul mvc nu-i respectat, ce sa mai vorbim de coruption layer de ala…
numa zic.
In caz de doriti sa fiti intelesi de toti cititorii, puteti face translatiile necesare dupa ce ati terminat ce aveati de spus in termeni high-end. Spre exemplu, cand mentionez anti-corruption-layer, pot face urmatorul lucru (notice the horizontal line):
Anti-Corruption Layer = in-app API, wrapper, or anything that helps to keep the code built in your app safe, with the minimum damage done to your app in the long-run
A good example of anti-corruption-layer for beginners is using multiple functions, each for the desired job, instead of having one big function containing all the code, making it nearly unreadable without spending too much time, unsustainable as the changes done to something need to be done in N places instead of just one, and pretty much a soon-to-be spagetti code, as DRY is not respected at all, going mostly for WET.
Si eu sustin cu inversunare idea evitarii specializarii in produse atat din punctul de vedere al carierei cat si din punctul de vedere al produsului. Nu m-am uitat la video, dar am citit in mare raspunsurile voastre, si sunt la tema cu subiectul. Iata ce am invatat eu in decursul anilor.
Efecte negative asupra carierei:
Produsele vin si pleaca - ai sanse 100% sa ramai fara cariera in urmatorii 10 ani. Prototype.js anyone? Cobol? FoxPro? Sa mai continui?
Va trebui sa te reprofilezi … foarte greu. Daca crezi ca iti este usor sa te reprofilezi de la Prototype.js la JQuery, deja ai trecut de pasul asta.
Traiesti in iluzia ca ai inteles programarea. Asta este ce vad cel mai des. Utilizatorii de framework-uri se cred programatori (scuze daca v-am ofensat, nu asta e scopul). Ei cred ca prin intelegerea unui framework pot face aplicatii durabile si valoroase. Un programator Drupal sau Joomla nu exista pentru mine.
Vei fi platit mediocru … forever.
Efecte pozitive asupra carierei:
Daca stii framework-ul care este pe val iti vei gasi loc de munca usor.
Vei lucra mereu in zona ta de confort.
O sa fi un robotel linistit si calm. Fara stres. Fara provocari. Fara multe necunoscute.
Vei avea un salar suficient cat sa nu iti bati capul cu ziua de maine … pana cand frameworkul dispare.
Efecte negative asupra produsului:
Produsele vin si pleaca. - Cand va trebui sa iti schimbi aplicatia veche de 5 ani scris pe template-uri de Velocity si Strut pe Spring vei intelege ce inseamna sa ai un layer care separa logica de business de logica de prezentare. Indiferent de numele acestui layer, el este esential.
In 99% din cazuri nu este nevoie sa intelegi un framework in detaliile sale intime. Sa inveti ceva asa in detaliu, sa investesti atat de mult timp in el, cu riskurile de la punctul 1), nu poate fi justificat din punct de vedere al proiectului, al companiei, al cheltuielilor, etc. Este economic nefezabil pe termen lung. Punct.
Daca mergi totusi pe idea framework-ului, va trebui sa angajezi oameni specializati in framework-uri. Daca schimbi framework-ul proiectului, va trebui sa dai afara echipa veche si sa angajezi alta echipa. Mai rau, daca trebuie sa mentii si proiectele vechi, va trebui sa ai doua echipe, sau una divizata. In consecinta nu vei putea sa profiti de capacitatile maxime ale angajatilor tai. Niciodata.
Efecte pozitive asupra proiectului:
Este intr-adevar mai rapid sa lansezi produse mici, care dupa aceea sunt abandonate. Desi este discutabil si acest lucru.
In urma experientei mele cu mai multe proiecte am concluzionat ca:
Refuz din start orice job care vrea specialisti in orice framework. So long and thanks for the fish. (ca sa citezi niste delfini)
Refuz sa lucrez la orice proiect care insista pe un framework si are un management ce refuza decuplarea business logic de framework sau orice alta librarie 3rd party.
Eu zic ca e suficient sa stii la nivel productiv 3 limbaje de programare: unul orientat pe obiecte, unul functional si unul procedural (sau modular cum se numea mai demult). Programatorii buni vor sti 2-3 limbaje din fiecare din cele 3 paradigme, lucru ce le va permite sa inteleaga filozofia din spatele paradigmelor si limbajelor, nu numai sintaxa.
Deci. Cine doreste sa lucreze cu mine? (<- publicitate ascunsa)
Concluzie:
Apreciez orice om. Indiferent ca vrea unul sau altul. Suntem diferiti, vrem lucruri difeite. Traim diferit si ne facem cariera diferit. Suntem unici in felul nostru si asta ne permite sa avem perspective diferite asupra aceluiasi lucru.
Convingerile mele sunt potrivite pentru proiectele cu care am avut tangenta. Cu siguranta exista undeva proiecte care este bine sa fie facute diferit. Altfel nu ar exista aceasta varianta in viata si industria noastra.
