Discussion :

[zecreator]

Bonjour,

Pourquoi ne peut-on plus aujourd'hui, se positionner sur un poste de développement sans la maîtrise d'un framework ? Ne peut-on réellement plus développer avec ses propres méthodes, en respectant les concepts de développement (MVC par exemple). En quoi un code fonctionnel et propre a moins de valeur s'il ne rentre pas dans les schémas de tel ou tel framework ? En quoi un code maison n'est plus considéré comme professionnel, même s'il répond au cahier des charges et aux contraintes de sécurité ?

Je vois venir l'argument du "code maintenable", "de l'outil commun" ou le fameux critère "productif". A vouloir tout standardiser, ne risquons-nous pas de perdre une certaine diversité dans la manière de programmer, et donc de finir par être des robots peu créatifs qui ne codent plus rien, et qui passent leur temps à lancer des lignes de commandes pour générer automatiquement leur script ?

En quoi installer des bundles et générer du code à partir de ligne de commandes peut encore être considérer comme du développement ?

Zecreator.

[Pyramidev]

Bonjour,

Je ne suis pas développeur web et je ne connais pas Symfony. Je développe surtout en C++.

En entreprise, je préfère que les développeurs utilisent un framework externe à l'entreprise plutôt qu'un framework maison, à condition bien sûr que ledit framework externe réponde au besoin.

La principale raison est qu'utiliser un framework externe est plus productif.
En effet :

• Le framework externe est déjà codé. On gagne du temps en développement et en maintenance.
• Un framework externe est généralement plus riche en fonctionnalités.
• Un framework externe est généralement moins bogué.
• Un framework externe est généralement mieux documenté.
• Un framework externe est généralement plus performant.
• Un nouveau venu dans l'entreprise peut déjà connaître ce framework externe et bénéficier de son expérience.

Certes, concevoir et implémenter un framework maison est plus enrichissant et plus agréable.
Mais il faut nuancer ce point : il est enrichissant et agréable principalement pour les premières personnes qui l'implémenteront.
Plus tard, les nouveaux développeurs embauchés, au lieu de travailler avec un framework externe de qualité, subiront un framework maison bogué, mal codé et peu voire pas documenté.
Après tout, dans un sondage récent, on a vu que, ce qui agaçait le plus les développeurs, en moyenne, c'était d'écrire la doc.

Réinventer la roue, c'est très enrichissant, mais ça doit rester hors de l'entreprise, chez soi, dans son temps libre.

[zecreator]

Avant que cela ne parte en Troll, on est tous d'accord pour dire que l'un des principaux avantages d'un Framework, c'est sa productivité. C'est la première raison qui poussent les entreprises à vouloir l'utiliser. De même, on est quasi certains de retrouver les mêmes frameworks, quelle que soit l'entreprise que l'on rencontre. Un gain de temps énorme sur la formation. Il y a un effet "tronc commun", qui fini par nous obliger à les utiliser.

Cependant, si l'on en revient à son métier de développeur, l'utilisation de framework me questionne :

- Est-ce vraiment moi qui développe, ou bien le Framework ?
- Les bugs sont-ils les miens, ou celui du Framework ?
- Mon métier n'est-il pas réduit à être un simple opérateur derrière un système d'usinage ?
- Sera t-on encore capable, dans 10 ans, de développer sans Framework ?

Mon questionnement vient des profils récemment rencontrés lorsque j'ai eu besoin de recruter un développeur web pour mon équipe. J'ai rencontré trois développeurs, tous mettaient en avant leur maîtrise des Frameworks courants (Symphony, CakePHP, Angular...). Mais j'avais besoin de connaitre leur maîtrise réelle des langages, et des concepts MVC. Car pour moi, en toute logique, un développeur doit être capable de produire du code à partir de rien, juste avec ses compétences. Là est tout l'intérêt d'embaucher un développeur.

Pour cela, je leur ai soumis ce questionnaire. Une catastrophe au point où je me suis demandé si les mecs avaient déjà codé quoique ce soit avant. Et je me suis dis que c'était là, l'effet pervers du Framework. Mais ce qui ma vraiment sauter aux yeux, ceux sont leur réponses aux questions générales. Il n'y a aucune passion, ni réelle curiosité dans leur approche du métier de développeur. A croire qu'ils subissent leur métier plus qu'ils ne le vivent.

