Je suis tombé récemment sur le manifeste micro PHP.
Le manifeste
Plutôt que de faire un copier-coller bête et méchant de la version originale, voici une traduction approximative :
Je suis un développeur PHP
Je ne suis pas un développeur Zend Framework ou Symfony ou CakePHP.
Je pense que PHP est déjà suffisamment compliqué.
J’aime créer des choses simples
J’aime créer des choses simples avec des objectifs simples.
J’aime créer des choses qui résolvent des problèmes.
J’aime créer des choses simples qui, mises ensemble, résolvent des problèmes complexes.
Je veux moins de code, pas plus
Je veux écrire moins de code, pas plus.
Je veux gérer moins de code, pas plus.
Je veux maintenir moins de code, pas plus.
Chaque morceau de code que j’ajoute à un projet doit être justifié.
J’aime le code simple et lisible
Je veux écrire du code qui se comprend facilement.
Je veux du code qui se teste facilement.
Le détail
Le créateur de ce manifeste explique sa pensée plus en détail sur son blog. Dans un premier post, il donne sa vision d’ensemble. Mettons de côté sa comparaison musicale (il compare l’installation de deux batteurs, pour dire qu’il se voit comme un codeur punk, et non pas comme un codeur rock-progressif… mais on s’en fout un peu).
Ce qui est intéressant, c’est lorsqu’il donne un exemple de code, censé être typique des applications Zend Framework :
<?php
chdir(dirname(__DIR__));
require_once (getenv('ZF2_PATH') ?: 'vendor/ZendFramework/library') . '/Zend/Loader/AutoloaderFactory.php';
Zend\Loader\AutoloaderFactory::factory(array('Zend\Loader\StandardAutoloader' => array()));
$appConfig = include 'config/application.config.php';
$listenerOptions = new Zend\Module\Listener\ListenerOptions($appConfig['module_listener_options']);
$defaultListeners = new Zend\Module\Listener\DefaultListenerAggregate($listenerOptions);
$defaultListeners->getConfigListener()->addConfigGlobPath('config/autoload/*.config.php');
$moduleManager = new Zend\Module\Manager($appConfig['modules']);
$moduleManager->events()->attachAggregate($defaultListeners);
$moduleManager->loadModules();
// Create application, bootstrap, and run
$bootstrap = new Zend\Mvc\Bootstrap($defaultListeners->getConfigListener()->getMergedConfig());
$application = new Zend\Mvc\Application;
$bootstrap->bootstrap($application);
$application->run()->send();
Et là, je le rejoins complètement. C’est une chose que j’ai déjà rabâchée à plusieurs reprises. À mon sens, un framework doit simplifier le développement, le rendre plus rapide et plus lisible. C’est une évidence pour tout le monde, mais le moyen d’y arriver ne semble pas être commun à tous.
À mes yeux, le code d’une application doit être limpide. Évidemment, on s’attend à avoir un « socle de base », un « moteur » sous-jacent qui est là pour simplifier les choses. L’exemple de code ci-dessus est sans appel. Moi non plus, je ne veux pas avoir à coder des trucs comme ça.
Je peux comprendre qu’il puisse y avoir à choisir entre complexité du code d’un côté, et complexité de la configuration de l’autre. Si un framework rend le code simple, mais au prix d’une configuration plus complexe, cela peut s’expliquer. Ensuite, tout dépend de là où on souhaite mettre le curseur. Une configuration plus simple aura sûrement pour effet de complexifier le code.
Le problème, c’est qu’on se retrouve parfois à avoir du code complexe ET des fichiers de configuration illisibles.
Les micro-frameworks et les micro-bibliothèques
L’auteur du manifeste prend ensuite le parti de dire qu’il existe des micro-frameworks qui font très bien le boulot. Prenant l’exemple de Slim, Epiphany, Breeze et Limonade, il part du principe qu’il sont largement suffisant pour la plupart des besoins, et que son approche est de les enrichir grâce à des bibliothèques de fonctions, plutôt que de vouloir utiliser un framework « full-stack ».
Pour rappel, les micro-frameworks fonctionnent quasiment tous sur le même modèle. Pour illustrer la chose, voici l’exemple de code fourni par Slim :
<?php
require 'Slim/Slim.php';
$app = new Slim();
$app->get('/hello/:name', function ($name) {
echo "Hello, $name!";
});
$app->run();
?>
Pour finir, l’auteur du manifeste tient à jour une liste de projets, qui sont tous censés être simples à utiliser, qui remplissent une seule fonctionnalité (ou un groupe de fonctionnalités connexes). L’idée est sympa, même si le nombre de projets similaires réduit son utilité.
Mon avis
Je suis complètement d’accord avec ce manifeste. Le code doit être simple ; rapide à écrire, facile à lire, facile à modifier. Je pense que personne ne dira le contraire.
Le seul point sur lequel je suis un peu plus circonspect, c’est en ce qui concerne les micro-frameworks. Je m’y suis intéressé un peu à une époque, et j’ai joué avec Silex, notamment. Et je n’ai pas trouvé que cette approche simplifiait réellement l’écriture de vrais sites.
Je suis peut-être trop formaté par l’approche à laquelle je suis habitué, mais je ne pense pas que la manière dont le routage est imbriqué dans le code soit l’idéal pour avoir du code simple à lire et à maintenir. Et plus le site sera important, plus ce sera vrai.
Cela m’amène à parler un peu du framework Temma.
Comme présenté sur le site du projet, l’idée générale est très simple :
- Pour une URL du type /article/show/123/title
- le framework exécute ArticleController::execShow(123, ‘title’);
- et transmet les données au template article/show.tpl
Et, à part une configuration très succincte (paramétrage de l’accès à la base de données), tout ce qu’on se retrouve à écrire comme code, ce sont simplement des objets dont les méthodes vont répondre aux URL. Nous sommes d’accord qu’il n’y a rien de fondamentalement novateur là-dedans, cette approche est partagée par de nombreux frameworks. Mais le code applicatif n’est pas pollué par le framework.
L’idée générale de Temma est de proposer quelques fonctionnalités de base (il y a quand même un embryon de routage, une gestion des sessions et du cache, de la base de données, …), qui sont extensibles à l’aide de plugins. On en parlait récemment sur le forum de discussion qui lui est consacré. Si vous avez besoin d’un routage élaboré, il suffit d’ajouter un plugin ; si vous voulez gérer un site multilingue, encore un plugin ; et ainsi de suite.
Ça permet de garder un cœur simple à comprendre et à assimiler, tout en gardant la souplesse d’en faire ce qu’on veut en fonction de nos besoins.
Pour en revenir au manifeste micro PHP, je pense qu’il s’agit surtout d’un rappel d’un principe fondamental du développement. Quand on développe, on sépare le code en entités séparées les unes des autres. La programmation orientée objet facilite cette approche en fournissant la brique de base de ce concept ; mais au-dessus de l’objet, il y a les bibliothèques qui regroupent plusieurs objets.
Ces différentes entités s’appellent entre elles pour profiter des fonctionnalités qu’elles offrent. Ce qui fait la différence entre un bonne bibliothèque et une mauvaise, c’est entre autre à quel point elle encapsule sa complexité et réussit à présenter une interface simple et facile à utiliser. Si une bibliothèque impose d’écrire des dizaines de lignes de code pour simplement y faire appel, ou si son API est tellement obscure qu’il faut faire plusieurs appels pour réaliser la moindre action simple, c’est qu’il y a un soucis.
J’ai un principe assez simple vis à vis des différents framework que j’ai pu essayé. Si je coince sur quelque chose qui sans framework serait une banalité , je laisse tombé. Y’a qu’a voir les tonnes de messages pour SF ou ZF où les utilisateurs veulent simplement rajouter un label ou un bout d’html à un formulaire.
Au final j’en suis venu à développer un « framework » utilisé en interne qui répond parfaitement et surtout légèrement à tous mes besoins.
@Grunk : Je ne me l’étais pas exprimé de manière explicite, mais je pense que j’ai créé Temma pourles même raison 🙂
Les choses simples devraient rester simples.
Je m’interroge depuis des années sur le réel gain de productivité apporté par les frameworks en général.
J’ai en effet deux problèmes avec la plupart d’entre eux.
Tout d’abord, comme tout le dit dans ton billet, ils ne simplifient pas forcément les choses, tant au niveau du code en lui-même que de la configuration.
La faute en incombe souvent et principalement à des API peu voir pas ergonomiques (par exemple avec une recours non systématique aux interfaces fluides, comme dans le cas de doctrine ou symfony), à une arborescence trop éclatée qui force le développeur à naviguer dans beaucoup trop de fichiers (l’existence du KnpRADBundle basé sur symfony2 est l’illustration parfaite de ce phénomène puisqu’il a été créé pour harmoniser/rationaliser l’arborescence de ce framework), à la complexité des fichiers de configuration (le développeur se retrouve à taper 3 fois plus de « code » de configuration que de code PHP), ou à un cumul de ces problèmes.
Ensuite, le framework est très utile tant que l’on ne sort pas du chemin pour lequel il a été conçu.
Dans le cas contraire, le développeur perd très rapidement du temps à chercher un moyen de contourner les mécanismes du framework pour obtenir le résultat qu’il désire.
Au final, j’ai donc tendance à penser que le ratio (temps gagné grâce au framework / temps perdu à cause du framework) n’est pas forcément si bon que cela (mais je n’ai aucune preuve scientifique, juste un ressenti forcément subjectif).
Partant de là, « less is more », car il est forcément plus facile d’appréhender un code « compact » et directement accessible (comprendre indépendant d’un fichier de configuration en YML/XML/ini/etc) et donc de le modifier pour le faire correspondre à ses besoins.
Le micro-framework a donc à mes yeux un meilleur rapport complexité/efficacité qu’un framework « usine à gaz ».
Cependant, cela va actuellement à l’encontre du marché et de la mode (mais comme tu le fais remarquer, ça évolue) car ces micro-frameworks sont beaucoup moins connus que SF (1 ou 2) ou ZF, pour ne citer qu’eux.
Ils sont donc beaucoup moins rassurant pour les « responsables » et trouver des développeurs opérationnels rapidement est beaucoup plus difficile (déjà qu’il n’est pas évident de trouver des développeurs PHP « pur » compétent…).
Je pense également que le micro-framework est encore « trop », et que la bonne voie est celle suivie par exemple par Hoa et dans une moindre mesure par SF2, qui mettent à disposition des bibliothèques que le dévellopeur n’a plus qu’à faire communiquer entre elles pour faire ce qu’il veut comme il le veut (je dis « dans une moindre mesure avec SF2 » car son cas est un peu particulier, il est en effet présenté comme un framework full-stack, mais dans les faits, pour être efficace avec lui, il est nécessaire d’écrire pas mal de « helpers » pour se simplifier la vie, et donc quelque part, cela revient à se faire son propre framework en se servant des briques de base offertes par SF2, à la façon de ce qu’à fait Sensio avec Silex).
Donc même si je suis totalement d’accord et en accord avec les principes du manifeste, je ne suis pas certain que ces derniers seront appliqués par une majorité de développeurs à court terme.
@Amaury Ha Temma est bien amené dans l’article , j’avais pas compris que c’était de toi ^^.
En tout cas , ça me fait plaisir , après avoir lu la FAQ de ton framework , je me sens un peu moins seul dans la vision que je me fait de ce que devrait être un framework PHP.
Ce sujet est le grand sujet de discussion en ce moment chez nous, pour intégrer un mini framework pour remplacer / merger notre framework interne. Merci pour les liens et ressources proposées ici (temma, je vais jeter un oeil), et le manifest (qui résume parfaitement aussi l’idée que j’ai d’un dév informatique 🙂 )
Encore une fois, je partage complétement ton avis sur un des tes articles, et comme ca arrive très souvent, je me permets ce premier post pour te féliciter pour ce blog.
A bientôt
@mageekguy : Je suis assez d’accord avec toi. Avoir une partie non négligeable de l’applicatif qui se retrouve cachée dans des fichiers de configuration abscons, ce n’est pas une bonne idée ; devoir écrire du code pour lancer l’exécution du framework n’est pas mieux.
Je nuancerais quand même, dans la mesure où la quasi-totalité des frameworks adresse 90% des développements web courants. Les cas où il faut contourner le framework me semblent être des exceptions ; ou alors c’est que le framework n’est pas adapté, ce qui peut être le cas pour ceux qui voudraient faire de la communication par websocket ou du développement de client lourd (pour prendre des exemples extrêmes).
Bref, je n’adhère pas à l’approche des micro-framework, tout comme je n’apprécie pas la complexité des frameworks full-stack existants. Je pense qu’un framework « presque full-stack », léger mais extensible, est une voie plus intéressante. C’est ce que je pratique depuis 5 ans, et mes développeurs en sont ravis 🙂
@Grunk : Oui, j’avais présenté Temma quand j’avais ouvert son code, l’année dernière.
Je suis content que sa philosophie te parle, moi aussi je me sens parfois un peu seul 😉
@tornad : Merci pour les félicitations. N’hésite pas à tester Temma et à me faire un retour d’expérience.
Je partage assez volontiers l’idée générale de ce manifeste ainsi que les observations à propos d’outils comme le ZF ou Symfony. Cela étant, j’aurais tendance à relativiser à propos de ces grosses machines : le problème à mon sens vient en grande partie de la documentation qui est malheureusement et trop souvent une bouse. Je suis certain que correctement expliqués, les principes de fonctionnement d’un ZF devraient permettre d’en faire une utilisation infiniment plus efficace et simple, mais pour ça, il faudrait que les rédacteurs de documentation ne court-circuitent pas certaines étapes essentielles. Et c’est le problème de la transmission d’un savoir : ceux qui ont conçu savent comment utiliser, mais ont des difficultés à transmettre correctement parce que certains éléments sont devenus tellement évident à leurs yeux qu’ils les omettent, probablement même pas volontairement, et du coup on patine à essayer de comprendre parce qu’il manque des pièces dans le puzzle et on finit par s’arracher les cheveux pour finir par tout envoyer par dessus bord en se tournant vers une autre solution.
Si ça complexifie le code du framework, à la limite ça m’est égal pour autant justement que ça son utilisation ne devienne pas un cauchemar ou que ça ne plombe pas franchement les performances.
My 2¢
PS. : 2 coquilles dans le texte :
-1- dans la traduction du manifeste, « … créer des choses simples qui, misent ensemble, résolvent… » // « … créer des choses simples qui, mises ensemble, résolvent… »
-2- Paragraphe « Les micro-frameworks et les micro-bibliothèques » alinea 2 : « … voici l’exemple de code fournit par Slim » // « voici l’exemple de code fourni par Slim »;
-3- Paragraphe « Les micro-frameworks et les micro-bibliothèques » alinea 3 : « … une liste de projets, qui sont tous censés entre simples à utiliser … » // « … tient à jour une liste de projets, qui sont tous censés être simples à utiliser … »;
Je suis très souvent gêné (pour ne pas dire autre chose) par les frameworks, mais j’ai apparemment une approche particulière des choses lorsque je développe, vu que je veux que ce soit simple, donc ça n’aide pas ;).
J’ai eu le cas pas plus tard qu’hier après-midi en voulant faire dans le cadre d’un projet SF2 une jointure avec Doctrine et son extension Gedmo permettant de gérer une arborescence par intervalle en base de données.
En résumé, chaque enregistrement de la table concernée contient une colonne « root » qui contient la clef primaire de la racine de l’arbre.
Or, le couple Doctine + Gedmo ne permet pas de faire une jointure sur cette colonne, (les annotations ou les directives de configuration de Doctrine et de Gedmo nécessaires pour réaliser cela ne sont pas cumulable au niveau de la propriété de l’entité, cela génère une exception) et pourtant, une jointure n’est pas une chose exceptionnelle lorsque l’on fait du développement web avec une base de données relationnelle, du moins il me semble…
Du coup, nous avons perdu plusieurs heures à chercher une solution, faisant s’envoler du même coût le gain de productivité apporté par le framework sur la mâtiné.
@Cyrano : Merci pour les remontées de typo, c’est corrigé 🙂
Je pense que tu as raison à propos de la documentation. Ce n’est pas un exercice facile.
Mais, quelque part, on voit bien que les entreprises payent des semaines de formation ZF ou SF à leurs développeurs ; le développement PHP à l’ancienne, sans framework, est maintenant considéré comme une base acquise par tout le monde (alors que c’était à cela que les gens étaient formés il n’y a encore que quelques années).
Au sujet du choix de mettre la complexité dans le code ou dans les fichiers de configuration, je répète que chacun doit pouvoir placer le curseur là où il le souhaite. Toutefois, je pense que pour une utilisation simple, le code et la configuration doivent rester simple. Ce n’est que lorsqu’on veut faire des choses plus complexes qu’on doit se retrouver à gérer cette complexité quelque part. C’est justement ça que je reproche à certains frameworks : même pour faire des choses simples, il faut d’abord mettre en œuvre des choses compliquées.
@mageekguy : Ton exemple est intéressant.
Ma réponse rapide serait plutôt de jeter Doctrine (ce serait pareil avec un autre ORM), et d’écrire les requêtes SQL à la main. Il n’y aura jamais rien de plus précis et efficace.
Mais c’est un autre débat… 😀
(au passage, ton exemple confirme ce que je pense des annotations…)
Je l’entends de la même oreille et mon propos concernait le code métier : si le code du framework a dû être compliqué et complexe à développer, c’est un moindre soucis dans la mesure où ça me permet de construire un code métier sans me prendre la tête juste avant le cachet d’aspirine 😉
Mais le framework doit être et rester un outil auquel je n’accorde pas d’autre rôle que de baliser une architecture, éventuellement des méthodes et conventions de codage, et affranchir le développeur de pas mal de traitements génériques, sont boulot devant être centré sur le code métier.
@amaury: pour le coup, jeter l’ORM (peu importe son nom) réduit à mon sens très fortement l’intérêt du framework, car il est pour beaucoup responsable de sa puissance, ce qui n’aide pas à trouver une réponse favorable à la question « les frameworks sont-ils réellement utiles ? » 😀
Je pense qu’on est tous plus ou moins d’accord, au final.
Pour préciser ma pensée : Pour moi, le rôle du framework est de faciliter l’appel d’objets (les contrôleurs) à partir de requêtes (les URLs), en y ajoutant quelques trucs pratiques (routage, plugins) et en unifiant quelques ressources (connexion à la base de données, à la session, au cache). Bref, simplifier et cacher les trucs dont on a besoin tout le temps quand on fait un développement web, pour permettre de se concentrer sur le « vrai » code.
Depuis le temps que j’y pense, il va vraiment falloir que j’écrive un article au sujet des ORM… 🙂
Et j’ajoute que notre problème n’avait rien à voir avec les annotations (même si les annotations à la sauce Doctrine sont justes à vomir de mon point de vue).
Le problème était le même avec un fichier de configuration traditionnel.
D’ailleurs, la multiplicité des formats disponibles pour configurer les frameworks ou les outils comme Doctrine est également à mes yeux le symptôme d’un problème quelque part, de la même façon que le KnpRadBundle.
À partir du moment ou il est nécessaire d’implémenter le support de plusieurs formats pour que les développeurs se sentent à l’aise avec au moins l’un d’entre eux, c’est que la simplicité n’est pas naturelle.
Et c’est la même chose avec l’empilage de couche de code nécessaire à la « simplification » de la mise en œuvre du framework.
Je vais me faire l’avocat du diable et défendre un tout petit peu les frameworks.
Le principal intérêt que je vois au framework est d’apprendre à programmer d’une manière
cohérente et de voir comment des gens, qui ont réfléchi longtemps, ont résolu certain problème courant.
Je trouve que le code source des principaux framework (ZF ou Symfony) est particulièrement soigné et mérite
une grande attention. Je reprend d’ailleurs souvent des trucs que je croise dans les framework.
Par contre, pour l’utilisation courante, je trouve ça tellement complexe qu’il est certain qu’ils font perdre du temps sur les projets simples.
@Eric : Oui, ce que tu dis est plein de sens. C’est aussi un bon résumé de ma pensée. 🙂
Merci pour ce post sympatique !
Cependant je me permets également de jouer le contradicteur 🙂
Pour moi commencer aujourd’hui un projet ambitieux sans Framework ( Zend, Symphony,…) est un non sens.
Evidemment si c’est pour faire une mini-maquette ou un truc rapidement ( projet de moins de 1 mois ) ca vaut pas le coup de se plonger dans la doc.
Si vous partez d’un truc maison vous allez in fine redevelopper Zend de manière mauvaise, faute de temps. Pourquoi ? Car il y a pleins de problématiques résoudre sur n’importe quel projet : authentification,droit,réecriture d’url, accès à la base,templats html, cache,formulaire ( bien gérer un formulaire est une grosse tache déjà ), et j’en passe..
Au fur et à mesure que le projet avance toutes ses questions se poseront. A chaque grosse perte de temps et de debug -> réinventez la roue
Sans compter que partir sur une structure standard permet à quelqu’un connaissant ce framework de rentrer plus facilement dans le code.
Bien entendu il est sympa de faire tout « from scratch » , c’est formateur. Mais ensuite partir d’un framework est vraiment un gens de temps précieux à mon sens
Lu dans un blog à propos de Smarty il y a quelques années déjà :
« Pourquoi développer un moteur de template en PHP, puisque PHP est déjà un moteur de template… »
Plus tard, j’ai entendu à propos d’un frameworks maison qui fabriquait des requêtes MySqL, mais bloquait LA requête dont on avait besoin : « c’est mieux de passer par le frameworks, mysql_connect, c’est mal ».
Sauf que le frameworks en question fesait un appel à mysql_connect presque directement…
La solution ? Faire une injection SQL !
Bref, il faut être pragmatique et critique…
À ce sujet, Symfony2 est une catastrophe. Pourtant, Symfony1, même s’il était parfois limité, permettait quand même de développer sans trop souffrir une application simple. Là on ne peut faire ni l’un ni l’autre… Les solutions autour de Symfony2 sont en plus toutes à côté de la plaque.
Pour les victimes de Doctrine, je leur conseille de tester les dernières versions de Propel. C’est simple, et surtout les dernières évolutions améliorent la vie du développeur.
@Marc et @Stéphane : Oui, personne n’a dit qu’il fallait jeter les frameworks. Le propos de l’auteur du manifeste est de dire code ZF à l’appui) que les frameworks existants sur trop complexes à utiliser à son goût, et que pour lui les micro-frameworks sont suffisants.
Moi, je dis que les micro-frameworks sont peut-être plus simple à utiliser, mais qu’ils ne cachent pas suffisamment les choses non plus pour moi, d’où mes choix d’implémentation pour le framework Temma.
On ne remet pas en cause la qualité du code des frameworks existants, ni le fait de ne pas réinventer la roue. Tout est une question de mesure et de préférence. L’intérêt des logiciels libres, c’est d’avoir le choix ; le choix de la solution qu’on souhaite prendre, le choix de l’adapter à nos besoins. L’intérêt de PHP, c’est que le choix est super large, avec un éventail de possibilités qui va du PHP pur jusqu’au framework full-stack avec moteur de templates et ORM. 🙂
Je crois que le moment est bien venu pour placer quelque sentence (pas trop définitive… quoique…)
La question à se poser est peut-être : Qu’est-ce au juste qu’un framework ? Et j’en arrive à la philosophie de base de Hoa : on sépare deux notions bien distinctement : le framework d’une part et les librairies d’autre part. Ce que j’entends par là, c’est que le framework, c’est le cadre de travail qui fixe l’architecture et la méthode de développement, les librairies, ce sont les packages qui traitent telle ou telle type de problématique.
Pour illustrer mon propos, je citerais mon propre exemple : j’utilise un framework maison qui fait appel à un certain nombre de packages, certains sont de mon propre cru, d’autres viennent d’ailleurs, pourquoi réinventer la roue si d’autres l’ont inventé tout court mieux que je ne pourrais le faire ? Ainsi, j’utilise php_mailer pour la gestion des envois de courriers électroniques, Zend_Pdf pour la création de documents PDF et Hoa_registry pour le registre de mon application, en parallèle avec des packages personnels pour la gestion des formulaires ou l’accès aux données par exemple. Si on fait l’amalgame entre librairies et framework, on ne peut qu’aboutir dans un mur, et à mon avis un solide. J’en arrive à la conclusion qu’utiliser un framework, ça signifie construire une application selon une architecture telle qu’elle a été pensée par les développeurs dudit framework, que ce soit ZF, SF, Hoa, Cake, Jelix ou autre, peu importe, et ça implique qu’on en a très bien compris le fonctionnement.
Ça ne peut en fin de compte que me ramener à un propos que je mentionnais plus tôt : si la documentation est moisie, on avancera pas dans nos développements en se posant trop de questions complexes et souvent insolubles parce que lesdites questions ne sont pas pertinentes. Le point de départ à mon humble avis, ça reste l’architecture de l’application. Pourquoi ? Tout simplement parce que c’est une question d’efficacité, et un problème de pérennité également. On doit pouvoir intervenir rapidement et efficacement sur une application qui tourne, en phase de développement dans un premier temps, mais aussi plus tard en phase de production, et ce sans devoir se prendre la tête à deux main en se demandant pourquoi il n’y a pas eu un météore capable de s’écraser sur le site du client histoire qu’on ait plus besoin de s’arracher ce qui nous reste de cheveux à tenter de retrouver ses petits dans le fouillis indescriptible qu’est son application, parce que cette application ne doit pas être un fouillis justement.
My 2¢
Bonjour / Bonsoir
Chouette ! encore un sujet intéressant sur ton blog.
Je me permets de partager mes observations collectées sur un projet relativement complexe d’e-commerce et l’utilisation d’un framework, après 1 an de développement continu.
Nous avons choisi Zend Framework pour les raisons suivantes :
– Nombre de modules disponibles dont nous avions besoins (orm, acl, search engine, pdf, cache…
– Respect des bonnes pratiques de développement (design pattern)
– Mise à jour/maintenance du code (société commerciale derrière)
– Documentation
– Clarté du code source
– Unit testé
– Communauté importante (=> recrutement)
La courbe d’apprentissage est relativement longue (+- 2 mois pour les bases) qui peuvent encore s’allonger si on a pas abordé d’autres MVC avant. Mais une fois dedans, on voit que tous les modules fonctionnent avec la même logique.
Cependant, je pense que tous framework home made ou ‘communautaire’, ou tout nouvel environnement on l’on s’intègre (nouveau projet, nouveau collègues, …) demande un temps d’apprentissage plus ou moins long.
L’utilisation du framework a eut l’effet bénéfique d’unifier notre façon de travailler, en appliquant la logique de Zend dans nos librairies métier. Ceci devant à terme simplifier l’intégration d’un nouveau membre d’équipe connaissant un minimum ZF. (temps d’intégration plus court).
Concernant la configuration, la première est fastidieuse si on la veut complète, mais elle restera utilisable dans 99% de vos autres projets basés sur ce framework. Le gain de temps est indéniable dans ce cas.
Une autre difficulté des framework est de connaître suffisamment les fonctionnalités disponibles dans ceux-ci, afin d’éviter de réinventer la roue. Cela nous est arrivé à deux reprises sur un an, par manque de temps et de recule. Puis Il y a toujours dans une équipe un pur et dur prêt à coder un serveur web ou à recréer un SSL à sa sauce 😉
En résumé, le cadre initial peut-être lourd et long, mais une fois en place et maitrisé, le framework permet d’accélérer le développement en simplifiant le code et en unifiant les connaissance de l’équipe.
Pour les détracteurs de full-stack, il faut savoir qu’il est possible d’utiliser uniquement telle ou telle libraire isolée sans embarquer tour le Zend et sans utiliser la mécanique MVC intégrée.
Pratique pour l’envoi de mails, la génération de PDF ou encore l’indexation d’un moteur de recherche (Lucene … terriblement efficace).
Maintenant, une constation générale sur l’utilisation des frameworks est qu’ils peuvent « tuer » les connaissances des languages et concepts de bases.
Quelques exemples concrets vécu (pouvant servir de test éliminatoire lors de recrutement 😉 :
• Un bon développeur JQuery incapable de manipuler un tableau en Javascript ou tout autre node du DOM
• Un développeur Java Web de bon niveau incapable de nommer la méthode principale pour lancer un simple programme Java, et ne connaissant pas la différence entre POST et GET, il avait appris des framework web qui occultaient trop fortement la base du langage.
Les framework tirent principalement leurs origines dans la programmation objet. Pour respecter en grande partie le MicroPHP manifesto doit-on en revenir au langage procédural ? La question est posée.
@Cyrano : La séparation entre librairies et framework est là encore une notion de mesure. Temma utilise aussi un ensemble de librairies (regroupées sous le nom FineBase) pour l’accès à la base de données, la gestion du cache, des sessions, …
Je ne connais pas aussi bien Hoa que d’autres frameworks, mais ma vision est qu’il doit être possible d’utiliser les mêmes briques de base qu’un framework, sans utiliser le framework entier ; c’est très pratique quand on doit écrire des scripts en ligne de commande, par exemple. Par contre, quand on décide d’utiliser le framework, son rôle doit être d’abstraire tout ça et de faciliter les développements au maximum. S’il faut écrire du code pour mettre les briques ensembles, c’est que le framework ne fait pas bien son boulot.
@Nauw : 2 mois pour apprendre les bases de ZF… ça illustre bien le problème, je pense. Les bases de Temma s’apprennent en 15 minutes.
Un exemple : Quand je fais passer des entretiens pour recruter des développeurs, il arrive un moment où je leur fais développer un mini-projet, en utilisant Temma. Si j’utilisais un framework dont l’apprentissage requiert 2 mois, j’aurais deux possibilités : soit je ne chercherais que des développeurs qui sont déjà opérationnels sur ce framework, soit je les testerais de manière absolument incomplète. Dans le premier cas, je passerais à côté de tous les développeurs intéressants qui ne demandent qu’à être formés ; dans le second cas, autant ne pas les tester parce qu’en cas de problème ce sera toujours la faute du framework et non celle du développeur…
On en revient au manifeste micro PHP : Je suis un développeur PHP, pas un développeur Zend Framework, Symfony ou CakePHP.
Encore une fois, je ne pense pas qu’on puisse considérer que l’envoi de mails ou la génération de PDF font partie du travail d’un framework. Les librairies en question, par exemple celles fournies par Zend, doivent être vues pour ce qu’elles sont : des bibliothèques de fonction très pratiques, mais qui n’ont rien à voir avec le framework lui-même.
C’est très exactement ce que je tente d’exprimer dans mes propos : le framework, c’est le moteur central de l’application, et en marge de ça, on a des librairies. Peut-être est-ce une question de sémantique ?
Or justement, le problème ne vient en général pas des librairies, il vient le plus souvent de la compréhension du fonctionnement du framework. Les librairies, ça fait longtemps depuis l’apparition du modèle objet dans PHP qu’à peu près n’importe quel développeur sait comment s’en débrouiller pour faire ce à quoi elles sont destinées pour autant qu’elles soient elle-même correctement conçues et documentées.
Avant l’arrivée des ZF, SF et autres, nous avions PEAR qui existe du reste toujours : mais c’est quoi PEAR au fond si ce n’est un paquet de librairies dont on ne prend que ce dont on a réellement besoin selon le traitement à effectuer. Ce que les « frameworks » actuels ont changé dans la vision générale, c’est schématiquement de regrouper le tout dans un bloc comprenant les éléments de gestion de la structure même des applications en fixant une architecture.
À la limite, il devrait être possible de choisir un framework selon tels ou tels critères, et à coté les librairies venant d’ailleurs. Ça peut vouloir dire que selon la manière dont sont nommées les classes et/ou les méthodes il faudra peut-être ajouter des adaptateurs pour la cohérence de l’ensemble, mais au final, le point important sera le choix du framework, le moteur. Et si on en revient au sujet de départ de ce billet, c’est la facilité de prise en main qui dirigera le choix, ce qui revient à dire qu’on devrait pouvoir comprendre très rapidement si la manière de fonctionner du framework correspond à notre besoin.
Pour les librairies, je ne suis pas convaincu qu’envoyer un mail avec une classe issue du ZF, de Symfony, de PEAR ou n’importe quelle autre soit fondamentalement différent. Si le moteur fourni par le ZF fait l’affaire mais que son package de gestion des courriel ne nous satisfait pas pour une raison x ou y, alors on doit pouvoir trouver rapidement comment traiter le problème avec le moteur pour appeler les classes d’un autre package qu’on aura pris ailleurs.
Mais au final, on en revient à cette distinction entre framework et librairie, le terme de framework étant volontiers utilisé à toutes les sauces pour désigner tout et n’importe quoi, incluant parfois carrément des CMS.
Bon, puisque tout le monde en remet, je vais aussi venir amener mon avis à ce débat !! 🙂
@cyrano +1. Je partage ta vision des choses sur la séparation framework / librairies… et je parlerai même d’API, utilisé à toutes les sauces maintenant. On ne se concentre plus assez sur l’aspect lib mais une lib n’a généralement pas besoin d’interfaces, c’est la gestion de l’interface qui complique tout.
En fait, pour moi, ca s’empile, et à charge des devs de choisir où
commençaient à « bosser » et avec quels outils.
Tout est effectivement un problème de sémantique.
Pour moi :
– Application = ce que veut le client ou le projet en interne
– CMS / ou A(pplication)MS = une application générique d’administration de pages / modules /plugins et systèmes qui par le biais de wysiwyg et import de modules vont une fois mis ensemble donner l’application du client
– Framework = Ensemble de fichiers/codes/configurations exécutés par un serveur web et un moteur de script (apache/php ?) qui vont générer le CMS/A(pplication)MS
– Librairies = Ensemble d’objets et de fonctions (en principe atomique 🙂 ) qui ont 1 rôle / 1 responsabilité
– Language = le language retenu (php, java, python, …).
Les bons outils dans tous cela, ceux qui nous permettent de modifier et intéragir au maximum aveccette « pile »/enchainement.
Et pour chaque projet, en fonction des attentes : perfs ? rapidité à sortir la solution ? sécurité ? maquettes ? nécessité d’évolutions spécifiques non standard ? Besoin d’une grande autonomie d’administration du client final ? etc… etc… etc… A charge du développeur de choisir le meilleur endroit dans la pile où « commencer » à bosser et à s’intégrer pour créer CE projet.
Pour moi, tout est relatif, et dépend donc ENORMEMENT du besoin de départ 😉
++
bon weekend à tous
J’avoue ne pas vraiment comprendre l’opposition « framework » != « simplicité ». En ce qui me concerne, cela fait 3 ans que je suis passé à Ruby on Rails et le gain de productivité est juste phé-no-mé-nal. Sans compter l’aspect reprise de code (je bosse en Freelance) : tout est à sa place, et on retrouve ses petits pratiquement comme si on avait soit-même codé l’appli depuis ses débuts.
Et puis il y a aussi l’aspect sécurité : token CSRF, XSS, injections SQL… je n’ose pas imaginer le délire si je devais tout me retaper à la main (et mal).
Franchement, pour moi, les Frameworks sont maintenant indispensables (idem pour le JS : vous imaginez 2 secondes un dév. sans JQuery ?!). Les besoins sont devenus beaucoup trop importants, il y a déja bien assez de boulot comme ça pour ré-inventer l’eau tiède à chaque projet.
Après par contre, là ou je vous rejoins, c’est que les Frameworks PHP sont (probablement, je ne connais pas assez en profondeur) un peu « pénibles » et pas simple de prise en main. J’avais essayé Cake et SF juste avant de tomber sur Rails, et c’est vrai que je n’avais pas été plus emballé que ça. PHP doit y être pour beaucoup, je pense… (houlla houlla, non, je troll pas, c’est juste un avis !)
Bref, tout ça pour dire : partir d’un language from scratch pour un dév. sérieux aujourd’hui, IMHO, c’est de la pure folie.
Entièrement d’accord avec Guillaume.
Je pense que le soucis c’est juste de se taper la doc pour comprendre l’architecture d’un projet. Mais au final ca se ressemble beaucoup ( RoR,Zend,Symphony, CakePHP,CodeIgniter,… ) car au final on retrouve la logique MVC.
Je pense que le problème est évoqué sur PHP car c’est un language où plusieurs communauté se retrouvent ( Ingénieurs développements, graphistes, intégrateur blog,…) alors que sur RoR c’est quasiment que des dev pur souche.
@Guillaume : Je partage ton avis concernant le fait de ne pas réinventer l’«eau tiède».
L’assertion « framework != simplicité » est démontré concrètement par l’auteur du manifeste par l’exemple de code ZF que j’ai recopié dans mon article. Mais, nous sommes d’accord, tout dépend du framework utilisé.
Sans vouloir nourrir le troll, je ne pense pas que quoi que ce soit provienne du langage. Et je ne pense pas que Ruby soit spécialement mieux armé que PHP face à la complexification ou la simplification du code applicatif. Tout est une question de philosophie de l’outil mis en œuvre.
Lol. Effectivement, ne nourrissons pas le troll. Quoique… 😉
C’est justement ça que je reproche à certains frameworks : même pour faire des choses simples, il faut d’abord mettre en œuvre des choses compliquées.
Le principe KISS c’est bien beau, mais qui n’a jamais connu de petits projets « simple » et qui au final se transforme en une usine à gaz incompéhensible ? Le framework est justement censé te permettre de maîtriser la complexité du projet en te fournissant un cadre plus ou moins rigide et standardisé. En contrepartie le coût du ticket d’entrée est plus élevé sans doute, mais 2 mois pour maîtriser les bases d’un Zend Framework je n’y crois pas, à moins de n’avoir jamais entendu du pattern MVC …
Après tout n’est pas rose bien sûr, il faut faire les bons choix dès le départ sinon on peut vite avoir l’effet inverse de celui désiré au départ en matière de maintenance et de productivité.
Le principal danger des frameworks selon moi concerne les nouveaux arrivants dans la sphère du développement web qui commencent de plus en plus à utiliser un framework comme Zend ou Symfony avant d’avoir une maîtrise profonde de leur langage (en l’occurence PHP).
Débat intéressant néanmoins.
Non surtout que la comparaison c’est plus Rails vs Zend ou Rails vs Symfony
Au final avec de bons développeurs dans les 2 cas on peut arriver à de très bons produit.
Après avoir lu/parlé avec 2 nombreuses personnes sur le sujet je pense que la bonne solution consiste plus à choisir en fonction de vos ressources ou capacités de recrutement. Sauf évidemment raison technique particulière.
Je pense que le débat doit ou devra plus se porter sur la base ( Mysql, MangoDB,… ) car là y’a une sacré différence !!
Je ne peux évidemment pas être d’accord avec ça. Si j’ai créé Temma, c’est bien parce que je ne trouvais pas ce que je voulais dans les autres frameworks.
On pourrait argumenter sur le fait que les différences se situent à la marge, par rapport au fait qu’ils embrassent tous le modèle MVC. Mais je pense que c’est justement dans ces différences que se situe la perte de temps.
Ce serait comme dire que coder en C++, en PHP, en Ruby ou en Python, c’est pareil, vu que ce sont des langages procéduraux orientés objet…
Bref, arrêtons le troll ici. 🙂
Ce que je voulais dire c’est que si on comprend la structure « MVC » appliqué à Zend, ou RoR, comprendre Temma est alors beaucoup plus facile….
Après chacun peut avoir de bonnes raisons de redevélopper ou de choisir tel ou tel framework ….
D’ailleurs je serais intéresser de savoir la tienne ( pas un troll mais pour ma connaissance personnel )
J’ai téléchargé Temma pour voir, bravo pour le taf
Il faut voir aussi que l’auteur de l’article source prend comme exemple censé être « représentatif du zend framework » la séquence d’initialisation et d’importation de la config au sein du contrôleur frontal. Ce fichier est auto-généré lors de la création d’un projet et le développeur qui utilise le framework n’a jamais besoin de mettre le nez là dedans, sauf cas exceptionnel de quelqu’un qui voudrait hacker le comportement de cette séquence d’initialisation.
J’imagine qu’une bibliothèque comme ZeroMQ doit avoir une séquence d’initialisation bien pire que ça.
Alors pourquoi est-ce qu’on nous la vante pour sa simplicité ? Parce que son API est simple et qu’en quelques minutes on est capable de monter une application réseau.
A mon avis, le code interne du framework peut être aussi complexe qu’on veut, c’est secondaire, et seuls ceux qui participeront à son développement seront concernés.
Ce qui est important, c’est que son API soit simple, claire, et facilement adaptable.
Ça va peut-être te décevoir Amaury, mais 5mn pour comprendre Temma, c’est uniquement sur papier. Samedi, j’ai passé plus de quatre heures dessus, pour finalement tout balancer par dessus bord : doc incomplète à cause d’éléments de base zappés, les devinettes me tapant de plus en plus sur le système avec les années. Ok, je ne suis pas ingénieur et je suis un autodidacte : pire, je travaille sous Windows… (j’ai suivi quelques liens pour trouver des infos et cet élément m’a un peu laissé sans voix…) mais sans succès pour ce qui est de faire au moins afficher la page de base.
Le problème est toujours dans la doc pour les mêmes raisons que j’ai déjà évoqué précédemment, sur tous les frameworks existant, je ne réserve pas cette sentence à Temma.
Du coup, j’ai un eu fouillé le sujet sur Internet et je suis tombé sur ceci [PDF], vraiment très instructif en matière de « framework » et surtout dans sa définition que je trouve la plus juste de toutes celles que j’ai pu lire ou entendre un peu partout jusqu’à présent. Le document mentionne explicitement un élément de base assez crucial : si le développeur ne comprend pas l’architecture, il ne pourra pas être opérationnel et sera encore moins efficace. Il appartient donc à l’architecte, ici en l’occurrence le concepteur du « framework » quel qu’il soit, de convenablement documenter de telle sorte que la prise en main soit la plus claire et complète. Mais bon, j’en arrive à ce que je disais déjà dans ma première réponse sur ce billet, je vais tourner en rond …
@Guillaume : la comparaison avec Ruby me semble hors de propos. Je suis certain qu’avec un minimum de bonne volonté, on doit pouvoir pondre une bouse en Ruby aussi. Le problème, ce n’est pas le langage mais sa documentation et celle des librairies disponibles. PHP a un coté un peu brouillon, mais à mon avis, victime de son succès il a eu du mal à se policer parce que la communauté qui s’est regroupée autour est beaucoup plus importante et d’autant plus difficile à cadrer, et c’est encore moins facile avec les milliers de contributions existantes en matière de code disponible, avec des qualités qui vont du meilleur au pire. Mais bon, c’est une impression personnelle peut-être complètement erronée, pourtant elle cadrerait assez bien avec la situation je trouve.
@Cyrano comme je disais tout dépend de tes expériences passées.
Perso j’ai regardé la doc Temma cela m’a paru trivial étant donné mon expérience passée. Car j’ai déjà testé BCP de frameworks de ce type
Evidemment pour quelqu’un qui n’a pas travaillé dans ce type d’environnement c’est bcp plus dur..
A l’époque j’avais commencé par regardé la video de CodeIgniter
http://codeigniter.com/tutorials/
ca pourra peut etre t’aider ?
@Marc : je travaille dans un environnement de framework au quotidien, à ce détail près que j’ai adopté un framework personnel. Pour paraphraser le manifeste-micro-PHP, je ne veux pas avoir à décortiquer des pages de code pour en comprendre le fonctionnement.
Le framework est là pour me simplifier la tâche en cadrant la manière de développer mon code métier, seule partie sur laquelle je devrais avoir à me concentrer. Or les frameworks posent un problème récurent : plus il est touffu et riche, plus il devient complexe : si la documentation ne suit pas, le gain de temps s’amenuise à grande vitesse.
@Cyrano je pense cependant que se taper de la doc compense largement le fait de redévelopper une roue carrée…
Dans ton framwork perso tu vas peux-être gagné du temps en lisant moins de doc mais tu vas en perdre en recreant toi même des solutions à des problèmes inévitables comme l’internationalisation, l’authentification, la gestion des erreurs de formulaires, les modules de vue, ….
Tout cela prend un temps FOU !!
Pour Zend ou CodeIgniter la doc est bien faite et y’a un forum actif.
Bien sûr que non, et c’est le point essentiel qui est à nouveau soulevé : c’est quoi exactement la définition d’un framework ? C’est un cadre de travail, et c’est théoriquement indépendant des librairies sur lesquelles vont reposer le code. Il y a une partie qu’on appellera par convention « Core » qui gère la partie architecture et les librairies pour traiter ces problèmes que tu évoques : gestion de formulaire, accès aux données, etc… Dans certain cas, j’ai greffé des packages maison, dans d’autres j’ai importé des packages issus aussi bien de Zend Framework que de Hoa ou d’ailleurs selon le cas et mon besoin.
Si on continue à faire l’amalgame entre framework et librairies, alors on va tourner en rond et personne n’aura raison ni tort, on sera tout simplement hors sujet. Suis le lien vers le doc PDF que j’ai indiqué tout à l’heure, ce sont des slides en PDF d’un cours d’architecture du CNAM, c’est vraiment très instructif et clair sur le sujet.
Tu évoques la doc : je m’en suis goinfré des kilomètres de toutes sortes. Il y a des années que j,ai découvert un truc fondamental : il est très difficile d’enseigner, parce que ça impose d’avoir une mémoire et de ne pas avoir oublié les difficultés par lesquelles on est soi-même passé. Sinon, on oublie plein de petits détails qui avec le temps deviennent pour soi des évidences. On oublie que le profane ignore totalement ces détails et leur importance.
Pour le rédacteur d’une documentation, c’est pareil, il y a beaucoup trop d’impasses et on table très (trop) souvent sur le fait que le lecteur « sait » ces détails comme si c’était l’enfance de l’art. Ça rend donc en fin de compte très difficile l’art de la rédaction d’une bonne documentation.
Pour le ZF par exemple, j’ai lu pas mal de doc, j’ai acheté de Bouquin de Julien Pauli et Guillaume Ponçon, mieux, je me suis même offert de ma propre poche une formation sur le ZF chez Anaska, formation où je n’ai rien appris que je n’avais du reste déjà vu dans ledit bouquin ce qui m’a fait constater avec une certaine amertume que j’avais purement et simplement balancé 2000€ par la fenêtre. Mais tout ça ne me rend pas l’utilisation du ZF plus simple : ça ne m’empêche pas d’avoir pu créer une extension pour des besoins spécifiques à Zend_Pdf que j’utilise pour produire des documents, j’ai juste intégré le package et ses dépendances dans la collection de librairies de mon système et ça fonctionne parfaitement bien.
Héhé, j’ai lu le manifeste et j’aime bien. Je suis développeur depuis 10 ans, et là je bosse dans une agence web dans laquelle on travaille sur du Zend.
Au début je me disais « cool », on va faire les choses vraiment carré, au final on est moins productif qu’avec le framework fait maison de la boite. Trop de structure tue la logique, on est obligés de passer par des chemins complexes pour faire des choses toutes connes. Autant le pattern MVC est consideré comme « la bonne méthode », autant j’ai l’impression que peu de gens se sont vraiment demandés si c’était quelque chose de très adapté au web
davidm > j’aimerais savoir en quoi le MVC n’est pas adapté au web, je suis curieux de lire tes arguments 😉
@Cyrano :
C’est bizarre que tu ais passé tant de temps sans réussir à le faire fonctionner. La seule explication que je peux avancer, c’est que Temma n’a jamais été pensé pour fonctionner sous Windows. Je sais que plusieurs personnes l’ont fait (en interne chez Fine Media, mais aussi à l’extérieur), mais je ne l’ai jamais testé personnellement sur cette plateforme.
Bon, plutôt que de batailler pendant 4 heures, il aurait fallu me contacter, je t’aurais aidé avec plaisir ! 🙂
La documentation n’est pas un exercice aisé. J’ai essayé de faire une doc accessible, simple et didactique, mais j’ai assurément oublié plein de choses, ou pris pour acquis des choses qui ne le sont pas forcément. N’hésite pas à me signaler ces oublis, pour que je complète la doc en conséquence.
On est pleinement d’accord sur cette définition. Toutes les librairies additionnelles sont, à mon sens, utilisées par le code métier pour réaliser le travail demandé. Le framework est là pour faciliter l’appel au code métier, pour ne pas réinventer la roue à chaque fois. Pas pour gérer des formulaire, des envois d’emails ou de la génération de fichiers Excel.
Je n’ai pas lu tous les commentaires, et peut être que mon avis a déjà été formulé, mais je pense que, en plus de souvent compliquer les choses, les gros frameworks type symfony2 risquent d’uniformiser la manière de développer des gens.
Bientôt, on n’apprendra plus PHP, mais Symfony. Tout le monde fera son site de la même manière. Tout le monde utilisera les mêmes bundles, qui auront donc tous les mêmes bugs. Bugs qui seront plus ou moins graves, mais dans le cas d’un problème de sécurité critique, le temps que celui-ci soit réglé, les nombreux sites utilisant Symfony seraient vulnérables.
C’est pourquoi, je pense qu’utiliser un micro framework, répondant tout juste aux besoins de base, et développer ses propres plugins par dessus, est la meilleure solution. Car dans ce cas, certes il y aura des bugs, certes le site sera parfois vulnérable, mais étant un cas isolé, et ayant une architecture méconnue de monsieur tout le monde, il restera mieux protégé.
@drazik : Le sens de l’histoire est plutôt de montrer que la sécurité par le secret est rarement une bonne chose dans la durée. C’est tout l’intérêt des logiciels libres. Être plusieurs à auditer un code et à corriger ses failles est plus efficace que de laisser un hacker les trouver en premier.
Après, cela veut dire qu’il faut s’informer sur les mises-à-jour de sécurité et patcher son système régulièrement. Mais cela fait partie du boulot, et c’est plus simple que de corriger soi-même toutes les failles.
Néanmoins, ta remarque n’est pas idiote. Si on regarde, concrètement, le nombre de serveurs qui ont été piratés à cause d’une faille dans un PHPBB ou un système du genre, simplement parce que la faille a été publiée mais pas corrigée suffisamment rapidement, et qu’au même moment les hackers avaient déjà fait des scripts pour l’exploiter à très grande échelle…
Pour revenir à la question initiale, je dirais que l’important est de pouvoir choisir en fonction de nos goûts et de nos besoins. La standardisation n’est pas une mauvaise chose ; l’unification est déjà plus discutable.
Bonjour Amaury,
Je suis actuellement en train de m’interesser a votre framework Temma, et j’en profite pour revenir sur ce post que j’avais lu il y a quelques jours, et larguer rapidement ici un lien vers un article que je viens de lire et qui va dans le même sens que tout le monde ici 😉
http://www.alexhudson.com/2012/03/24/a-fond-farewell-to-zend-framework/
@Rody : Merci pour le lien, l’article est très bon.
N’hésite pas à me faire un retour sur ton utilisation de Temma, ou à me poser des question.
Je viens de lire tout les commentaires, et je suis rassuré de voir que pas mal de devs partagent mon expérience des frameworks.
On confond en effet trop framework et librairies, un frameworks ne devrait à aucun moment générer du html (gestion des formulaires des tableaux ..) c’est le rôle d’une librairie. UN framework ne devrait en aucun cas gérer les identifications, c’est le rôle d’une librairie. A mon humble avis un framework devrait se contenter de gerer le cadre MVC (je parle bien du cadre et pas de son application, pas question de me coller un ORM dans les pattes par obligation) et point barre.
Tout ce qui facilite la vie du dev au quotidient c’est le rôle des librairies et classes metiers.
Le framework idéal selon moi devrait se contenter d’un bootstrap lançant le bon contrôle, d’une méthode d’appel simple aux modèles et vues et basta.
Je pense même que les faux frameworks à la ZF ou SF contribuent au manque de reconnaissance du métier de dev en france, après tout un dev ne fait que jouer au legos.
Ca contribue même au nivelement par le bas, quand les jeunes arrivent sur le marché gavés d’ORMs, faut pas s’étonner ensuite qu’ils ne sachent pas pondre un requête sql valable.
Sur mon dernier gros projet pro (3 ans de dev avec des moutons a 5 pattes a tout les coin de rue) faute de trouver un framework correspondant à mes attentes j’ai codé moi même un squelette MVC de base, et y ai greffé les librairies qui m’étaient utiles.
Mais je continue de rêver du framework MVC idéal, un simple squelette MVC à habiller, sans une once de chair inutile sur les os.
@Karedas : Je suis assez d’accord avec toi. Jette un œil à Temma, et n’hésite pas à me contacter directement pour me dire ce que tu en penses.