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.
Les frameworks n'ont pas été inventés juste pour le plaisir de ruiner notre créativité. Ils règlent un besoin et nous permetent d'accélérer notre développement en investissant notre temps sur les problèmes qui nous importent vraiment. Le reste, c'est de la routine.
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.
Vous l'avez probablement vu sur FailQc plus tôt cette semaine. C'est maintenant le temps de vous rappeler que c'est ce matin que vous devez vous rendre chez Bureau en gros pour profiter du spécial "lève-tôt du samedi" pour vous procurer une clé USB Kingston avec un écran de 16 pouces (au lieu de capacité de 16 Go), au prix spécial de 9,99$.
Pourquoi parler de poutine aujourd'hui ? Parce que ce plaisir coupable par excellence des québécois vient d'être immortalisé par un groupe de punk/gypsy de Vancouver que je viens de découvrir nommé The Dreadnoughts. Sur son plus récent album, Polka's Not Dead, sorti il y a à peine un mois, la chanson "Poutine" met ce mets à l'honneur.