A vouloir s'enfermer dans des automatismes/conformismes (je ne leur jette pas la pierre, c'est la demande actuelle du job), ces développeurs étaient en train de perdre leur savoir-faire (l'ont-ils déjà eu, je ne sais pas). Pire, ils n'apprenaient plus rien.

Du coup, ne faudrait-il pas différencier développeur et frameworker ? N'est-ce pas, en fin de compte, 2 métiers avec un savoir-faire différents ? Je fini par me poser la question...

Zecreator.

[Marco46]

- Est-ce vraiment moi qui développe, ou bien le Framework ?
- Les bugs sont-ils les miens, ou celui du Framework ?
- Mon métier n'est-il pas réduit à être un simple opérateur derrière un système d'usinage ?
- Sera t-on encore capable, dans 10 ans, de développer sans Framework ?

- C'est toi qui tape sur le clavier jusqu'à preuve du contraire, pas le framework.
- Les bugs qui relèvent de ton implémentation sont les tiens, ceux qui relèvent du framework relèvent du framework. A question stupide réponse stupide.
- On va t'envoyer à l'usine sur un poste de tourneur-fraiseur ou même plus cool en contrôle qualité pendant quelques mois et puis on en rediscutera
- Est-on capable aujourd'hui de développer sans librairies ? Je suis certain que si on avait accès à des discussions de dev d'il y a 20 ans, on aurait les mêmes reproches à propos des librairies ...

Du coup, ne faudrait-il pas différencier développeur et frameworker ? N'est-ce pas, en fin de compte, 2 métiers avec un savoir-faire différents ? Je fini par me poser la question...

Et pourquoi pas différencier les vrais développeurs qui bossent avec notepad des fillettes qui utilisent un EDI ? Ou ceux qui n'utilisent aucune dépendance et qui codent absolument tout ?

...

Bon j'arrête de te provoquer, de mon point de vue un mauvais développeur est un mauvais développeur, qu'il utilise un framework ou pas ne change rien, et utiliser un framework ne transforme pas un développeur en mauvais développeur de même qu'utiliser des librairies n'a rendu un développeur mauvais.

Tu as simplement rencontré des mauvais profils c'est tout. Ceci dit si tes critères d'exigences c'est ce questionnaire t'es pas sorti du sable !

[Luckyluke34]

Oui, il y a de gros problèmes autour des frameworks aujourd'hui :

• Ils en font souvent beaucoup trop par rapport à ce dont le développeur a réellement besoin et cachent mal leurs "dessous" techniques, ce qui fait qu'on se traîne des dépendances, de la configuration et des problèmes dont on aurait jamais eu à se préoccuper normalement.

• La traduction d'une approche théorique en framework est un passage ultra délicat et pas toujours bien réussi. Il suffit d'une seule fausse bonne idée dans l'implémentation pour forcer les utilisateurs du framework à faire des trucs complètement alambiqués voire contraires à la philosophie d'origine. Sans compter les auteurs de frameworks qui décident sur un coup de tête de renommer à leur sauce tous les concepts préexistants, ou qui ne sont même pas au courant qu'ils existent.

• Beaucoup de développeurs apprennent l'aspect de surface d'un framework sans maîtriser les concepts intemporels de programmation qui sont mis en oeuvre derrière. Au rythme où se succèdent les frameworks à l'heure actuelle, ce sont des connaissances qui se périment très vite.

L'uniformisation en soi ne me gêne pas, tant qu'on parle d'une théorie comprise par tous et d'abstractions que tout le monde s'accorde à nommer pareil. En d'autres termes, les frameworks ne sont pas mauvais tant qu'on en comprend les ressorts et qu'on serait capables de les réimplémenter nous-mêmes. C'est l'uniformisation vers des produits parfois dysfonctionnels à grands coups de hype superficielle qui en effet est plus inquiétante.

Après, le développement maison n'est pas la seule alternative aux gros frameworks, il existe aussi des bibliothèques plus petites et mieux segmentées.

[el_slapper]

snip

C'est pour ça qu'il faut savoir calculer de tête, rapidement, même si on a une calculatrice(ou un smartphone) sous la main. Accélérer ce que l'on comprend, c'est bien. Accélérer ce que l'on ne comprend pas, c'est "paf muret'.

[Nico_F]

Globalement je suis d'accord avec ce qui a été dit notamment par Pyramidev pour tout ce qui concerne productivité, nouveau dev opérationnel etc. Les arguments classiques

En quoi installer des bundles et générer du code à partir de ligne de commandes peut encore être considérer comme du développement ?

Pour moi il fait distinguer le code productif et le code créatif. On ne se lancera pas dans les deux dans le même contexte.
En tant qu'employé ou indépendant, les contraintes de productivité nous laissent peu de place à la créativité : tout simplement parce que ce n'est pas ce qui est demandé : on veut délivrer un produit répondant à tel besoin le plus vite possible et le mieux possible. Et c'est ça que nous apportent les framework et les libs : des outils de qualité qui nous font gagner du temps.
Si tu veux être créatif, fais ça sur ton temps libre, crée ou participe à un projet open-source, fais toi une lib qui ne dépend d'aucune autre et utilise là ailleurs une fois qu'elle est fonctionnelle. Dès qu'elle est terminée, si tu veux l'utiliser dans un projet "productif", tu en fais un bundle et tu l'installes comme si c'était le bundle d'un autre.

Maintenant l'erreur qu'on a tous fait au moins une fois (et qu'on fait peut-être encore) lorsqu'on a utilisé un framework c'est de ne pas s'en abstraire dans l'implémentation.

Aujourd'hui beaucoup d'entreprises et beaucoup de développeurs se lancent dans un nouveau projet : première question technique "on utilise quel framework ?".
Comme si le choix du framework était une contrainte métier.
Comme si le développement ne pouvait pas commencer avant d'avoir choisi le framework.
Comme si on voulait commencer par s'enfermer dans un choix technique non réfléchi sur lequel il sera souvent impossible de revenir par la suite.

Et c'est ce qui se passe. On commence par choisir Symfony (ou un autre) on garde la structure standard proposée (parce que c'est standard donc bien pratique), on met des annotations dans tous les sens (parce que c'est bien pratique aussi et qu'on gagne du temps), on génère les CRUD parce que si déjà on peut le faire on aurait bien tort de se priver, etc. Et on a un magnifique prototype avec le label : SYMFONY-FOR-EVER dessus et des dépendances au frameworks dont on ne sortira plus jamais à moins de repasser sur quasiment tout.

En réalité, l'erreur se trouve là : on lie trop souvent son développement au framework : le développement d'un projet devrait commencer AVANT le choix d'un framework, avant le choix d'une base de données aussi pourquoi pas. Développer les packages du domaine ne nécessite à priori aucune (ou très peu de) lib externe. Parce que si une règle de mon business est "une fois que j'ai créé un user je lui envoie un mail" : ça doit se produire indépendamment du framework, de l'ORM ou de la BDD utilisés. Le framework vient se greffer AU DESSUS du domaine pour permettre une interaction avec un utilisateur quelconque : c'est la couche applicative. S'abstraire du framework est la meilleure manière d'utiliser le framework.

Donc à la question "Symfony et les autres sont-ils obligatoires ?", je serai tenté de te dire : que pour des raisons de productivité, oui ils le sont. Un bon développeur Symfony va plus vite que le même bon développeur from scratch.
Maintenant le "légèrement moins bon" développeur Symfony va souvent faire l'erreur de baser tous ses développements sur le framework alors qu'il pourrait isoler son dev et faire en sorte qu'il fonctionne ailleurs qu'avec Symfony ... mais pour des raisons de temps et parfois aussi de compétences, il est très fréquent de voir du code métier totalement dépendant du code applicatif. Et c'est là qu'on se rend compte que le "légèrement moins bon" développeur Symfony oublie qu'il peut aussi faire des POPO (Plain Old PHP Object) qui n'étendent et ne dépendent de rien au lieu de tout faire à la sauce Symfony/Doctrine.

Pour ton questionnaire deux questions importantes pour moi seraient :
Connais-tu et appliques-tu les principes S.O.L.I.D. ?
Maitrises-tu la notion de Separation of concern ?

Mais ça s'applique plus à du dev back (l'utilisation de Symfony également cela dit).




