Drupal 8, the good, the bad, and the ugly

Versiunea 8 a cunoscutului CMS Drupal este rescrisa folosind componente Symfony. Vestea e minunata pentru ca se seteaza un alt nivel al calitatii dezvoltarii de module. Din pacate pentru companiile care au oameni rodati pe Drupal 7 asta inseamna multa reconversie profesionala. Daca e sa ne uitam la Magento2, va fi o perioada destul de lunga (eu estimez de 1 sau 2 ani) in care se vor coda module pe noul stil.

Unul din videourile bune despre D8 a fost inregistrat chiar la conferinta vecinilor bulgari de PHP.
Lead developerul versiunii 8, Larry Garfield, a plecat spre zari mai bune, probabil epuizat de efort. Nu e putin lucru sa tii in mana comunitatea de developeri care era Drupal 7 (non-OOP).

2 Likes

Am avut deseori discutii cu colegii pe tema asta, parerea mea este ca nivelul ridicat al codului va fi o bariera majora in raspandirea Drupal 8 si Magento 2.

Nivelul scazut al codului a permis dezvoltarea extraordinara a ecosistemului prin faptul ca multi puteau scrie un plugin fara prea multe cunostinte de programare. Daca nu vor putea face asta se vor reorienta spre alte framework-uri mai simple.

Am avut experienta recenta cu Oro CRM (construit pe componentele Symfony2) si m-am trezit ca trebuie sa citesc multe lucruri pentru un simplu CRUD, complexitate inutila din punctul meu de vedere.

2 Likes

Sunt de acord cu voi, nivelul scazut a fost cel care a dus la popularitatea sa. E extraordinar, pentru ca a trivializat accesul la industria programarii. Nu am mai fost o casta de țăcăniți asociali.

Nu sunt de acord cu bariera joasa de intrare din prezent, de aceea parerea mea personala este ca vestea e minunata. Stiu ca ma entuziasmez prea mult, insa 2016 este anul in care PHPul a trecut granita maturitatii cu adevarat. Pana acum eram cativa care pionieram scrierea de cod bun. Eu personal mi-am luat cateva hatereli adevarate pe subiectul asta, pentru ca am pus stacheta undeva unde membrii echipei nu voiau nici macar sa conceapa ca vor fi candva. Am patit inclusiv un fel de rascoala de pe Bounty a membrilor echipei, pentru ca ei nu voiau sa respecte coding standards sau sa isi puna problema eficientei / performantei codului pe care il produceau (bine, unii dintre ei nici nu voiau sa vina la job, daca se putea sa vina Casper sa le faca treaba era perfect). Pentru ca am trait pe pielea mea efectele lipsei de viziune a membrilor comunitatii PHP, am continuat sa “propovaduiesc” bunele practici in toate modurile in care m-au tinut puterile. Tot timpul era varianta “merge si asa”, nici nu era nevoie OOP in Drupal 7.

Din octombrie, de cand o sa vina Uncle Bob la ZendCon, o sa putem sa aratam colegilor mai tineri ce si cum. In plus, faptul ca PHP este o solutie pentru IBM i inseamna ca suntem bagati in seama ca si comunitate in lumea enterprise. Acum o sa fim acolo, conectati la date, si folosind ceea ce facem de ani de zile ca agilitate, vom putea conta la toate nivelurile, indeosebi la middleware. De fapt, ceea ce noi numim middleware si altii numeau pana mai ieri doar “frontend”, va fi adevaratul layer de business al multor afaceri.

4 Likes

Apropo de cât de matur a ajuns php-ul și bunele practici, se întrebă lumea pe quora care limbaj va domina în viitor dezvoltarea web, și cred că îți va plăcea răspunsul meu :slight_smile:

Nu știu de ce, dar am impresia că ți-ai setat niște așteptări foarte ridicate vis-a-vis de impactul lui Uncle Bob :slight_smile:

1 Like

11 posts were split to a new topic: Professional Software Developer: PHP Vs Ruby

Cred că problema nu este, că de exemplu se folosește componente symfony pentru drupal 8 sau că pentru magento 2 s-au adoptat anumite standarde, ci faptul că în locul codului vechi s-au cuplat la un framework și la un model de tip crudish.

Dacă în schimb, pentru un modul nou, mai înainte de a scrie cod, se face o minimă analiză, de genul 3 amigos (developer, tester, business) și din care să rezulte niște scenarii care sunt formulate într-un limbaj înțeles de toată lumea, fără referințe la ui sau alte detalii de implementare și care exprimă work flow-ul de business.

Astfel, de exemplu după ce ai făcut modelling by example poți avea pentru un client ce are 2 magazine pe platforme diferite de magento, aceiași funcționalitate în core, urmând doar să scrii codul de connectare la platforma respectivă pentru fiecare caz în parte, sau poate în cazul unui csm ca și drupal 8, upgrade-ul la o nouă versiune sau chiar schimbarea la un alt csm de exemplu eZ Platform, se poate face ușor pentru că core-ul este separat, ducând spre o arhitectură de tip hexagonal.

Asta ar fi soluția pentru sisteme legacy, de tip database first, adică de fapt a modului în care se face stocarea pentru schimbarea stării unui concept.

Mai greu ar fi, pentru astfel de sisteme, ca noile module să utilizeze o arhitectură de tip event sourcing poate după o sesiune de tip event storming pentru că probabil integrarea nu ar fi la fel de lină, dar care cred că ar merge de minune pentru ceva nou și care nu depinde decât de php, eventual un framework pentru cqrs/es în php.

Un lucru e sigur, Drupal 8 va tria din programatorii care nu cunosc OOP.

Echipa Drupal, in momentul de fata au reusit sa restructureze core-ul pentru a fi usor de migrat la PHP7; momentan functioneaza pe versiunea PHP5.6 care are elemente de PHP7.

Din punctul meu de vedere PHP nu va ajunge niciodata ca si Java sau .NET

Cred ca am intarziat un pic cu comentul dar sper sa fie de folos.

1 Like

Nu aș fi chiar atât de categoric. Pentru că asta ar putea funcționa și în sens invers: Drupal va fi ocolit de programatorii care nu cunosc OOP și/sau care nu sunt dispuși să învețe ceva nou. Iar dacă ăștia sunt mai mulți (sau apropiati ca număr) decât ceilalti, s-ar putea ajunge la două situatii:

  1. abandonarea Drupal în masă;
  • o schismă de genul Python 2 vs Python 3, în care Drupal 7 va continua să fie întreținut mulți ani de acum înainte.
1 Like

dar pre-Drupal 8 totusi code quality wise nu era peste WP?

Intradevar, ai dreptat, este “cutit cu 2 taisuri” dar sunt foarte sigur pe ceea ce am scris. Cei care o sa fuga de Drupal OOP (Symfony/Laravel) for merge catre Wordpress/Joomla.

Drupal 7 nu va mai fi intretinut dupa maxim 5 ani, deoarece in 5 ani PHP7 va intra puternic pe piata si nu cred ca cineva isi va petrece timpul sa modifice corul de D7 pentru a fi compatibil, unde D8 este mult mai simplu de migrat.

Drupal 7 a fost superior peste WP, ca si structura de cod si modul in care a fost construita platforma, dar D4-D6 nu a fost foarte departe de WP.