Car j'ai un avis, ne serait-ce que parce qu'en plus de 10 ans d'expérience professionnelle, j'ai eu le temps de développer quatre frameworks, de discuter avec d'autres créateurs, d'en utiliser que je n'avais pas créé et de concevoir des projets en pur
PHP.
Et je vais être immédiatement très clair, à titre strictement personnel, je n'aime pas utiliser de framework, pour plusieurs raisons, dont voici une liste non exhaustive.
Tout d'abord, je préfère, et de loin, trainer mes guêtres dans les couches basses d'une application, dans les coins sombres et reculés que peu de développeurs aiment arpenter, tout simplement parce que c'est à ce niveau que je trouve le challenge technique qui me semble le plus gratifiant à résoudre intellectuellement.
Le corollaire de cela est que je trouve beaucoup plus intéressant de concevoir un framework que de le mettre en œuvre.
En effet, un framework a pour but de simplifier les développements, et en développer un implique donc de devoir résoudre des problèmes plus ou moins complexes, ou en tout cas suffisamment délicats à résoudre pour que cela vaille le coût de se lancer dans un tel développement.
Ensuite, les frameworks imposent un certain nombre de règles, parfois explicitement, comme les conventions de codage, mais aussi parfois implicitement, de part leur conception.
Et dans les deux cas, il est totalement impossible de prévoir les implications que ces règles auront sur les développements futurs.
Or, de part mon expérience, je sais qu'à partir d'un certain niveau de complexité ou pour répondre à certain besoins exotiques
, l'utilisation d'un framework devient plus un inconvénient qu'un avantage.
En effet, dans certain cas, il devient nécessaire de court-circuiter le fonctionnement normal du framework pour obtenir le résultat désiré, et outre le fait que cela nécessite du temps en terme de recherche et développement (alors qu'un framework est censé permettre d'en gagner), bien souvent, c'est également une source d'erreurs et de problèmes à plus ou moins long terme (alors qu'un framework est normalement conçu pour limiter le risque d'erreur et simplifier la vie des développeurs).
D'ailleurs, à la réflexion, il n'y a pas besoin de devoir faire face à une problématique complexe ou un besoin étrange pour se retrouver dans ce cas, puisqu'il suffit parfois de devoir simplement, par exemple, mettre en place des tests unitaires.
Si le framework considéré met en œuvre massivement des singletons, n'utilise pas l'injection de dépendance, bref, n'est clairement pas conçu dans l'optique de permettre au code d'être testé, il faut avoir recours à des ruses et des techniques peu avouables pour arriver au résultat désiré, et dans le pire des cas, il est même impossible de répondre totalement au besoin.
Un autre problème que me pose les frameworks est qu'il n'est pas possible de mesurer leur efficacité.
L'une de leur raison d'être est en effet d'améliorer la productivité, mais dans les faits, je ne connais aucune étude qui permette de dire que pour un projet mené à bien, un framework a permis de gagner X % de productivité.
Or, encore une fois par expérience, je pense que ce gain de productivité est loin d'être au rendez-vous dans tous les cas de figure, et qu'en fonction des projets et de leur problématique, un framework peut dans le pire des cas faire perdre du temps, et au mieux permettre une productivité égale à un développement sans framework, et cela à cause d'au moins trois facteurs.
Le premier facteur est évidemment celui que j'ai énoncé précédemment, à savoir qu'il faut parfois passer énormément de temps pour parvenir à court-circuiter le fonctionnement du framework afin de répondre à un besoin spécifique.
Le second facteur est qu'il arrive que l'on soit amené à être obligé d'utiliser une fonctionnalité peu ou pas du tout documenté, parce qu'on a besoin de sortir des sentiers battus, pour une raison ou pour une autre.
Dans ce cas, le développeur se retrouve à devoir mettre le nez dans le code en profondeur, à étudier son fonctionnement, à tracer la pile d'exécution, à afficher le contenu d'objet pour comprendre ce qu'il se passe, à devoir utiliser xdebug, etc.
Bref, il se retrouve a devoir sortir l'artillerie, alors qu'il ne devrait pas avoir à le faire puisque, encore une fois, le framework est censé lui simplifier la vie.
Le troisième facteur est l'ergonomie du framework, qui peut, lorsqu'il est mal conçu, ou bien lorsqu'il a une philosophie de développement peu usuelle, demander au développeur un effort d'écriture conséquent pour répondre à un besoin simple.
J'ai ainsi déjà rencontré un framework qui demande au développeur d'écrire en PHP plus de deux fois la quantité de code HTML effectivement produite par le framework, sans parler des interfaces de classes alambiquées ou mal conçu qui obligent à une gymnastique mentale permanente.
Dans ce genre de cas, il est légitime de s'interroger sur le bénéfice apporté par l'outil...
Un autre problème que me pose les frameworks est que, de par leur nature, ils masquent une complexité.
Or, cette complexité existe toujours, et un jour ou l'autre, pour une raison ou une autre, le développeur y sera forcément confronté, et, loi de Murphy aidant, cela se passera certainement au plus mauvais moment possible.
Et comme le développeur n'y aura jamais été confronté, il ne saura pas gérer la situation, ou en tout cas moins bien qu'un développeur plus au fait des mécanismes internes à PHP.
De plus, ce masquage de la complexité induit une perte de savoir-faire, car plus personne ne sait ce qu'il se passe sous le capot, pour reprendre une métaphore mécanique cher à certain dans ce débat.
Il y a donc de moins en moins de mécaniciens capables de le soulever pour résoudre les problèmes.
Je ne compte plus les stagiaires qui n'ont pas su répondre à une question pourtant simple parce que leur cher framework fait tout le travail pour eux et qu'ils n'ont absolument aucune idée des mécanismes sous-jacents.
J'ai même eu le cas extrême de l'un de mes collègues actuels qui m'a dit qu'une fois qu'on avait essayé son framework favori, il n'était plus possible de refaire du PHP, et j'avoue qu'une telle attitude m'effraye quelque peu.
Alors certes, je sais très bien que personne ne peut tout maîtriser, mais il y a un socle minimum de connaissances qu'un développeur se doit de posséder, et actuellement, je pense qu'il se réduit de plus en plus.
Et si l'enseignement a sans nul doute sa part de responsabilité dans ce phénomène, comme le souligne Hugo Hamon dans son commentaire au sujet du billet de Goulwen Reboux sur le même thème, je pense que que les frameworks en ont également une, ou qu'en tout cas, à minima, il n'arrange pas la situation.
<parenthèse>D'ailleurs, en parlant de la responsabilité de l'enseignement, je me souviendrais toujours de ma réaction interloqué lorsqu'au moment de noter un stage et la soutenance associée, les deux professeurs
présents m'ont annoncé avec le plus grand sérieux que la moyenne dans leur établissement (une école d'ingénieur) était 12 et qu'il n'était pas bien vu de noter en dessous.
Sur le coup, je n'ai rien trouvé de mieux à répondre que de leur demander s'ils notaient sur 24, d'autant que le travail du stagiaire ne méritait pas mieux qu'un 7 à mes yeux...</parenthèse>
Voici donc quelques unes des raisons pour lesquelles, à titre personnel, je n'aime pas utiliser un framework.
Maintenant, faut-il pour autant jeter le bébé avec l'eau du bain ?
Je sais que cela peut paraître très paradoxal avec tout ce qui précède, mais Je pense que dans un cadre professionnel, un framework bien construit et utilisé à bon escient, en toute connaissance de cause, est un outil puissant qui a beaucoup plus d'avantages que d'inconvénients, ne serait-ce que parce qu'il permet de structurer et d'industrialiser les développements.
De plus, dans la grande majorité des cas, un framework apporte une réponse efficace et rapide à tout un ensemble de problèmes, surtout lorsqu'il est utilisé pour ce pourquoi il a été conçu.
Enfin, même si les frameworks actuels ne sont pas parfaits, et ne le seront d'ailleurs jamais, ils sont en amélioration constante, et je ne doute pas qu'à terme, une bonne partie des problèmes qu'ils me posent n'existeront plus ou seront en tout cas fortement atténués.
De mon point de vue, ils ne sont donc pas le Mal en entreprise, mais à la condition que, comme tous les outils au monde, ils soient sélectionnés et utilisés par des personnes compétentes, qui comprennent parfaitement ce que leur utilisation implique en terme d'avantages et d'inconvénients, qui sauront en tirer le meilleur parti en les utilisant au maximum de leurs capacités lorsqu'il y a lieu et qui sauront également à contrario, parfaitement s'en passer ou les contourner lorsqu'il le faut.
Un framework n'est qu'un outil, et un outil ne remplacera jamais un cerveau humain bien utilisé.
33 réactions
1 De usul - 11/01/2011, 17:09
Comment résumer ma pensée, ah si, +1
Comme je te l'ai déjà dit, pour moi, il y a ceux qui utilisent les fwk et ceux qui les écrivent.
Et effectivement, ce qui est important c'est le choix et les motivations qui guident ce choix.
2 De MathRobin - 11/01/2011, 17:14
Bien vu, ceci dit, je dirais plutôt que pour qu'un framework soit bien utilisé, il doit déjà ne pas être utilisé par un débutant.
Quel débutant sait utiliser xDebug ou simplement un print_r(), tout le temps que je passe depuis des années sur certains forums d'entraide de développeurs me l'ont prouvé, un débutant qui maîtrisent ça, ça n'existe pas.
De plus un framework, ça ne s'utilise pas "comme ça". Bon certes, ça se court-circuite quasi systématiquement pour répondre aux besoins du projet, même si je préfère dire que je surcharge le comportement standard. Mais surtout, il faut avoir reçu une formation réelle. Apprendre sur le tas, c'est bien joli mais il y a pas mieux pour passer du temps empêtrer comme pas permis dans la multitude de classes dont on n'a parfois même pas la moindre idée de leur utilité. La doc peut aider, mais pas toujours.
Bon après, bien entendu, tout dépend de la qualité de la formation.
Mais honnêtement et pour exemple, sans l'aide de tout un tas de tutos, je n'aurais jamais réussi à déployer le zend framework dans sa version MVC comme ça avec juste le "get started" de zend. Et encore, il y a un paquet de trucs que je n'ai jamais réussi à mettre en place.
Ton point de vue est intéressant en tout cas.
3 De Michel Pigassou - 11/01/2011, 17:45
Je dirais plutot que *certains* framework sont de la merde, à plus forte raison s'ils ne permettent pas de faire des tests.
Le problème est qu'en PHP, les débutants ou ceux qui maîtrisent mal le langage font vite du code spaghetti horrible, et une entreprise peut rarement se permettre d'avoir un tel code ou de revoir son architecture régulièrement parce que 3 personnes sont intervenues dessus et qu'aucune n'a suivi les logiques des autres. Là, les frameworks sont aussi importants et permettent de gagner du temps (ou d'éviter d'en gaspiller en s'éparpillant) mêmes si les personnes ne sont pas capables de se rendre compte de la facilité qu'ils offrent.
Les framework pour les utilisateurs avancés, je dirais oui, mais dans un monde (et une entreprise) idéal.
4 De Eric - 11/01/2011, 17:50
Excellent.
Pour une fois, je suis entièrement d'accord
De mon point de vue, les frameworks rendent complexes les choses simples et ils rendent impossible les choses complexes.
5 De Steuf - 11/01/2011, 17:54
@mageekguy Je plussoie ! Aujourd'hui tout le monde ne jure que par les Frameworks et cela a sérieusement le dont de m'énerver, surtout quand on t'avance un framework parce que "Il est bien" (En général ceux qui viennent de découvrir 1 Framework), et que celui-ci ne comprend pas que tu veuille en utiliser un autre parce que par a+b il répond mieux au besoin... Car chaque framework étant différent, suivant le contexte l'un sera mieux qu'un autre et c'est bien pour cela que je ne préfère ni l'un ni l'autre... Pour moi c'est juste un outil comme un autre qui doit répondre au mieux au besoin au moment T (et aux moments T+n).
Et ceci sans compter le massacre des performances que cela implique... Je me rappel de la première requête SQL exécuté avec Zend, quand j'ai vu 5Mo de Ram utilisé (Sans Xcache qui n'est pour moi que du cache misère comparable à de la vaseline et masquer la réalité) j'ai faillé faire une syncope...
6 De NiKo - 11/01/2011, 18:09
Alors ça c'est bien vrai. Sans oublier quand même, une fois codé, de l'utiliser soi-même sur de vrais projets, sinon ça peut rapidement poser des soucis.
7 De Cyrano - 11/01/2011, 18:54
J'approuve également presque sans réserve cet exposé.
Le petit bémol que je mettrai concerne la définition même de ce qu'est (ou devrait être) un framework. À écouter bien des chroniqueurs (ou prétendus tels), c'est tout juste si on ne pourrait pas faire le café avec ça. Oui, merci, avec deux sucres s'il vous plait :D
Étant autodidacte en PHP, ma vision intéressera peut-être certains qui ont une approche plus académique. Le PHP à l'origine était avant tout un langage accessible. Il n'en demeure pas moins que si on a pas de logique élémentaire, on ne fera rien de plus en PHP qu'avec n'importe quel autre langage de programmation. Il me semble que l'idée générale du framework part de la philosophie DRY (Don't Repeat Yourself) et je suis bien entendu tout à fait favorable à cette idée. Mais quand je parcours un peu les classes d'un framework, prenons le ZF par exemple, il m'arrive d'avoir l'impression que certains se sont bien éclatés à développer un truc hyper-balèse... et inutilisable par le commun des développeurs parce que justement trop complexe et peu, mal voire pas du tout documenté. On a aussi des packages traitant trop de choses à la fois sans qu'on puisse vraiment dissocier certaines parties qui serait vraiment utiles.
Pour en revenir à la définition, je pars personnellement du principe qu'il y a (en tous cas il devrait y avoir) deux parties fondamentales : les librairies/packages et le cadre de travail proprement dit. À de très rares exceptions près, on devrait pouvoir virer de la librairie tous les packages dont on a pas besoin et pour que ce soit possible, on ne devrait pas y trouver de dépendances directes à coup de requires, includes et autres variantes. Quant au cadre de travail, j'ai à l'usage de plus en plus l'impression qu'il est difficile voire impossible de faire quelque chose de réellement générique pour n'importe quel type d'application sans faire une usine à gaz dont on utilisera de 15 à 30% dans une application donnée selon son type.
Est-ce que le framework n'est pas avant tout une forme de méthodologie que chaque développeur digne de ce nom devrait comprendre globalement avant d'être tel ou tel édité par un majeur (ZF, Symfony, etc..) ?
Enfin bon, pour ce que j'en dis hein
my2¢
8 De Eric - 11/01/2011, 19:08
@steuf: comment tu fais pour avoir la taille de la RAM consommée par une requête SQL ?
9 De metagoto - 11/01/2011, 19:45
Comme disait je ne sais plus qui de surement influent,
.Contrairement à pas mal de langages/technologies, PHP a toujours fourni toute une artillerie de fonctions et de facilités pour faire des applications web.
Normal, c'est ce pourquoi il a été conçu.
En revanche, toutes ces facilités sont restées à un niveau relativement bas, au point que l'on confonde ce qui appartient au langage et ce qui appartient à la
(standard).Par la force des choses (et la difficulté apparente d'avoir un système PEAR fonctionnel), la communauté de PHP n'a jamais eu une culture d'utilisation et de partage de librairies, alors même que tout était réuni pour qu'une telle communauté émerge.
Encore une fois, PEAR a un peu plombé tout ça, ou du moins, c'est mon avis.
Du coup, tout le monde réinventait la roue.
Certes, certains projets se détachaient du lot, je pense notamment à Horde ou Drupal, mais aucun n'a eu une influence suffisante pour faire basculer les mentalités.
Puis il y eu la release de Ruby on Rails qui précédait tout juste le nouveau PHP 5 avec son support objet accru.
C'est là que tout s'est joué.
Zend a annoncé son intention de fournir un framework aussi
et que RoR.En parallèle, on a vu une explosion de frameworks.
Des trucs comme Seagull ou WACT, je ne sais pas si ça vous dit quelque chose et je repense à cette époque avec nostalgie.
La créativité et l'enthousiasme débordaient, les forums étaient gavés de questions et présentations de techniques toutes plus ou moins exotiques de mises en place de
pour effectuer tels ou tels opérations au sein du glorieux MVC.De tous ces frameworks, seule une poignée ont survécu.
D'autres ont vu le jour sur les restes et erreurs grossières de leur prédécesseurs.
Je dirai qu'on aborde depuis 2010 la 4ième génération de frameworks PHP, la troisième depuis RoR avec ZF2, Symfony2, Lithium...
Je comprends que les "anciens" développeurs aient gardés cette mentalité des pionniers qui consistait à faire un require_once() dès la première ligne de code. Bon, ça n'a pas trop changé de nos jour, mais au moins ces développeurs le faisaient en toute connaissance de cause (l'élite utilisait la directive
auto_prepend_file
).Je suis personnellement POUR les frameworks. Ne serait-ce que parce qu'ils apportent un certain gage de maturité à la communauté.
Les frameworks qui se détachent, ceux qui sont cités dans les offres d'emplois, ne sont pas si mauvais et/ou néfastes que cela en terme de productivité, pertinence, bref, tout ce qu'on peut reprocher à un framework.
S'ils étaient si nuls, d'autres auraient pris leur place.
Encore une fois, la nature de PHP laisse grande ouverte cette possibilité.
Comme dit judicieusement dans le billet, un framework est juste un outil.
Il faut apprendre à s'en servir et ça demande du boulot.
Et oui, il faut être armé
pour faire face à des situations impromptues, comme n'importe quelle personne utilisant n'importe quelle librairie et donc framework.10 De Romain - 11/01/2011, 20:05
Je pense qu'il s'agit avant tout d'une histoire de maturité des frameworks.
Les frameworks prennent tout leur sens avec la POO, qui est somme toute qqch de
en PHP.Dans le monde J2EE, certains frameworks comme les commons d'Apache (pour ne citer qu'eux) sont tellement éprouvés qu'ils sont absolument incontournables, d'une part, et qu'ils constituent un socle commun, même pour un développeur débutant, qui peut ainsi intégrer des projets existants et comprendre le code.
Je pense qu'il ne faut effectivement pas jeter le bébé avec l'eau du bain, mais travailler pour améliorer ces frameworks et les rendre incontournables : dans 99.99999% des cas, je ne vois pas l'intérêt de réinventer la roue et coder une transaction d'accès en base non ? :p
11 De Da Scritch - 11/01/2011, 21:56
Le gros problème, c'est que certains frameworks ont été conçus du temps de PHP4, et qu'on en est au PHP 5.3.
Résultat : ils ignorent totalement les dispositifs de filtrage, les PDO, une gestion moderne de classe, les outils récents de débugs, simple_xml, le mb_*, voire les conventions XHTML ou HTML5.
Et même pire : ils induisent en erreur en obligeant d'utiliser des fonctions qui sont complètement obsolète ou erronées du point de vue sécurité.
Je suis comme toi : j'ai conçu deux ensembles de libs (ce qu'on peut abusivement appeler framework) afin de me faciliter le travail mais aussi de me frotter aux règles actuelles de développement primaires.
Et rien que pour faire très proprement une gestion de session avancée en prenant en compte les dernières avancées côté navigateur, ben vaut mieux prendre ses organes génitaux à deux mains, se plonger dedans et ne pas hésiter à demander d'auditer son code.
Il vaut mieux progresser en maîtrisant les basiques tout court, qu'en connaissant les basiques d'un framework dépassé.
Or, le problème, et je le dis d'autant mieux que je suis autodidacte, c'est que je vois un nombre conséquent d'écoles
qui apprennent à leurs élèves comment créer du code à partir d'un framework (ou d'un CMS vu comme un framework, ce qui est carrément délirant), afin d'être plus rapidement sur le marché du travail.Résultat, des projets mals maîtrisés, mal quantifiés, et pas sécurisé.
Le nombre effarant de sites pondus avec Joomla me laisse pantois : ça représente 50% de mes clients qui sont confronté à un machin horriblement complexe qu'ils n'arrivent pas à comprendre.
Et le plus drôle, c'est quand on voit que pour palier certains manques de ces frameworks, le code créé à cette occasion n'est absolument pas sécurisé.
Cela dépasse le PHP : j'ai vu des sites en Java (facturé à 6 chiffres) composés de plusieurs dizaines de libs accolées les unes aux autres, dont certaines ont des fonctions identiques mais non communes, juste pour céder à la facilité et par totale ignorance.
12 De Olivier Mansour - 11/01/2011, 22:13
La plupart des textes sur les frameworks ont été écrits par des des experts.
On y retrouve un peu le syndrome
.Ces réflexions manquent selon moi de pragmatisme et de recul sur ce qui se fait réellement aujourd'hui (je ne parle pas de ton texte qui est équilibré).
Peu traitent de l'aspect bénéfique de pouvoir structurer une équipe importante sur une même base de code source et des pratiques communes.
C'est vrai qu'aucune étude n'existe (enfin, l'informatique est un métier jeune). Alors je parle depuis ma modeste expérience de développeur devenu manager (hou hou).
Je veux dire que d'un aspect purement business (hou hou bis) il faudrait vraiment
utiliser un framework.A l'ère de PHP4 je préconisais déjà le framework Seagull en SSII.
C'était pourri (non mais vraiment), mais par contre je pouvais réunir une équipe de cinq bonhommes de niveau divers, ne se connaissant pas, et les mettre au boulot en quelques jours.
Ils n'avaient pas à définir toute l'architecture technique car un bon bout était fait dans le framework (oui bien sur, mal fait et pas comme tu l'aurais fait … mais fait tout de même) et beaucoup d'éléments de bases étaient déjà présent (avec tout leur défauts mais déjà présent).
Quand j'ai fait du SF 0.6 je l'ai fait pour les mêmes raisons.
Alors oui, c'est vrai, quand tu mets des machines dans ton usine il faut les acheter et embaucher des mecs pour les entretenir et expliquer comment ça marche aux autres (et les convaincre de les utiliser). Mais au final ça change plus le monde !
Et sinon je suis bien ok avec tes réserves sur les précautions à prendre avec l'usage d'un framework. Par ex, j'aurais ajouter la séparation des concepts métiers du framework pour pouvoir plus facilement les extraire etc…
bye
ps : de toute façon les développeurs ne sont jamais contents : PHP, leur framework, IE6 ;-).
Mais c'est aussi pour ça qu'on les aime.
13 De desfrenes - 11/01/2011, 22:39
On dirait moi qui tente de faire du
Zend_Form
.14 De CC - 12/01/2011, 08:59
Par analogie, nous sommes des peintres.
La toile est la page HTML, et la palette des couleurs de base est PHP.
On peut utiliser ces couleurs, les mélanger et obtenir des millions d'autres couleurs à étaler sur notre tableau, ou on peut avoir une palette prédéfinie des couleurs les plus utilisées mais qu'on ne pourra que difficilement mélanger.
A mon goût, il n'y a pas de côté artistique aux frameworks et j'y trouve moins de plaisir, voire aucun. Bon après je n'ai pas la contrainte de temps ou le cahier des charges d'un client, sinon ce ne serait plus ma passion mais un boulot ingrat :).
15 De Steuf - 12/01/2011, 10:32
@Eric Je parle de mémoire alloué au script à l'exécution par PHP, j'ai pris comme exemple une requête SQL, ça aurait pu être n'importe quel module de Zend
16 De Amaury Bouchard - 12/01/2011, 12:13
Je serais plus nuancé.
Si on replace les choses en contexte, les frameworks sont particulièrement utiles dans les cas où on doit sortir de nouveaux projets rapidement et fréquemment. Une manière de ne pas réinventer la roue, en quelque sorte.
Évidemment, ce n'est pas toujours optimal, ce n'est pas toujours comme on voudrait que ce soit, mais ça reste systématiquement un gain de temps de développement, et dans certains contextes professionnels, c'est une contrainte particulièrement importante.
Maintenant, si on travaille sur des projets plus "stables", qui vont avoir un cycle de vie plus long, sur lesquels on va vouloir travailler en profondeur, les limites d'un framework peuvent se faire sentir assez vite.
Si on schématise, on aurait
et .C'est simpliste, mais il y a un fond de vérité.
D'un autre côté, il est possible de mettre en place des frameworks minimaux, qui aident au développement sans pour autant se mettre en travers du développement. Celui qu'on utilise dans ma boîte, que j'ai développé et fais évolué, est à la base un système de mapping très simple, pour qu'une URL du style "/toto/tutu/aa/bb" fasse en sorte d'appeler automatiquement TotoController->execTutu("aa", "bb"), plus une gestion de templates (à base de Smarty), une gestion du cache (à base de MemCache) et un système de plugin pour faciliter la réutilisation.
C'est simple, ça accélère les développements (on code des contrôleurs et des objets métiers), mais ça laisse aussi toute latitude pour sortir des clous quand il y en a besoin.
Par contre, je serais critique sur les ORM, avec quasiment tous les arguments que tu utilises au sujet des frameworks, mais c'est un autre sujet dont on pourra rediscuter à l'occasion.
17 De Amaury Bouchard - 12/01/2011, 12:22
@Steuf : Je comprends que tu sois horrifié de la consommation mémoire de ZF. 5 MO pour la moindre requête SQL...
Mais d'un autre côté, je connais des gars qui développent en Lua (oui, y'en a qui font du Web en Lua, pourquoi pas), qui rigolent quand ils voient les ressources (mémoire et processeur) consommées par l'interpréteur PHP...
Les frameworks c'est nul, c'est gourmant. Il y a une époque, on entendait la même chose à propos des langages orientés objet. À une époque, c'était pareil pour tous les langages interprétés. Et comme on ne va pas coder nos sites Web en assembleur... on a toujours la possibilité d'écrire les parties les plus critiques sous forme de modules Apaches, en C. Moi j'ai arrêté.
18 De nautilebleu - 12/01/2011, 15:24
La phase de conception est toujours plus intéressante que la phase d'exécution.
Comme tu dis, c'est là qu'on peut montrer ses plus grands talents de développeur.
D'un autre côté, c'est en mettant en production qu'on a des feedbacks, qu'on peut voir des dévs faire des trucs avec ton code que tu n'avais pas imaginés et puis voir son code exploiter en production, c'est aussi assez gratifiant, non ?
19 De Guile - 12/01/2011, 22:09
Tu peux me donner le nom de l'école d'ingé en question par mail? J'ai l'impression de la connaître : la mienne a justement cette politique que je n'ai jamais comprise...
20 De Steuf - 13/01/2011, 08:21
@Amaury Bouchard Oui bien sur les choses évoluent et consomment plus ou moins de ressources. C'est l'évolution plus ou moins normale que l'on connais de l'informatique. Mais bon il ne faut pas abuser quand même, pour moi rien ne peut justifier autant de mémoire utilisée pour si peu de chose... D'ailleurs la consommation mémoire est l'une des principales critiques envers Zend. Et encore je ne parle même pas de Ez Components/Ez Publish ou l'on atteint des sommets de sadomasochisme (Ou le principe doit être rendre ultra compliqué et obscure ce qui est simple...)...
21 De mageekguy - 13/01/2011, 09:27
@Guile : Une école d'ingénieur d'Arras.
Et c'est une pratique relativement courant dans l'enseignement, malheureusement.
22 De Hugo Hamon - 13/01/2011, 10:06
Hello Fred,
Ton billet est très intéressant et je te rejoins sur la majorité des points évoqués. Comme tu le précises, beaucoup de développeurs aujourd'hui apprennent PHP avec un framework, ce qui a pour conséquence qu'ils ne maîtrisent pas les concepts de base de PHP, de SQL, de HTTP... Le but du framework c'est aussi d'abstraire une partie de la complexité technique. C'est par exemple ce que font très bien les librairies d'ORMs. A l'utilisation c'est très séduisants mais on en vient à oublier que derrière on a un SGBD doté de fonctionnalités particulièrement efficaces mais que l'on ignore presque à chaque fois (triggers, procédures stockées, transactions...).
Les frameworks sont comme les sites de vulgarisation informatique qui cherchent à vulgariser à outrance les concepts. A partir de là, le développeur sait comment ça marche et il parvient à s'en sortir lorsqu'on le met fasse à une problématique simple. Essayez de le mettre devant la même problématique en lui interdisant d'utiliser un framework ou des librairies tierces. Je pense que le résultat va être surprenant. Je parie que certains développeurs ne sauront pas qu'ils doivent instancier un PDO pour se connecter à leur base de données, ou bien qu'ils doivent aller chercher les paramètres de l'utilisateur dans les tableaux $_GET, $_POST, $_COOKIE... Quand ils y parviennent, il faut aussi s'assurer qu'ils sécurisent bien les données utilisateurs ainsi que les données affichées en sortie.
Il est donc nécessaire de trouver un juste milieu et pour moi ce juste milieu c'est de dire aux développeurs de ne pas travailler avec un framework PHP modernes tant qu'ils ne maîtrisent pas suffisamment le langage PHP et la programmation orientée objet. En formation, je constate régulièrement que des entreprises envoient leurs salariés pour se former sur symfony alors que ces derniers ont des connaissances très minces en programmation orientée objet et php. Ils ne savent pas ce qu'est une interface ou un autoloader par exemple.
Le framework est donc pour moi intéressant à partir du moment où l'on maîtrise le langage et les concepts sous-jacents. Mais ce n'est pas tout ! A ce niveau là, il ne faut pas se contenter d'utiliser "bêtement" le framework, il faut être capable de se l'approprier et de comprendre comment il fonctionne. Cela passe par de la formation et de l'analyse de l'outil. Pour y parvenir, le développeur se doit d'être curieux et de mettre en peu les mains dans le cambouis. Il doit se forcer à ouvrir le code source du framework pour comprendre les interactions entre les différents objets créés. A ce propos, regarder le code source d'un framework écrits par d'autres que soi-même est un exercice très formateur.
J'attends avec impatience l'arrivée de Symfony2 car la philosophie du framework ira dans cette direction : utilisation avancée de la POO, mise en oeuvre des bonnes pratiques mais surtout simplification des concepts.
Symfony2 simplifie énormément les concepts par rapport à symfony 1.x. Il y aura beaucoup moins d'abstraction et le développeur sera obligé d'écrire un peu plus de code, d'ouvrir le code source du framework pour comprendre comment ça marche et comment il peu le contourner ou bien remplacer des briques logicielles par d'autres.
Symfony2 sera également très flexible, ce qui permettra de le hacker très facilement. Dans ton billet, tu parles de ton désir de pouvoir utiliser le framework uniquement selon tes besoins et pouvoir être capable de le détourner pour des besoins exotiques. Aujourd'hui la grande majorité des frameworks ne le permettent pas... Quand bien même ils le permettent, cela nous oblige à modifier le code à de nombreux endroits en raison des forts couplages entre les classes. Dans Symfony2, le couplage est tellement faible que l'on sera capable de détourner le framework pour l'enrichir ou bien remplacer certaines de ses briques logicielles par d'autres plus adaptées.
Par exemple, dans symfony 1.x, vous êtes quasiment obligés d'utiliser l'ORM (Propel ou Doctrine). Si vous prenez le parti de ne pas l'utiliser, vous éliminez d'office la grande majorité des fonctionnalités de l'outil à cause de ces forts couplages avec l'ORM. Dans Symfony2, l'ORM n'est qu'un outil supplémentaire indépendant et vous aurez le choix de l'utiliser ou non sans perdre la richesse des fonctionnalités du framework.
C'est exactement ce que j'attends de la nouvelle génération des frameworks. J'ai toujours aimé travailler avec symfony mais avec le temps et l'expérience, j'en suis arrivé à lui trouver certaines limitations qui peuvent parfois considérablement pénaliser la productivité.
La nouvelle génération des frameworks doit offrir aux développeurs une plus grande souplesse. Ces nouveaux frameworks doivent aussi simplifier les concepts en limitant les couches d'abstraction afin de contraindre les développeurs à comprendre ce qu'il se passe sous le capot et ne pas se laisser dépasser par l'API de haut niveau du frameowrk.
Ma conclusion sera la suivante : faisons les choses simplement mais faisons les bien. Restons pragmatiques. Les frameworks ne sont que des outils qui ont de nombreux avantages comme des inconvénients. Et dans un monde où l'on "industrialise" de plus en plus les développements, les frameworks sont nécessaires pour garantir la productivité, la stabilité, le travail en équipe et la qualité du logiciel. A condition bien sûr de comprendre ce qu'ils font et de les utiliser à bon escient...
23 De Mère Teresa - 13/01/2011, 10:18
@nautilebleu:
Non non non, ses talents d'architecte, et non pas de développeur.
Après, il faut aussi des grouillots pour pisser le code qui fait des choses (afficher des données pour l'utilisateur par exemple) et pas seulement des intellectuels qui conçoivent.
Comme le souligne Cyrano, au bout de quelques dévs, on a tous envie de penser DRY (Don't Repeat Yourself), et on a tous envie de réutiliser du code. En ce sens, je suis pour les frameworks mais surtout : je suis POUR la doc !
24 De Guile - 13/01/2011, 10:55
Remarque pour commencer : il serait intéressant de préciser que ce débat parle surtout de mauvaises expériences sur les frameworks PHP, et pas sur d'autres langages.
Mon avis :
J'ai bossé dans une usine où les ouvriers se plaignaient de la procédure de candidature à une charte de qualité truc machin : ils disaient que ça leur fait perdre du temps, de la paperasse, etc.
De l'autre côté, l'intégration d'un nouvel ouvrier habitué à cette charte de qualité le rendrait opérationnel rapidement.
Les frameworks portent bien leur nom : ils donnent un cadre de travail. C'est tout ce qu'il faut en attendre.
Si des mecs argumentent sur les performances au dépit de ce cadre, qu'ils fassent de l'assembleur. Là ils auront des perfs de ouf'
J'ai eu également un collègue qui gerbait à l'idée de faire de l'objet en le qualifiant d'inutile "Je vois pas l'intérêt de mettre des variables en privé", et qui préférait ré-inventer la roue pour plus de performances (il avait justement ré-inventé le malloc avec une pile mémoire maison, le tout géré avec un algo de tri genre garbage collector codé en assembleur...)
Un autre collègue ayant une tout autre expérience m'avait dit : "L'objet ça ne bouffe pas plus de mémoire ou de temps processeur quand on sait coder de l'objet".
Ces deux connaissances ont néanmoins un point commun : ils ont bossé sur du dev pour machine à maigres performances (machines portables). La principale différence entre eux : le premier a fait du boulot pour une équipe de 2 développeurs, l'autre a géré une équipe d'une cinquantaine de développeurs.
On pourra également dire que le fusil de chasse c'est mal, y a tellement de gens qui font n'importe quoi avec (ça fait du bruit, ça met du plomb dans la bête, ça peut tuer des gens quand on ne sait pas s'en servir), alors on devrait utiliser son bon vieux couteau pour aller chasser, ou bien partir sans arme et les refabriquer à chaque fois sur place ?
Les frameworks suivent cette même polémique de l'informatique, quasiment une arlésienne. Je trouve les frameworks hyper lourds (côté ORM surtout) pour ce qu'on veut parfois en faire. Mais ils apportent un confort dans d'autres domaines que les purs codeurs n'imaginent pas (car ils sont purs, et ne travaillent pas avec ces impies personnages sachant faire echo "$mavariable" en se disant développeur php).
Faut-il voir dans ce débat l'expression d'une résistance au changement d'une partie de ceux qui s'expriment? Une résistance à l'apprentissage (faut parfois mettre les mains dans le cambouis)? A de la jalousie ("zut, je ne connais pas ZF je ne peux pas postuler à ce poste, pourtant jsuis un as en php")?
25 De Amaury Bouchard - 13/01/2011, 12:46
@Steuf : Oui, je suis évidemment d'accord avec toi. Je voulais juste dire que ce n'est pas parce qu'un framework consomme beaucoup de mémoire que ça doit remettre en question le principe même des frameworks.
26 De Martin - Webaaz - 13/01/2011, 14:24
Article sympa, j'ai eu un peu peur que ce ne soit qu'a charge, mais la conclusion est parfaite !
27 De Steuf - 13/01/2011, 16:08
@Amaury Bouchard Oui bien sur, c'est juste que pour moi les Framework veulent trop en faire, et à force de vouloir gérer tous les cas particuliers dont une projet sur mille à besoin la plupart sont devenus de vrai usine à gaz... Je n'ai personnellement pas cette définition du "Framework". Pour moi un Framework doit me simplifier certaines parties redondantes et rébarbatives, avoir une prise en main simple, aller à l'essentiel et ne pas massacrer les performances de l'application. Il y a un juste milieu selon moi
28 De joey - 17/01/2011, 16:47
Les framework c'est un peu comme les capotes, ça permet de faire des cochonneries avec les personnes qu'on ne connait pas sans avoir à se poser de questions.
C'est quand même très limitant à de nombreux niveaux.
29 De babas3d - 25/01/2011, 12:36
J'aime bien les Frameworks mais je suis comme toi, je préfère les faire et utiliser mes propres FKs plutôt que les utiliser ... en PHP en tout cas.
Je me suis essayé à plusieurs d'entre eux dans plusieurs langages : Java, C# et maintenant PHP.
Mais comme je suis un relou et que j'ai besoin de comprendre comment fonctionne les composants que j'utilise avant de les utiliser ... ben au final, je vais presque aussi vite à faire mon propre FK avec sa documentation qu'à apprendre celui des autres.
D'autant plus que les FKs PHP me gênent comparés à ceux de Java ou C# car ils cherchent tous à faire TROP de choses pour répondre à 100% des besoins dont 20% de ces besoins ne couvrent au final que 5% des cas réels. Et assez souvent, ces 20% obligent à complexifier le FK de telle façon qu'apprendre son fonctionnement est gageure.
Enfin, le peu que j'ai pu lire sur les Symfony, ZF et consorts c'est qu'une fois qu'on en a adopté un, on ne peut que très difficilement passer sur un autre, si l'envie nous prend ou pire pour les faire cohabiter. Même si le Symfony 2 à venir semble être un FK plutôt cool ... j'espère que ce n'est pas que du teasing
Si quelqu'un veut me contredire, no soucy, ca ne fait que 6 mois que je me suis replongé dans le PHP pour des besoins pros et surtout la migration d'un projet tentaculaire commencé avec PHP3 sans aucun logique véritable et très peu de POO ... un vrai challenge quoi et heureusement que le PHP est enfin POO je n'aurais jamais accepté le poste sinon loool.
PS : J'ai aussi l'impression que les FKs-fourre-tout sont apparus pour faire croire aux mauvais développeurs qu'ils pouvaient du bon code malgré leur nullité (C'est une méchanceté purement gratuite mais elle est basée sur mon expérience des 'autres' et je voulais la dire hehe).
30 De ronan - 26/01/2011, 14:07
Je pense que l'on est tous d'accord sur le fait que d'apprendre PHP par l'utilisation d'un Framework est sans doutes la pire des choses.
Il est dans ce cas très difficile pour la personne en question de bien distinguer la logique et les fonctionnalités propre au language et celle du framework, masquant ainsi le fait que le Framework en question proprose un outils et des logiques parmis une infinité d'autres....
31 De bob - 13/02/2011, 05:57
J'ai environ 5 ans d'éxpériences professionnelles en PHP et aujourd'hui je n'arrive tout simplement pas à décrocher un seul job car je n'ai aucune expérience CMS !!
Autant vous dire que j'en ai plus que marre de ces CMS/framework.
Si je connais cake PHP dsl ici dans notre entreprise on developpe avec symfony et vis versa. Pareil pour ces CMS de merde ! Vous connaissez Joomla ? Aie, nous utilisons typo3, désolé pkoi on en est arrivé là ?
Autant vous dire qu'aujourd'hui je suis au bord du suicide j'ai jamais compris l’intérêt d utiliser des CMS sauf si on est un gros noob qui n'a aucune notion d estetique qui veut un site formaté 2 colonnes et 1 logo en haut à gauche surtout que dès qu'on veut faire du spécifique c'est la grosse galère, aucune flexibilité..
Merci à tous ces développeur de CMS et framework de me gâcher ma vie professionnelle et à tous ces développeur qui ont eu l'idée d imposer ca en entreprise pour soit disant rendre l appli facilement à jour mon cul au final c'est tout autant usine à gaz à force de magouiller pour la rendre flexible.
Donc oui les frameworks, c'est de la merde (mais les CMS encore plus). Fallait qu'a apprendre à bien coder.
32 De Updel - 13/11/2011, 19:01
+1
Je pense que les frameworks tuent PHP, au début la blague était de contrer le FW "Ruby On Rail" qui réinventait le langage Ruby, puis c'est Zend qui mis son nez dedans.
Perso je ne voient pas l'intérêt de respecter des règles MVC et de réécrire mon code à la mode puis dans 2 ans le réécrire à nouveaux ? la tendance et le marketing Ruby on Rail à fait mal au développeurs PHP qui n'ont pas cru à la blague, maintenant toutes les Web agency exigent une maitrise d'un ou plusieurs Frameworks et pire encore à des CMS de mauvaises réputations.
Je continue à croire et que dans pas longtemps les frameworks céderont, alors que Python gagnera plus de place.
33 De steph - 05/12/2012, 23:15
j'approuve totalement !