TL;DR: Les frameworks sont un must-have en terme de productivité et permettent de standardiser le développement. En revanche le choix du framework (un micro ou un très gros) doit être totalement indépendant du reste et peut se faire tard dans le cycle de développement d'un projet. On prendra le soin d'isoler le code métier (qui lui ne peut pas être généré ou remplacé par une lib toute faite) et de ne le faire dépendre d'aucune contrainte technique du type ORM/Framework/BDD etc. C'est à ce niveau là qu'un développeur doit apporter de la valeur à un projet.

[zecreator]

Ce qui m'a toujours gêné dans les frameworks, quel qu'il soit, c'est la multiplication d'opérations et le nombre de fichiers qu'il faut déployer par défaut. Je prends pour exemple ce tutorial sur Symfony 2, très bien fait.

Le nombre incroyable de manipulations et de commandes en ligne que l'on doit faire pour obtenir quelques pages web connectées à une base mySQL. Alors c'est sûr, ça fonctionne bien. Mais on a passé plus de temps à configurer des scripts et à ouvrir la console Windows, qu'à programmer. On a 30 Mo de fichiers à déployer, pour seulement 4 pages web qui pourraient tenir sur moins de 1Mo en évitant le framework. Et ce sentiment de n'avoir rien codé, c'est frustrant...

