Framework: custom sau nu?

Workflow & Best Practices
,
1

Lovindu-ma de un nou proiect zilele trecute, ma pregateam sa deschid un topic pe tema titlului.
Am vazut ce s-a inceput aici Do Not Learn Frameworks. Learn the Architecture, dar am deschis, totusi, un topic nou, pentru ca mi-ar placea sa stiu ce concluzii ati tras din experienta voastra.

Eu am inceput prin a crea un framework, inspirandu-ma din CodeIgniter. Fiind abia la inceput cu OOP, am zis ca, facand un framework, o sa invat ce inseamna, ce trebuie urmarit, ce probleme se trateaza, ce solutii se gasesc. Am luat cam fiecare componenta CI si am incercat s-o reproduc dupa logica mea. Si m-a ajutat foarte mult, atat la a cunoaste arhitectura, OOP, cat si la a-mi imbunatati gandirea.
Am avut cateva proiecte unde am avut sansa sa folosesc respectivul framework si a ajuns in productie. La fiecare proiect am descoperit neajunsuri pe care, de multe ori, le-am rezolvat in graba, din motive de timp. Si nu eram multumit de asta.

Pe urma, am trecut la a folosi framework-uri existente (CI, Laravel, Symfony). Si am observat ca orice situatie impusa de proiect are o rezolvare eleganta, daca stai si studiezi cu rabdare problema.

Dezvoltand ceva dupa modalitati si standarde proprii, alti indivizi vor fi nevoiti sa inteleaga, in primul rand, cum ai gandit (aici ma refer mai mult la arhitectura si standarde, nu neaparat la implementarea unor solutii, desi gasim pattern-uri structurale comune si pentru astea).
In schimb, daca folosesti o unealta (corespunzator, dupa practicile indicate), cel care vine dupa tine are instant o privire de ansamblu.

Nu sunt impotriva framework-urilor custom, dar sunt destul de greu de intretinut in timp si pentru un numar mare de persoane si, cum ziceam, nu poti sa prevezi toate situatiile ce pot aparea. Dar, daca totusi se alege calea asta, e de preferat ca macar unele standarde sa fie folosite (cum ar fi PSR-ul pentru cod in sine).

Recomandarea mea, in general, e folosirea framework-urilor existente (da, pot exista situatii in care sa fie benefica o altfel de solutie), sunt destule incat sa avem de unde selecta, in functie de preferinte.
Insa nu recomand inflexibilitatea, un lucru nu “se face asa pentru ca asa se face, asa il face toata lumea”, ci e de preferat sa sapi adanc, sa intelegi cu adevarat logica fiecarui framework.

Inca ma mai gandesc uneori sa incep iar dezvoltarea unui framework pe placul meu, in stilul meu de a gandi si a rezolva problemele, dar cu siguranta as face asta cu gandul la cei ce ar putea lucra pe codul meu la un moment dat.
Nu, nu sunt un robot ce lucreaza strict dupa carte, ci am inteles si observat avantajele standardelor (nu a doctrinelor).

Voi?

1 Like
2

Sau ai putea sa le imbini, adica sa te implici in frameworkul respectiv, sa intelegi cum functioneaza si sa te implici in dezvoltarea lui (opensource), adica ai putea rescrie unele componente dupa logica ta si faci pull request si discuti cu dezvoltatorii proiectului de ce e mai bine logica ta, ce probleme are, de ce e mai buna logica din framework, etc. Asa ai avantajul unui framework custom (poti face orice modificare/adaptare rapid) si avantajele standardizarii.

Si eu m-am gandit in ultimul timp sa incep sa imi fac un mini-framework / librarie, pentru a imbina bootstrap (sau alte frameworkuri css) cu angular si libraria medoo in backend, si probabil o voi face. Dar pana atunci merg pe ce stiu deja, si anume frameworkuri existente.

3

Eu unu dupa ce am renuntat sa mai dezvolt pe Joomla acum mai bine de 5 ani am lucrat in general cu platforme “custom” (MVC sau nu) mulate pe cerintele clientilor si nu pot sa zic ca la un update am ajuns sa scriu spaghete. Framework-uri am folosit rar, doar cand mi-au fost impuse de client.

