Je suis un développeur web ayant plus de 10 ans d'expérience en différents langages de programmation. Depuis son lancement, je suis un utilisateur modéré du framework PHP de Zend. Il m'offre la flexibilité de choisir un par un quels composants peuvent améliorer ma productivité sans toutefois m'imposer de contraintes et me mettre en boîte comme le feraient d'autres framework plus stricts.
Suite à la lecture du billet Pourquoi le framework est synonyme du mal sur le blogue Coding by Head, j'étais plus ou moins d'accord avec l'argumentation de l'auteur parce qu'il ne présente qu'un seul côté de la médaille. Plutôt que d'envoyer un commentaire qui aurait été trop long, je présente ma réplique ici.
Je vais donc me faire l'avocat du diable et représenter le clan qui est en faveur de l'utilisation d'un framework. Vous pourrez ensuite vous faire votre propre opinion car tout est une question de perception.
Un framework suit le principe de pareto (la règle du 80/20) : faire 80% du travail avec 20% des efforts. Si le but premier d'une usine est de sortir un produit fini répondant aux besoins de la clientèle, une firme de conception web a le même mandat. À l'intérieur de la fabrique, le moyen pour y arriver n'est pas un souçi de la clientèle qui utilisera le produit final. Ce qui se passe dans l'usine reste à l'usine. Et ce n'est pas une surprise, le client, l'acheteur, veut payer le moins possible pour en obtenir le plus pour son argent. Vous aussi, en tant que consommateur, devez comparer les prix et magasiner les soldes parce que vous pensez à la santé de votre porte-feuille.
C'est la triste vérité pour l'artisan : on s'industrialise pour être concurrentiel face à la compétition. On utilise différents moyens pour faciliter la création du produit et réduire les coûts pour l'offrir à un plus grand nombre possible. Ce qui fait qu'un artiste offrira un original étiquetté 1000$ à un cercle restreint de connaisseurs alors que la reproduction imprimée trouvera preneur chez des millions de consommateurs heureux de l'obtenir pour une fraction du prix. Produire plus vite en gardant le plus haut niveau de qualité possible au moindre coût. Nos voitures japonaises sont fabriquées au Mexique et le iPhone est mis en production en Chine. Tant pis pour le principe.
Dans notre milieu, le programmeur doit se doter des meilleurs outils pour avoir le rendement le plus efficace. Et il y a des choix à faire. Parfois déchirants et qui vont contre l'idéologie utopique d'un monde idéal et parfait. C'est ce qui rend notre gagne-pain possible. Si les entrepreneurs demandent à leurs employés d'utiliser une méthodologie, un outil ou un framework, c'est qu'il y a des avantages d'ordre logistique, organisationnel et économiques en jeu. Les décisions sont parfois motivées par des erreurs commises dans le passé que vous n'auriez jamais soupçonné. Autrement, libre à vous de tenter votre chance en vous lançant en affaires et de l'apprendre à vos dépens.
Oui, un framework peut être perçu comme contraignant pour la créativité et le mérite. Mais on parle aussi de ne pas réinventer la roue en programmation (voir aussi mon billet sur la performance de Zend Framework). Dans le monde idéal, si on avait du temps illimité pour réaliser un projet, je préférerais aussi tout programmer les composants de A à Z. Pour la même raison que j'aimerais programmer mon propre système d'exploitation, juste pour le plaisir de le faire (quoi que la barre serait haute avec Linux). On est soumis aux lois économiques et bien qu'on puisse choisir d'appliquer les principes qu'on juge les meilleurs dans nos projets personnels, quand on le fait dans le milieu professionnel, il faut prendre des décisions selon ce qui est le plus rentable.
Pour avoir travaillé avec des dizaines de programmeurs, j'ai constaté que plusieurs ont de la difficulté à structurer leurs programmes et que ça peut facilement virer en code spaghetti. Pour eux, le framework devient un avantage car il vient encadrer leur mode de pensée pour donner une ligne directrice commune aux développeurs d'une même équipe. Travail d'équipe + egoless programming = succès.
Il n'y a pas de mal à ne pas tout faire soi-même. Je ne connais personne qui programme "from scratch" en ignorant l'environnement sur lequel il développe (Windows API, applications iPhone, COM objects, libraires commerciales, etc). On construit constamment autout du code que d'autres ont produit. Pourquoi est-ce que ça ne serait pas pareil pour l'utilisation d'un framework ? Après tout, il ne sert que de fondation à la maison qu'on tente de construire.
Dans le cas d'un framework comme celui de Zend, il a l'avantage d'être développé et révisé par une communauté très active, d'être utilisé par des milliers de programmeurs dans le monde (voire plus), ce qui lui confère un avantage considérable sur sa qualité. Pour une même fonction, plus elle sera utilisée et appelée, plus on aura la conviction qu'elle sera fiable ou qu'on détectera un bogue rapidement. Chose que vous aurez beaucoup plus de difficulté à faire avec vos librairies maison.
Un bogue est trouvé dans un framework populaire ? La communauté prendra la responsabilité d'offrir une patch dans les plus brefs délais parce qu'ils sont réactifs. Oui, il existe un risque pour des frameworks moins populaires qui peuvent parfois être à l'abandon et laisser ses utilisateurs sans ressource. C'est à vous de choisir le bon et de ne pas mettre tous vos oeufs dans le même panier (tous vos projets avec le même framework).
Au fil du texte, l'auteur présente aussi plusieurs questions qu'il laisse sans réponse. Tentons d'y trouver écho.
Essayez donc de voir plus loin que le bout de votre nez, pensez comme les gens qui ont fait cet outil incontournable dans votre quotidien, recréez la roue pour innover.
Réinventer la roue n'est pas toujours synonyme d'innovation parce qu'il faut considérer que le temps de faire de la recherche et développement pour trouver une meilleure solution en plus du temps pour l'implémenter creusera le retard sur la solution existance qui poursuivrera son évolution. À moins d'une bonne raison de le faire, tout le temps passé à réinventer la roue est du temps que vous ne facturez pas vos clients et que vous ne remplissez pas les coffres.
Car avant tout, un code est une pensée. C’est un texte possédant tout un sens, une idéologie et une expression.
Faux. Comme j'ai déjà dit, c'est de la technique, pas de la poésie ;-) Le code est la représentation d'un algorithme, la traduction d'un processus d'affaires en langage machine. Un artisan, un artiste, comme un peintre, prend son temps pour réaliser son oeuvre. Il n'est pas autant soumis aux contraintes de productivité que peut l'être un programmeur qui travaille dans un milieu commercial. L'artiste vit aussi sous le seuil de la pauvreté.
Où est le mérite lorsque c’est quelqu’un d’autre qui a pensé la solution pour lui?
Le mérite vient de l'innovation sur la façon d'utiliser les outils mis à notre disposition. Le fait de combiner deux idées ordinaires peut donner naissance à une idée géniale. Il faut se rappeler que l'utilisateur final ne voit pas le code et que c'est bien le dernier de ses soucis! S'il y a du mérite à aller en retirer, ce serait l'impact que peut avoir le projet s'il a été bien réalisé. Mais ça ne dépend en rien du langage de programmation utilisé, c'est l'idée qui fait le succès. Le programmeur travaille dans l'ombre du grand public et les seuls dont il peut espérer faire reconnaître son mérite, ce sont ses pairs. Adoptez une attitude digne du egoless programming.
Sincèrement, allez-vous réellement regarder dans les sources du framework en vous disant “tiens, comment le mec a pensé tel truc” ?
Parfois oui. Et c'est une bonne source d'apprentissage de voir comment ils ont implémenté ce qu'ils croyaient être la meilleure solution. D'autres préféreront apprécier le principe de la boîte noire et faire confiance au fonctionnement interne.
Où est l’intérêt d’utiliser une solution inventée par quelqu’un sans même poser un œil sur cette solution?
Jusqu'à preuve du contraire, s'il y a une seule solution proposée, c'est la meilleure par défaut. On vit dans mon monde d'hyperspécialisation où des milliers de personnes se sont penchées sur un problème et on trouvé une solution acceptable. La nature humaine fait qu'on aime pelleter des nuages. On peut critiquer la solution et proposer des améliorations mais si ça prend quelques centaines d'heures de recherche, d'essais et erreurs et de tests pour obtenir un gain peu significatif ou arriver au même résultat avec une solution différente, la discussion n'a pas lieu d'être. Je ne dis pas que ça ne vaut pas le coup d'essayer mais n'oubliez pas que d'autres ont eu des bonnes idées avant vous et que l'évolution avance à petits pas. SVP, faites confiance à l'intelligence humaine.
Le framework, c’est LA chose qu’il vous faut posséder sinon vous n’êtes pas à la mode, pas à jour, et surtout, vous ne vous faites pas embaucher.
C'est loin d'être une mode. Oui c'est relativement nouveau dans le jeune monde du web mais ça existe depuis la nuit des temps pour d'autres langages. On regroupe les bouts de code utiles en fonctions, en classes, en librairies et ensuite en framework.
Si vous pensez que seul la connaissance d'un framework est déterminant dans une entrevue, remettez vos compétences en question.
Pourquoi une telle dépendance au framework? Pourquoi est-il aussi important qu’un bonbon, une nouvelle technologie, ou bien un nouvel artiste du domaine musical?
Un individu qui se tient à jour dans son domaine d'expertise, voire qui est à l'avant-garde, qui explore ce que le futur lui réserve sont des synonymes de curiosité, d'exploration, d'évaluation des opportunités. Il saura prendre les meilleures décisions et influencer la direction de l'entreprise où il oeuvre plutôt que d'être influencé. En ayant une longueur d'avance sur les autres, il est le premier à profiter des opportunités qui s'offrent à lui. D'un autre côté, il serait bête d'opter pour une nouvelle technologie s'il n'avait pas la conviction que ça lui sera bénéfique.
Le développeur sera-t-il alors un simple mec bon à appeller des fonctions toutes faites et ne pensera plus à rien? S’il n’y a plus de développeur, il n’y aura plus de langage.
Ouf, un peu alarmiste comme propos! Comme le disait un autre programmeur mentionné dans son billet : le framework reste un outil, il ne remplacera jamais un développeur. Je suis d'accord avec lui. Pour moi, le framework ne solutionne aucun problème de logique, sauf si ce n'est de la structure qu'il permet de mettre en place plus facilement et d'offrir un jeu de librairies pour simplifier les actions qu'on fait régulièrement.
On disait il n'y a pas si longtemps que les robots nous feraient perdre nos emplois. Au contraire, ça en a créé! Des emplois de meilleure qualité et de plus haut niveau de complexité qui nécessite une spécialisation toujours plus poussée. Le métier de programmeur ne fera qu'évoluer vers des nouveaux défis.
Le temps n’est pas une excuse valable pour l’utilisation d’un framework. S’il en est une pour vous, alors cela prouve tout l’intérêt que vous portez à votre projet, c’est à dire aucun.
Mon cher ami, tu expliqueras ça à ton patron quand il t'annoncera que tu perds ton poste parce que son entreprise n'est plus assez compétitive sur les coûts et le temps de production. Il y a probablement plusieurs chinois et indiens qui ont tout à gagner à travailler 14 heures par jour pour un salaire dérisoire.
Si on compare le temps utilisé, alors comparons le temps utilisé pour créer un framework ou bien pour recréer la roue.
J'ai une très belle histoire à ce sujet. Deux de mes collègues ont créé, sur les heures normal de bureau, un projet qui aurait nécessité quelques composants du ZF. Parce qu'ils avaient une perception bien négative de l'utilisation du framework, ils ont décidé de développer leurs propres composants spécifiques à ce projet. 600 heures personnes ont été nécessaires pour le réaliser en imitant les fonctionnalités déjà offertes par ZF. Le résultat : mal structuré, limitatif en fonctionnalités, bogué et j'en passe. Le projet initial avait été évalué à 250 heures. Aujourd'hui, les deux programmeurs ne travaillent plus pour l'entreprise.
Je dis ça juste comme ça.
Pourquoi les entreprises focalisent-elles sur ces produits mâchés par des gens aux ambitions de contrôle et de manipulation?
Parce qu'on est victime d'une grande conspiration internationale. Ben non, voyons! Les recruteurs qui cherchent à engager des programmeurs savent que :
- en ayant travaillé avec un framework, le candidat est capable d'être productif dans un cadre de travail défini;
- de façon générale, sa courbe d'apprentissage sera plus aisée et le risque amoindri
- qu'il parlera un langage commun, avec les mêmes termes et patterns avec les autres programmeurs
- il risque moins de déroger des standards de l'industrie pour imposer "ses" standards;
- que la documentation d'un framework connu est disponible : tutoriels, formations, références, livres, etc;
- il y a plus de chances que le candidat connaisse un framework largement utilisé plutôt qu'un framework ou jeu de librairies faits maison. Il sera rentable plus rapidement pour l'entreprise.
Parler contre les frameworks, c'est un peu insulter tous ceux qui en utilisent (Zend, CakePHP, Symphony, Drupal, jQuey, Prototype, YUI, .NET, etc). Si vous avez une critique envers un framework, rien ne vous empêche de vous impliquer dans son développement et de suggérer des améliorations. Ce sont souvent des projets collectifs, à l'écoute des besoins des développeurs. Ce sera gratifiant parce que vous aurez excellé là où d'autres n'avaient jamais pu offrir mieux. Si vous ne le faites pas, là ce sera de la paresse. Trouver LA ligne de code à améliorer est plus exigeant que critiquer et tout réécrire 10000 lignes de code à votre façon (sauf rares exceptions). C'est une question d'efficience. Si vous avez la prétention de pouvoir faire mieux, vous venez de tomber dans le piège. Si vous avez la conviction et que vous savez exactement pourquoi vous devez le faire, faites-le.
Oui, il faut regarder ce que le framework offre et le choisir par rapport au besoin du projet. Le problème est que le temps investi dans l'apprentissage d'un nouveau framework doit être de beaucoup inférieur au temps que vous prendriez pour coder votre propre framework. Sinon, remettez en question celui que vous avez choisi, il n'est peut-être pas approprié à l'application que vous voulez en faire. Le second problème est qu'après avoir investi du temps à le connaître et à le maîtrisez, c'est naturel de vouloir utiliser l'outil connu et de l'adopter pour le projet suivant. Ça demande moins d'efforts mais vous vous casserez peut-être la tête à figurer comment contourner les problèmes et deviendrez amer envers le framework.
Avoir un bon outil est mieux que de ne pas avoir le bon ou ne pas en avoir du tout. Je terminerai avec un passage du livre The Pragmatic Programmer, From Journeyman to Master :
Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be. Start with a basic set of generally applicable tools. As you gain experience, and as you come across special requirements, you'll add to this basic set. Like the craftsman, expect to add to your toolbox regularly. Always be on the lookout for better ways of doing things. If you come across a situation where you feel your current tools can't cut it, make a note to look for something different or more powerful that would have helped. Let need drive your acquisitions.
Ma foi, je suis entièrement d'accord avec tout ce que tu dis là.
Auparavant, je n'utilisais pas de framework, je concevais un site de zéro à chaque fois ce qui me demandait énormément de travail pour toujours refaire la même chose au final. Qui plus est, la programmation de la base que je recréais à chaque fois était vraiment ennuyeuse, ça ne donnait vraiment pas envie de travailler sur le projet.
A présent, je travaille avec CodeIgniter.
Je peux lui faire des reproches, parfois il ne permet pas de réaliser ce que je voudrais faire de la manière dont j'y ai pensé. Bien.
Mais depuis que je l'utilise, je suis bien plus efficace qu'avant. Tout ce travail de base à coder à chaque fois n'est plus qu'un lointain souvenir.
Aujourd'hui, je peux directement me concentrer sur le projet que j'ai à faire qui est unique. Je ne travaille donc plus que sur du code unique et spécifique à chaque projet qui va stimuler ma créativité, me faire mouliner et au final me faire progresser.
Il est évident que les frameworks posent des limites mais ils permettent aussi d'en affranchir pas mal.
Actuellement, j'utilise CodeIgniter et je vais me mettre à Ruby on Rails lorsque la version 3 sera disponible.
Il est certain que d'apprendre à utiliser un framework demande du temps mais ce temps n'est rien comparé à celui passé et perdu à refaire la même chose pour chaque projet.
Je pense que pour utiliser correctement un framework dans un projet, il faut être capable de faire ce même projet sans le framework. Le framework ne remplace pas le langage, c'est un complément au langage permettant de booster l'efficacité sur un projet.
De ce fait, lorsque quelque chose me chagrine dans le framework, il m'arrive d'apporter quelques modifications aux bibliothèques en question, il m'arrive d'ajouter un fonction à une classe. Ceci permet de lever certaines limitations tout en gardant le framework. Pour ce faire, il faut connaître le langage.
Pour conclure, les frameworks ne sont pas synonymes de mal mais plutôt de complément et d'atout.
J'aimerais revenir sur quelques points.
Le "tout artistique" et le "tout technique" sont tous deux erronés.
La programmation est un subtil mélange de rigueur (technique) et d'imagination. C'est un peu comme un jeu de construction : vous devez connaître les pièces, mais à un moment donné vous devez réfléchir et faire preuve d'inventivité pour les articuler.
Rappelons que de nombreux travaux du MIT ont été considérés comme de la littérature, ce qui fait qu'aujourd'hui les logiciels dépendent juridiquement du droit d'auteur et non pas des brevets.
Il faut faire attention à ne pas toujours être trop tranché. L'informatique est aussi une question de mode. Aujourd'hui, en informatique de gestion, la mode est au JEE et au .NET et dans chacune de ces technologies on a vu passer des technologies "hype". Par exemple pour JEE : Struts => JSF sans puis avec les Facelets.
Dans le web d'ailleurs, l'AJAX est devenu une technologie à la mode alors que ce n'est qu'un regroupement de vieux trucs.
Il ne faut pas oublier que derrière ces frameworks, ces technologies, il y aussi une volonté commerciale (c'est moins marqué, évidemment, dans l'open source).
Enfin, utiliser un framework ne sert pas qu'à gagner du temps. En informatique web, la tendance aujourd'hui est effectivement à produire le plus vite possible au détriment de la qualité (car les produits ont un cycle de vie assez court), mais par contre on trouve de nombreux frameworks en informatique de gestion/industrielle qui sont destinés à structurer le développement.
Cette structuration et cette qualité passe parfois par un surplus de contraintes qui ralentissent le développement "à la main" (encore une fois, le Struts à la main est vraiment contre-productif, mais alors quelle robustesse, quelle modularité !).
Aujourd'hui, ce qui nous fait gagner du temps ce n'est pas forcément le framework mais l'environnement de développement qui l'intègre de manière graphique (interface de configuration plutôt que fichier XML, génération de code, etc.)
Comme toujours c'est une question de dosage. C'est le fameux triangle "ressource délai qualité".
De fait, il y a des entreprises qui privilégient la rapidité (angle "délai") et le moindre coût (angle "ressource") ce qui impacte forcément négativement l'angle "qualité". C'est une stratégie comme une autre, ça va dépendre des clients. Croyez bien que lorsque l'on commence à développer des logiciels pour piloter une centrale nucléaire, on va mettre un peu de côté la productivité.
D'ailleurs, il n'y a qu'à voir comment fonctionnent les entreprises certifiées CMMi, ISO COBIT ou ITIL : ils perdent un temps fou en procédure, mais le processus de production est parfaitement maîtrisé de bout en bout, sans surcoûts, sans retards et avec une excellente qualité.
Bon, sinon, je suis pas anti-framework hein xD. J'en utilise beaucoup soit pour me simplifier l'existence soit pour écrire du code plus facile à maintenir mais c'est vrai que j'ai vu passer pas mal de modes (pas que pour les frameworks d'ailleurs).
Après, je penses que ce qui génère cette réticence vis à vis des framework, c'est aussi parce que c'est parfois assez chiant de devoir changer complétement de philosophie pour en apprendre un nouveau. On a l'impression de perdre son temps en réapprenant ce que l'on sait déjà.
Je suis content que quelqu'un ait écris l'autre revers de la médaille.
J'aimerais souligner une chose chez cet auteur, très particulière car personne n'a fait de même: il a toujours (ou presque?) parlé sur le sens cognitif et la théorie. Tous les développeurs avec qui j'ai parlé sur ce sujet ont toujours parlé de la technique, codes, fonctions, etc. Tandis qu'ici, nous avons une belle réflexion sur le plan théorique d'un framework.
Je ne sais trop où rappliquer :-" ... (forum? Ici? Mon blog?)
En revanche, les gens qui nous lisent ne doivent pas penser qu'ils doivent prendre un parti (le mien ou le sien). C'est une question de pensée critique. Il faut savoir en prendre et en laisser. Il y a du bon et du mauvais partout. À chacun sa façon de faire. En espérant que la plupart ont une pensée critique (Ouais, car c'est la seule chose que l'école ne nous apprend pas).
Bel article, je l'ai lu un peu en diagonale, je finirais de le lire dans les minutes qui suivent. Merci de cette réplique!
PS: Pour ceux qui ne l'ont pas encore compris, je suis l'auteur de l'article sur Coding by Head ;-) .
En regardant dans mes stats de visites, j'ai vu une autre réaction à nos billets sur Spackydev : if ($Framework = « mal ») {$moi= »chevre »}.
Ce que je dénote chez moi, c'est que quand bien même le framework soit productif et qu'il permet d'octroyer certaines tâches au développeur, j'ai rencontré des personnes qui ne comprenaient rien à la POO mais qui utilisaient cakePHP (par exemple). Je ne dis pas que le framework est mauvais pour la santé mais l'apprentissage d'un framework devrait être après celui du langage ... Sinon on saute beaucoup trop de connaissances.
Et dans un cadre personnel, je conseille toujours de développer des applications à la main, le temps ne nous est limité et on peut ce permettre cela, car on en apprendra bien plus qu'en créant un programme pour créer un programme ...
Voilà, j'ai rédigé ma réponse à ce billet. Elle se trouve ici -> http://www.coding-by-head.tk/pourquoi-le-framework-est-synonyme-du-mal-suite-1