Je vois bien là l'intérêt "productif" d'utiliser un framework, on obtient le bon résultat en quelques manip. Mais à quel prix. On laisse de coté son métier de développeur en ayant une confiance aveugle dans le framework, parce que c'est celui qui est utilisé partout, et que c'est obligé. Ils sont tous fais à partir des mêmes moteurs.

Marco46 : je te sens un peu sanguin sur le sujet

Je me demande juste ce qu'il reste aujourd'hui du métier de développeur. Ceux que l'on tag de développeur "à la papa" et qui refusent le conformisme des frameworks pour privilégier leur épanouissement technique, sans vouloir être élitistes. Ceux qui souhaitent pratiquer leur métier avec le vrai plaisir de le faire. Sont-ils vraiment devenus ringards et inutiles ? Le contexte du métier tourne t-il définitivement autour de la productivité et de la rentabilité ?

Zecreator.

[Nico_F]

Le nombre incroyable de manipulations et de commandes en ligne que l'on doit faire pour obtenir quelques pages web connectées à une base mySQL. Alors c'est sûr, ça fonctionne bien. Mais on a passé plus de temps à configurer des scripts et à ouvrir la console Windows, qu'à programmer. On a 30 Mo de fichiers à déployer, pour seulement 4 pages web qui pourraient tenir sur moins de 1Mo en évitant le framework. Et ce sentiment de n'avoir rien codé, c'est frustrant [...] Je me demande juste ce qu'il reste aujourd'hui du métier de développeur

Et c'est normal : dans ce tuto il n'y a aucun code métier : et c'est ça qu'il reste du métier de développeur : le plus important c'est le code métier. Coder un système de routing peut-être intéressant sur un projet à part, mais si tu dois t'amuser à recoder un système de routing sur chaque nouveau projet tu perds un temps fou, et surtout ça va rapidement te lasser. Donc pour t'éviter cette tache répétitive et n'apportant aucune valeur, tu lances un script qui fait ça à ta place

Je vois bien là l'intérêt "productif" d'utiliser un framework, on obtient le bon résultat en quelques manip. Mais à quel prix. On laisse de coté son métier de développeur en ayant une confiance aveugle dans le framework, parce que c'est celui qui est utilisé partout, et que c'est obligé. Ils sont tous fais à partir des mêmes moteurs.

Tu fais la même confiance aveugle dans ton langage de programmation que d'autres dans leur framework.
Et si faire moins de code "boilerplate" c'est mettre son métier de développeur de coté je pense que tu n'as pas encore saisi la valeur qu'un développeur est supposé apporter.

Ceux que l'on tag de développeur "à la papa" et qui refusent le conformisme des frameworks pour privilégier leur épanouissement technique, sans vouloir être élitistes. Ceux qui souhaitent pratiquer leur métier avec le vrai plaisir de le faire. Sont-ils vraiment devenus ringards et inutiles ? Le contexte du métier tourne t-il définitivement autour de la productivité et de la rentabilité ?

Tu pars du principe qu'un dev utilisant un framework ne pratique pas son métier avec le vrai plaisir de le faire ? Parce que si c'est le cas, là encore tu te trompes. Je prends plus de plaisir à développer des fonctionnalités qui n'existent pas encore, et qui sont uniques à mon projet qu'à redévelopper un système de routing, de container de service ou de formulaire lorsque j'en ai des dizaines à disposition qui non seulement font ce que j'attends d'eux, mais qui en plus évoluent bien mieux que je n'aurais été capable de faire moi même.


Si tu es un jeune développeur je comprends cette frustration car j'ai été réticent également au départ à utiliser "du code tout fait" : j'avais le même sentiment que toi à passer à coté de quelque chose. Et je t'encourage à essayer de faire un ou deux projets from scratch pour te permettre de savoir faire ce que proposent les composants des framework, et pour mieux comprendre le gain. C'est après avoir développé soi-même une ou deux libs qu'on comprend mieux : d'une comment ça fonctionne, et de deux à quel point c'est mieux d'utiliser une lib qui prend en compte tous les cas de figure tordus auxquels on avait pas nécessairement pensé.