Daca ar fi sa o iau de la capat cu un proiect in PHP as folosi Silex (http://silex.sensiolabs.org/) + Composer pentru ce pachete mi-ar fi absolut necesare. In rest foloseste-ti imaginatia si cine stie ce vei inventa :stuck_out_tongue:

Respecta standardele de baza, fa o structura clara fara inflorituri aiurea si orcine cu putina experienta va putea sa continue ceea ce ai inceput tu.

Just do it! :smiley:

1 Like
4

Daca ai un proiect mai maricel, daca nu folosesti un framework, părerea mea este că ar trebui să îți reconsideri decizia (edit moderator). Asta pentru ca un framework rezolva foarte multe probleme intr-un mod documentat, chiar daca nu optim.

Foarte populare sunt framework-urile MVC. Separarea responsabilitatilor e esentiala. MVC-ul a fost un prim pas. In ziua de azi, s-a ajuns la o mai mare maturitate in gandire, iar MVC-ul nu mai e suficient. Exista solutii elegante, pe care cei de prin Symfony si Laravel le-au implementat. Ca de exemplu, comenzi, evenimente…
Sa te apuci sa faci tu singur chestiile astea, e extrem de ineficient. In primul rand ca nu ti-ar veni ideea sa pui multe lucruri, pe care daca le-ai vedea intr-un framework, le-ai folosi.

Toti amicii mei care au preluat proiecte fara framework de pe la diversi profesionisti, au injurat foarte mult si fie au renuntat la ele, fie le-au rescris. Nu am auzit de vreo poveste de succes pe framework personal, pana azi.

5 Likes
6

Haideti sa facem discutia constructiva. Fiecare sa-si spuna experienta si tragem concluzii pe parcurs.

@ovidiu_dtp are parerea respectiva, poate gresita, poate nu. Cand avem mai multe voci, poate ii argumentam de ce greseste sau poate ne argumenteaza el mai in detaliu de ce are dreptate.

Cu calm, n-are sens sa ne agitam. :smile:

7

Experienta mea este similara cu cea a lui @ovidiu_dtp. Niciodata nu pot sa zic ca m-am bucurat cand am preluat un proiect dezvoltat pe un framework propietar, care reflecta gandirea unui singur individ (sau echipa mica). Iar motivele sunt cat se poate de clare: experienta invidului nu era suficient de mare, documentatie inexistenta, cometarii in cod putine sau proaste (pentru ca de ce am folosi PHPDoc sau ceva similar?!). Ah, si niciodata nu am gasit nici un fel de test intr-un framework din asta custom.

Singura varianta rezonabila din punctul meu de vedere ar fi sa folosesti componentele de Symfony (+arhitectura) si sa le unesti intr-un stack custom, dar daca nu ai un motiv foarte bun sa faci asta reinventezi roata de pomana (nu vorbesc de cazul in care nu ai inteles corect arhitectura sau design patters din spate).

De cand cu Symfony (framework-ul dar si componentele) si Silex nu ma mai gandesc sa scriu vreodata sa scriu cod in propriul meu “framework”. Am invatat si mai am destule de invatat din aceste framework-uri/componente asa ca planuiesc sa le folosesc in continuare. Nu e vorba de indoctrinare, e vorba de pragmatism.

PS: custom frameworks pentru pet projects, facute ca sa inveti fac exceptie de la idea mai sus.

3 Likes
8

Nu e vorba de indoctrinare, ci de pragmatism. E ca si cum ai avea de mers pana la Paris. Unii merg cu avionul, unii cu masina, iar to hotarasti sa mergi pe jos sau sa-ti contstruiesti caruta ta, ca stii tu mai bine cum se face.

Singura situatie in care un proiect este okay sa fie facut fara framework, este cand e suficient de mic si garantat sa nu creasca. Atunci, PHP blana e tot ce-ti trebuie. Dar nici atunci nu se justifica. Pentru simplul motiv ca utilizand un framework - orice framework - o sa termini semnificativ mai repede, pentru ca ai abstractizate o gramada de chestii. Asa ca niciodata nu exista vreun motiv valid sa nu folosesti un framework.
Daca vorbim de rapiditate si eficienta codului, acesta e un fals argument. E vorba de optimizare prematura, iar argumentul asta in general e folosit mai mult pentru a arata unul si altul cat e el de pretios si ce probleme savante-si pune, decat din motive obiective.

Intrebarea, dupa parerea mea, nu e niciodata daca sa folosesti sau nu un framework, ci este mai degraba ce framework sa folosesti.

3 Likes
9

Ca si contraexemplu, sa folosesti un framework pentru un site cu cateva pagini web este ca si cum ai folosi tunul sa omori muste.
Un framework introduce un grad de complexitate suplimentar, practic un limbaj aditional pe langa PHP, care la proiectele mici nu este necesar.
Deasemeni am intalnit project manageri disperati ca nu puteau continua proiectul pentru ca nu gaseau programatori PHP care sa stapaneasca un anumit framework cu care era dezvoltat acel proiect.

3 Likes
10

Ceea ce ne face să ne întoarcem la… „Do Not Learn Frameworks. Learn the Architecture” :smiley:

4 Likes
11

O să plec de la premisa că nu vorbim de cine știe ce obscuritate de framework, ci de unul la modă. Din perspectiva programatorului pot apărea 4 situații:

  1. Nu-ți place framework-ul, deci nu te bagi. Aia e, se întâmplă, mi se pare absolut normal.
  2. Nu-ți convine prețul. Mi se pare cu atât mai normal.
  3. Aplicația a fost scrisă cu curul până la acel moment, caz în care framework-ul contează prea puțin.
  4. Nu ești capabil să scrii cod în framework-ul respectiv

Primele trei sunt situații normale, dar dacă tu ca programator de trezești în situația numărul 4 atunci mai bine te apuci de agricultură. :slight_smile:

2 Likes
12

Dar nimeni nu a intalnit vreodata un project manager disperat ca i-a plecat “lead developerul” care a creat un framework proprietar eventual si fara sa lase documentatie sau sa predea proiectul altcuiva cu set de cunostinte/abilitati similare. :smirk:

2 Likes
13

Perfect de acord cu chestia asta. Invatatul de arhitectura e esential, dar utilizarea de framework-uri este foarte importanta. Omul vorbea de javascript. Acolo lucrurile sunt mai bizare, prin natura limbajului Si are dreptate intr-un fel.

Si mie mi se par extrem de incalcite framework-urile de JS. Daca apuci sa incepi cu Angular vechi sau ExtJS 3, nu prea mia poti sa schimbi acel framework fara o rescriere groasa. Pe de alta parte, la momentul la care incepi, aceste chestii iti dau un boost de productivitate mult prea mare sa-l neglijezi. Desigur, daca nu-l folosesti, nu are rost sa te legi de asa ceva.

Pe partea de PHP, lucrurile stau un pic altfel.
Laravel, si probabil si alte framework-uri moderne, implementeaza principii. Lucruri pe care le-ai face tu insuti in majoritatea situatiilor.

E adevarat, are chestii care sunt un mare avantaj in anumite situatii, gen Eloquent, dar in acelas timp, pot ajunge sa te incurce foarte tare, daca ai o aplicatie extrem de complexa si ai de facut interogari ultra dubioase. Pe de alta parte, daca inveti un framework si nu esti in stare sa traiesti fara te miri ce chestie din acel framework, ai o mare probelema. Iar cand observi ca ai acea problema, e vremea sa postezi pe forumuri si sa ceri ajutor :smiley:

1 Like
14

Da putem să ne creăm propriul framework opensource pe github cu multă documentație bine pusă la punct și easy to use :slight_smile: ce developeri urmează după noi au documentația acolo. Eu cam așa vreau să fac.

15

Nu-mi dau seama dacă glumești sau nu, dar numai eu am avut trei clienți în situația asta. Și alți doi trimiși spre alți programatori, că mă depășea situația.

16

Uite, de fapt aici se vede skill-ul unui programator… la asta nu ma gandisem. Iti faci propriul framework si esti indispensabil. Iti mai faci si niste chestii pe care numai tu le pricepi de ce-s asa, cu masti pe bit si conditii cu logica booleana de 3 pagini cu toate alea denumite x, a ,i, array, obj. In felul asta te-ai asigurat ca nu are nimeni curaj sa te schimbe… Probabil ca sunt si astfel de experti… Si se considera talentati.

Iar daca vrei sa ai succes, pastrezi o parte din cod in baza de date si-l rulezi cu exec. MESERIE!!!

3 Likes
17

Glumeam. :blush: (un pic prea mult sarcasm, nu?!). M-am lovit si eu de situatia asta, bineinteles.

1 Like
19

I moved 9 posts to a new topic: Framework: custom sau nu? (locul în care ne jignim și ne ștergem conturile)

2 Likes
20

Eu unul sunt contra framework-urile custom si anume dintr-un motiv foarte simplu, logic si evident, parerea mea. Poti sa fii tu macar si inventatorul php dar nu ai cum sa faci un framework care sa concureze cu un framework open source, la care participao caruta de programatori, probabil multi, cel putin la fel de buni ca tine.
Singurul avantaj care-l vad la un framework propriu e ca-l faci pe client dependent de tine, dar nu cred ca asta e o strategie de marketing. corecta/de perspectiva.
Daca vrei sa-ti faci un framework din cauza ca ai nevoie sa-l folosesti la proiecte mici, ori alegi Silex care, din cate stiu eu, e pentru proiecte mici, ori alegi un framework foarte flexibil in care in bootstrap iti setezi autoload-ul.si o sa fie mare doar ca dimensiune, dar nu si ca (virgula) consumator.

1 Like
21

I think it’s important to reason from first principles rather than by analogy. The normal way we conduct our lives is we reason by analogy, we are doing this because it’s like something else that was done, or it is like what other people are doing.
Elon Musk

Daca ai cunostinte si intelegi nevoiele pe care le ai, nu este rau sa-ti faci propriul framework daca esti mai eficient cu el. Ideal este sa-l faci Open Source ca sa-ti validezi ideile si poate atragi si alte persoane sa contribuie, iar ca “side-effect” exita progresul in domeniu, automat te lovesti de lucruri pe care nu le stapanesti si le inveti ca sa le poti implementa.

Quote-ul din Elon Musk mi se pare foarte relevant can vrei sa te apuci de ceva custom. Inainte sa te apuci sa scrii cod consider ca este important sa-ti schitezi structura framework-ului si sa incepi cu documentatia. Eu de ceva timp folosesc Documentation Driven Design si de multe ori dupa incep sa schitez API-urile incep sa-mi dau seama ca unele lucruri le pot scoate in module separate.

In ultima perioada am inceput sa-mi modelez modul de abordare al arhitecturii dupa microservices, un articol util pt. cine e interesat: MicroservicePrerequisites

4 Likes
22

Din experienţa mea, un framework este net necesar oricărui proiect mai complex. Mai complex în sensul în care nu face un scop exact şi precis, gen vreun bridge sau API între 2-3 alte servicii/API-uri, ci are nevoie de session management, useri, ceva interactivitate minimă, deja discutăm de framework imperativ dacă vrem ceva stabil şi rapid.

Putem fi subiectivi pe care framework să folosim, fiecare framework este mai bun pentru un anumit tip de soluţie, şi oricât de fani am fi, nu există un framework bun la toate.

Legat de aplicaţiile ultra-complexe, cu query-uri complexe care depăşesc ORM-ul standard, orice framework modern suportă (sau ar trebui să suporte) foarte uşor query-uri custom complexe şi lucrul direct cu ele.

Personal am lucrat cu Zend, şi acum cu Laravel, şi pragmatic fiind, timpul de la negocieri până la încasare efectivă a scăzut dramatic. Ce să mai zic dacă începi după un timp să dezvolţi să zicem nişte componente complet independente şi reutilizabile pentru frameworkul respectiv, gen arhitectura de Facades de la Laravel, sau modules, services la Zend.

Plus că am şi stabilitatea. Am un cod testat. La un cod propriu aproape tot timpul mai apare câte un bug obscur care e aproape imposibil de prins când lucrezi la 2-3 proiecte pe lună, pe când la un framework care e folosit în milioane de proiecte, sunt şansele mult mai mari să fie descoperit acel bug şi tu să nu mai ai probleme cu el pe când lucrezi tu cu el.

Părerea mea este că dacă lucrăm cu software…cel mai mare avantaj al unui produs software faţă de unul fizic sunt costurile inexistente de reutilizare. De ce să nu profităm de el şi de munca altora şi să trecem noi prin bug-uri pe banii/timpul nostru?

9 Likes