par
ouckileou » 01 sept. 2008, 13:17
- Tout commence avec "Je n'ai pas besoin d'un framework."
- Ensuite vous créez 7 classes.
- Maintenant vous avez une petite librairie de classes.
- Puis vous créez une application utilisant votre librairie.
- Ça marche et c'est rapide, hourra!
- Puis quelqu'un demande une extension à une fonctionnalité de votre application.
- Et ils continuent à vous en demander plus, et plus, et plus, et plus...
- Vous avez maintenant 43 classes.
- Vous avez beaucoup appris lors des deux dernières années. Design patterns, sécurité, performance, tests...
- Ce qui était une petite librairie est devenu un énorme, laid, non-testé, non-documenté, effrayant framework.
- Puis vous changez de boulot.
- Et vous créez à nouveau 7 classes...
Je ne sais pas si c'était le but à la base mais ce commentaire me parait être en faveur des frameworks, puisque :
- Je pourrais m'en passer pour le moment mais je vais prendre un framework
- Je récupère 150 classes mais bon elles ne sont pas toutes chargées
- L'application grossit mais tout est bien organisé
- J'ai tout un tas d'outils à dispo, pas besoin de tout réinventer
- Je peux recruter des gens qui connaissent déjà, pas besoin de les former sur mon outil maison
- etc etc
C'est curieux que si peu réagissent à ce type d'article.
Moi j'ai hésité, des fois c'est fatiguant d'avance de mettre le nez dans ce genre de débat...
Ça fait déjà un moment que Rasmus a dit que les frameworks, c'est bien ... pour ceux qui les écrivent. Il enfonce aujourd'hui le clou avec cette batterie de tests.
Oui enfin bon c'est pas parceque Rasmus le dit que c'est forcément vrai. Il a l'air de voir les choses par sa lorgnette de gars très technique, mais je sais pas s'il a les autres contraintes en tête des fois (ou alors il s'en fout). Les contraintes qui dirigent les projets en vrai.
Et là pour moi ça n'enfonce aucun clou, faire un benchmark sur un "Hello world" est ridicule et n'a rien de représentatif.
Puisqu'il évident que comme tu l'as dit, on s'adapte aux besoins et on ne prendra pas un framework pour faire ça.
Je crois que ça soulève un incontestable problème de méthodologie dans la programmation mais aussi un point peut-être plus grave : on essaye de tout faire avec PHP alors qu'en fin de compte on voudrait faire des choses pour lesquelles ce langage n'est pas approprié.
Un peu comme on a vu fleurir des sites Full-Flash lorsque ce type de média est apparu, puis du Full-Ajax lorsque les navigateurs se sont mis à supporter cette technique, on voit de plus en plus des applications en Full-PHP et... on va droit au casse-gueule, moins rapidement peut-être, mais on y va sûrement. Le sens de la mesure et des choix appropriés selon les besoins semblent absent trop souvent... Et puis j'ai l'impression (peut-être à tort notez bien) que certains s'ingénient à tenter de programmer en PHP de la même manière qu'on le fait en Java. Le résultat, ce sont des sites de plus en plus lourds... et lents. La programmation qui est derrière se veut hyper-professionelle avec des modélisations énormes, des framerowks testés et re-testés, des architectures super-évoluées... mais en oubliant des règles de bases de l'internet qui sont pourtant très loin d'être neuves et toujours d'actualité :
- l'internaute lambda est lent;
- l'internaute lambda est pressé.
C'est à partir de là que j'ai pas compris. Puisqu'on a toujours fait des sites full PHP non ? Un framework propose juste des outils pour ne pas tout refaire, et pour organiser les choses.
On part direct avec une architecture précise, c'est la seule différence. Mais on ne rajoute pas de fonctionnalités juste en utilisant un framework, on ne fait pas plus de choses avec ou sans framework, on les fait juste différement. Donc le parallèle avec le "full Flash" me paraît incongru. De même, je n'ai pas compris ce qu'était "la méthode de programmation en Java", puisque c'est pareil, les frameworks PHP ne proposent qu'une implémentation de divers pattern, principalement une architecture MVC, que nous avons tous encouragé à mettre en place sur ce forum. Utiliser un framework ne me parait pas être un problème de méthodologie, au contraire !
Il suffit de voir le nombre de messages sur ce forum avec des gens venant dire "j'essaie de mettre en place un modèle 3 couches mais j'ai un problème", ou autre chose de ce genre. Tous ces gens qui réinventent des trucs mais forcément pas aussi bien que plusieurs personnes qui se mettent en semble et laissent mûrir le truc. C'est déjà bien d'essayer mais ça a forcément ses limites.
À cet égard, un récent article de Nexen soulignait ce point : (
source Nexen)
"La latence a un coût. Amazon a découvert que chaque 100ms de latence lui coûte 1% de ses ventes. Google a aussi remarqué que chaque .5 seconde de retard dans la génération des pages de résultats réduit son trafic de 20%. ".
ça c'est intéressant mais tout le monde n'est pas Google ou Amazon. Pour un tas de boite l'utilisation d'un framework n'aura pas de telles conséquences, le ralentissement sera imperceptible (si ralentissement il y a) mais les gains en terme de temps de développement, de maintenance, et de robustesse du code seront énormes, comme l'a dit Sekiltoyai dont le message résume tout.
[quote="Cyrano"]
[quote][list=1]
[*]Tout commence avec "[i]Je n'ai pas besoin d'un framework.[/i]"
[*]Ensuite vous créez 7 classes.
[*]Maintenant vous avez une petite librairie de classes.
[*]Puis vous créez une application utilisant votre librairie.
[*]Ça marche et c'est rapide, hourra!
[*]Puis quelqu'un demande une extension à une fonctionnalité de votre application.
[*]Et ils continuent à vous en demander plus, et plus, et plus, et plus...
[*]Vous avez maintenant 43 classes.
[*]Vous avez beaucoup appris lors des deux dernières années. Design patterns, sécurité, performance, tests...
[*]Ce qui était une petite librairie est devenu un énorme, laid, non-testé, non-documenté, effrayant framework.
[*]Puis vous changez de boulot.
[*]Et vous créez à nouveau 7 classes...[/list][/quote][/quote]
Je ne sais pas si c'était le but à la base mais ce commentaire me parait être en faveur des frameworks, puisque :
[list=1]
[*]Je pourrais m'en passer pour le moment mais je vais prendre un framework
[*]Je récupère 150 classes mais bon elles ne sont pas toutes chargées
[*]L'application grossit mais tout est bien organisé
[*]J'ai tout un tas d'outils à dispo, pas besoin de tout réinventer
[*]Je peux recruter des gens qui connaissent déjà, pas besoin de les former sur mon outil maison
[*]etc etc[/list]
[quote="Cyrano"]
C'est curieux que si peu réagissent à ce type d'article.
[/quote]
Moi j'ai hésité, des fois c'est fatiguant d'avance de mettre le nez dans ce genre de débat... :)
[quote="Cyrano"]
Ça fait déjà un moment que Rasmus a dit que les frameworks, c'est bien ... pour ceux qui les écrivent. Il enfonce aujourd'hui le clou avec cette batterie de tests.
[/quote]
Oui enfin bon c'est pas parceque Rasmus le dit que c'est forcément vrai. Il a l'air de voir les choses par sa lorgnette de gars très technique, mais je sais pas s'il a les autres contraintes en tête des fois (ou alors il s'en fout). Les contraintes qui dirigent les projets en vrai.
Et là pour moi ça n'enfonce aucun clou, faire un benchmark sur un "Hello world" est ridicule et n'a rien de représentatif.
Puisqu'il évident que comme tu l'as dit, on s'adapte aux besoins et on ne prendra pas un framework pour faire ça.
[quote="Cyrano"]
Je crois que ça soulève un incontestable problème de méthodologie dans la programmation mais aussi un point peut-être plus grave : on essaye de tout faire avec PHP alors qu'en fin de compte on voudrait faire des choses pour lesquelles ce langage n'est pas approprié.
Un peu comme on a vu fleurir des sites Full-Flash lorsque ce type de média est apparu, puis du Full-Ajax lorsque les navigateurs se sont mis à supporter cette technique, on voit de plus en plus des applications en Full-PHP et... on va droit au casse-gueule, moins rapidement peut-être, mais on y va sûrement. Le sens de la mesure et des choix appropriés selon les besoins semblent absent trop souvent... Et puis j'ai l'impression (peut-être à tort notez bien) que certains s'ingénient à tenter de programmer en PHP de la même manière qu'on le fait en Java. Le résultat, ce sont des sites de plus en plus lourds... et lents. La programmation qui est derrière se veut hyper-professionelle avec des modélisations énormes, des framerowks testés et re-testés, des architectures super-évoluées... mais en oubliant des règles de bases de l'internet qui sont pourtant très loin d'être neuves et toujours d'actualité :
- l'internaute lambda est lent;
- l'internaute lambda est pressé.
[/quote]
C'est à partir de là que j'ai pas compris. Puisqu'on a toujours fait des sites full PHP non ? Un framework propose juste des outils pour ne pas tout refaire, et pour organiser les choses.
On part direct avec une architecture précise, c'est la seule différence. Mais on ne rajoute pas de fonctionnalités juste en utilisant un framework, on ne fait pas plus de choses avec ou sans framework, on les fait juste différement. Donc le parallèle avec le "full Flash" me paraît incongru. De même, je n'ai pas compris ce qu'était "la méthode de programmation en Java", puisque c'est pareil, les frameworks PHP ne proposent qu'une implémentation de divers pattern, principalement une architecture MVC, que nous avons tous encouragé à mettre en place sur ce forum. Utiliser un framework ne me parait pas être un problème de méthodologie, au contraire !
Il suffit de voir le nombre de messages sur ce forum avec des gens venant dire "j'essaie de mettre en place un modèle 3 couches mais j'ai un problème", ou autre chose de ce genre. Tous ces gens qui réinventent des trucs mais forcément pas aussi bien que plusieurs personnes qui se mettent en semble et laissent mûrir le truc. C'est déjà bien d'essayer mais ça a forcément ses limites.
[quote="Cyrano"]
À cet égard, un récent article de Nexen soulignait ce point : ([url=http://www.nexen.net/actualites/web/18653-la_latence_coute_cher_aux_services_web.php]source Nexen[/url])
[quote]"La latence a un coût. Amazon a découvert que chaque 100ms de latence lui coûte 1% de ses ventes. Google a aussi remarqué que chaque .5 seconde de retard dans la génération des pages de résultats réduit son trafic de 20%. ".[/quote][/quote]
ça c'est intéressant mais tout le monde n'est pas Google ou Amazon. Pour un tas de boite l'utilisation d'un framework n'aura pas de telles conséquences, le ralentissement sera imperceptible (si ralentissement il y a) mais les gains en terme de temps de développement, de maintenance, et de robustesse du code seront énormes, comme l'a dit Sekiltoyai dont le message résume tout.