Si tu es un vieux de la vieille du code je n'ai qu'une chose à te dire et elle ne va pas te plaire : le métier de développeur (comme plein d'autres métiers dans tout domaine) évolue en même temps que les langages et les frameworks et c'est au dev de suivre s'il ne veut pas devenir "ringard et inutile".

[fatbob]

Si tu es un jeune développeur je comprends cette frustration car j'ai été réticent également au départ à utiliser "du code tout fait"

Tout à fait d'accord. Pour moi, la question est un peu curieuse. Un framework est juste un outil d'aide au développement comme d'autres (EDI, gestionnaire de versions, intégration continue...). Pourquoi ne pas se poser la question pour ces outils aussi ?

A l'extrême, utiliser un langage évolué, c'est déjà utiliser du "code tout fait". Avec cette optique, le seul langage acceptable, c'est assembleur, et encore (sinon, où est la limite ? C ? python ? Avec ou sans librairie tierce ?...).
L'utilisation de librairies, d'objets tiers ou de frameworks n'est ni plus ni moins qu'une évolution de la dynamique qui consiste à éviter de mal développer ce que quelqu'un d'autre a bien fait.

Et si le framework est trop gros, il est souvent possible de le faire maigrir. Symfony, puisqu'on en parle ici, permet tout à fait d'être recalibré au minimum de ce que l'on souhaite en n'intégrant que les éléments que l'on veut. Ca demande un peu de boulot mais c'est possible.

[fatbob]

On a 30 Mo de fichiers à déployer, pour seulement 4 pages web qui pourraient tenir sur moins de 1Mo

Si ton appli ne fait que 4 pages, c'est sûr que le framework ne sert pas à grand chose.
Si par contre, s'il y en a plusieurs dizaines avec des tas de listes, de tableaux, de formulaires, ce n'est plus le même tonneau.
Or, de très nombreuses applications de gestion (stocks, clients, fournisseurs, commandes) ne se contentent pas d'une base de 3 tables à gérer facilement. Celle que je développe actuellement dépasse la centaine et franchement, sans framework, ce serait pénible.

Sans parler de la sécurité qui est un vrai casse tête quand tout doit être fait à la main. Certes, au début, c'est intéressant mais après, ça finit par devenir franchement laborieux.

On laisse de coté son métier de développeur en ayant une confiance aveugle dans le framework, parce que c'est celui qui est utilisé partout, et que c'est obligé.

Pas forcément. Des frameworks, il y en a plein. Il suffit de les comparer soi-même ou de lire des comparatifs faits par d'autres. Qui plus est, sans faire une confiance "aveugle", je pense que des types qui se consacrent depuis des années à un ORM ont de grandes changes d'être meilleurs que moi dans ce domaine, des types qui se consacrent à un moteur de template depuis des années ont de grandes changes d'être meilleurs que moi dans ce domaine, des types qui se consacrent à assembler différentes briques au sein d'un framework depuis des années ont de grandes changes d'être meilleurs que moi dans ce domaine. De mon côté, me consacrant depuis des années à traduire du métier en applications, je pense que ma valeur ajoutée se trouve plutôt là.
Dans un développement, il y a normalement aussi beaucoup de code métier qui fait appel à des compétences de développement. Le "vrai" développeur n'est pas forcément celui qui a développé 250 fois un tri à bulles.
Le développement, c'est comme la médecine, ça se fragmente en plein de spécialités difficiles (voire impossible) à maîtriser toutes.
Peut-être que simplement tu n'es pas fait pour faire du développement d'applis de gestion web...
Je doute que dans l'embarqué, ils utilisent des frameworks de plusieurs dizaines de Mo.

Je me demande juste ce qu'il reste aujourd'hui du métier de développeur. Ceux que l'on tag de développeur "à la papa" et qui refusent le conformisme des frameworks pour privilégier leur épanouissement technique, sans vouloir être élitistes. Ceux qui souhaitent pratiquer leur métier avec le vrai plaisir de le faire. Sont-ils vraiment devenus ringards et inutiles ? Le contexte du métier tourne t-il définitivement autour de la productivité et de la rentabilité ?

Je ne comprends pas cette remarque. Un framework n'empêche pas de développer. Il n'enlève pas la technique, ni le "vrai plaisir" de développer. Il déplace les bornes, c'est tout. Le métier de développeur évolue, les outils aussi (le framework en fait partie, au même titre que l'IDE, le gestionnaire de version ou les outils de tests unitaires), comme celui de dentiste dont la pratique n'a plus grand chose à voir avec celle de nos grands parents. En informatique, le changement est seulement 10 ou 20 fois plus rapide.
Et le framework ne fait pas tout, autour d'une application, il peut rester pas mal de développement à réaliser dans un simple éditeur de texte avec quelques centaines de lignes et quelques objets. Par exemple un petit générateur de code pour générer des classes bâties sur un même modèle en fonction de données récupérées dans le dictionnaire d'une base, ou une macro dans tel ou tel logiciel pour importer ou exporter des méta données (je pense à MySQL Workbench qui se programme facilement en python).