In this article I’m putting together my quotes, thoughts and notes on the idea that Frameworks harm the maintainability of the software you build in that framework.
Sunt de acord cu multe puncte din articol si as adauga urmatorul meu punct de vedere:
Deobicei folosim frameworkuri ca sa ridicam rapid un produs pe picioare, mentenanta care urmeaza este deseori un fapt care se pierde din vedere. Daca faci un soft in 3 luni, nu prea te gandesti ca o sa-l tii 10 ani (mai ales cand faptul acceptat la noi este ca schimbi jobul la fiecare 2 ani).
Din cauza acestei mentalitati nu cred ca e vina per-se a frameworkurilor, ci a mentalitatii unei industrii. Ca folosesti sau nu un framework, daca nu se planifica de dinainte mentenanta ajungi in aceeasi situatie. De unde si vorba mea: “Doamne fereste sa ai success” ca dupa ramai cu proiectul ala pe care l-ai facut pe genunchi intr-un weekend pe jumatate mahmur si doar Dumnezeu mai stie ce-i pe acolo.
Autorul ar trebui sa scrie inca un articol despre cum e sa preiei un proiect “90% ready” scris pe genunchi. Sa vezi acolo mentenanta incercand sa intelegi ce s-a vrut de fapt, unde e codul, cum se testeaza, si, cel mai important, cat se securizat e.
E doar un articol pe stilul “scriu contrar opiniei generale, ca sa fie partajat/discutat cat mai mult”. Un fel de click-bait modern.
3 Likes
Nu am citit articolul, comentez doar pe titlu
Using vs coupling sunt două lucruri care pot însemna același lucru. Sau care nu. Și în funcție de mediul în care lucrezi, e OK. Sau nu.
De exemplu, codul meu e scris pentru WP, șansele să fie portat în altă parte sunt atât de mici încât nici nu merită să mă gândesc la treaba asta. Pe de altă parte, codul meu este scris pentru plugin-uri de WP. Șansele ca în viitor să renunț la plugin-ul X în favoarea plugin-ului Y sunt destul de mari. Chiar acum sunt în situația asta: am moștenit un proiect care are multe plugin-uri custom pentru Ninja Forms - care este o mizerie, btw - iar plugin-urile sunt super legate de NF; pentru a migra pe alt plugin de forms ar însemna rescrierea tuturor plugin-urilor.
Am mai spus despre cartea Modernizing PHP (este gratuită de ceva timp): este genul de lectură care m-a făcut să privesc ușor diferit codul și modul în care mă raportez la dependențe. Pentru că da, asta este framework-ul, o dependență.
Recent am răsfoit și Clean Architecture și - pe lângă multe chestii pe care nu le-am înțeles pe deplin, trebuie să aprofundez, dar asta e o altă discuție - este aceeași idee: framework-ul este o unealtă, nu arhitectură. Nu îți construiești codul în jurul framework-ului, codul tău ar trebui - în mod ideal - să nu știe nimic despre framework.
Câteva citate din capitolul „Frameworks are Details”:
The relationship between you and the framework author is extraordinarily asymmetric. You must make a huge commitment to the framework, but the framework author makes no commitment to you whatsoever.
For the framework author, coupling to his or her own framework is not a risk. The author wants to couple to that framework, because the author has absolute control over that framework.
What’s more, the author wants you to couple to the framework, because once coupled in this way, it is very hard to break away. Nothing feels more validating to a framework author than a bunch of users willing to inextricably derive from the author’s base classes.
Oh, you can use the framework—just don’t couple to it. Keep it at arm’s length. Treat the framework as a detail that belongs in one of the outer circles of the architecture. Don’t let it into the inner circles.
If the framework wants you to derive your business objects from its base classes, say no! Derive proxies instead, and keep those proxies in components that are plugins to your business rules.
Don’t let frameworks into your core code. Instead, integrate them into components that plug in to your core code, following the Dependency Rule.
For example, maybe you like Spring. Spring is a good dependency injection framework. Maybe you use Spring to auto-wire your dependencies. That’s fine, but you should not sprinkle @autowired annotations all throughout your business objects. Your business objects should not know about Spring.
Instead, you can use Spring to inject dependencies into your Main component. It’s OK for Main to know about Spring since Main is the dirtiest, lowest-level component in the architecture.
4 Likes
Probabil logica de business ar trebui decuplata de framework. Si astfel daca nu iti mai place framework-ul, poti sa migrezi spre altceva.
Good luck with that. La proiecte mature, cu code base mare este aproape imposibil si al naibii de riscant business wise.
1 Like
Stiu 
De aia este teoretic si nu neaparat practic.
Orice ai face, iti va afecta mentenanta…
Strategia buna e sa decuplezi cat mai mult lucrurile ca daca ceva trebuie inlocuit/rescris sa se poata efectua in paralel. (parallel refactoring)
Daca un framework iti permite asta deja esti castigat.
Mentenanta e in fiecare caz extrem de complexa fiindca de obicei creste exponential efortul cu cat se dezvolta mai mult. Creste dificultatea la CI/CD, cresc testele flaky, creste technical debt-ul, cresc cuplarile intre componente, documentatia trebuie actualizata din ce in ce mai mult.
De multe ori trebuie sa schimbi strategia de tot.
Acum cu Spring/Java si eu aveam preconceptia ca e foarte enervant fata de Go de exemplu, dar are si avantajul ca debugging-ul e standardizat. Intrii pe orice proiect de spring, attach la proces/docker si poti pune breakpoint-uri unde vrei.
Da, mai degraba faci fork la framework daca ajungi in situatia de switch
Si uite asa ajungem la Symfony: niste baieti destepti au construit un framework decuplat, si au facut-o asa de bine ca altii folosesc bucati din el in propriile lor frameworkuri (Drupal, Laravel, etc).
1 Like
Parcă veneau roboții care în 2-3 ani vor rezolva tot cât ai bate din palme. Acum ne speriem că e de muncă.
Yup, e o carte faina cu siguranta. In opinia mea, mult peste mai faimoasa Clean Code.
Foarte asemanator e si hexagonal architecture. Despre care mi se pare ca e mai usor sa gasesti material pe net. Inclusiv video-uri / tutoriale pe YouTube.
Daca adaugi si niste Domain Driven Design in ecuatie, e o reteta pentru structurarea aplicatiilor “monolitice” foarte buna.
Cat lucram la side project citeam si cartea asta plus alte materiale ajutatoare. Si am evoluat incet-incet arhitectura de la niste scripturi, la layerd architecture, la hexagonal architecture, la hexagonal + DDD-light.
Clar nu aveam vre-o presiune externa gen “deadline” sau “clienti”, asa ca YMMV intr-un proiect real. Dar chiar puteam sa vad diferente mari in usurinta de a lucra cu proiectul, separarea concern-urilor, si sentimentul ala warm-and-fuzzy de “asa e corect” pe masura ce progresam. De exemplu, niste migrari destul de tricky au mers “ca la carte” din cauza asta (flat YAML files+dumb orm → SQLite+SQLAlchemy, print → textualize/rich, client neoficial Notion.so → client oficial Notion.so).
Si in cinstea metodelor de mai sus, asta este o aplicatie CLI, nu una web.
Si vad o cale destul de simpla de a trece de la CLI la aplicatii de alte forme gen TUI, webapp, mobile app, etc. Cu schimbari minime in miezul aplicatiei si adaos de cod doar acolo unde are sens - in layerul de infrastructura.
4 Likes
Și comentariile de pe HN sunt interesante:
2 Likes
Sunt de acord intru totul cu ideea articolului. Sunt fan al arhitecturii hexagonale si al Domain-Driven design in aplicatii monolit dar si microservicii cu Bounded-Contexts.
Problema e ca in absolut toate proiectele si companiile pe la care m-am perindat in ultimii 11-12 ani, din diferite motive, unele de dragul “Agile”, altele de dragul de a livra la timp si a incasa un bonus, noi programatorii ajunseseram ca in Morometii: timpul nu mai avea rabdare.
Si uite asa au ajuns 95%+ din proiectele informatice de azi, in special web, sa fie facute pe scheletul rezultat din comenzile specifice crearii unui new project in frameworkurile la moda la vremea respectiva.
Pentru mine e un lucru rau ca am ajuns asa. Mai grav este si daca aparam acea structura ca fiind una standardizata…eventual care ne-a ajutat sa livram chestii la timp in momentul 0 al proiectului. Dar stiu sigur ca se poate mai bine decat atat.
Cum zicea @alexjorj mai sus, symfony e un exemplu de framework bun care vine din start sub forma de componente. Si tu alegi ce si cum sa folosesti ce ofera. Ar trebui urmat exemplul asta in toate ecosystemele(Nu, Spring nu e acelasi lucru)
Si ma rog, nu mai inteleg de ce cineva ar dori sa apere frameworkurile desi pot intelege anumite contexte. Gen, lucrez la o firma de outsourcing si trebuie sa livrez ceva in 3 luni. Clientul vrea java cu spring. Here you go, boss…Dar nu ma pune sa fac mentenanta pe asa ceva ca nu pot inghiti nici cu 1kg de lamai.
5 Likes
poti sa explici putin pt astia mai ca mine?
Ce este o arhitectura hexagonala?
2 Likes
As zice ca esentialul e celebra blue book a lui Eric Evans. Dar multi o gasesc greu de digerat, asadar eu recomand the red book:
Am incercat sa fac o poza sa se vada grosimea.
DDD se invata prin studiu sistematic, nu sunt indeajuns cateva blogposturi si/sau poze. Trebuie trecut prin ciclul studiat-codat-refactorat de mai multe ori pana cand it all clicks together.
2 Likes
Asta? Domain-Driven Design: Tackling Complexity in the Heart of Software Amazon.de ca ma asteapta de ceva vreme pe raft
da, aia e blue book
Un talk bun(cu exemple in cod) despre DDD de la Devoxx 2022: Writing cleaner code with Domain Driven Design by Paul van der Slot
Recent am inceput un proiect cu arhitectura hexagonala in java cu maven multi module (e-commerce)
1 Like