La réutilisation du code
Cela fait peut de temps que je suis amené à coder avec d’autres gens, bien sur j’ai par exemple bossé (tout au plus quelques heures) sur Webmaster-debutant avec Hugo, mais rien de vraiment conséquent, vu mon niveau en développement à l’époque.
Aujourd’hui je pense avoir fait un bon en avant dans ce domaine, quand je compare ce que je faisais il y a encore deux ans, j’ai du mal à admettre que c’est moi qui ait codé ça. Objectivement, je dois ça à mon DUT SRC, ou plutôt au stage et à l’année d’alternance auquel il m’a donné accès.
Seulement voilà, il y a toujours quelque chose avec lequel j’ai du mal : réutiliser le code d’un autre. Je suis sans doute devenu un peu trop borné sur “les bonnes pratiques à adopter” (selon moi), mais il n’y a pas qu’au niveau de la propreté et l’organisation du code. Et oui, je parle de tous ces outils tout fait qui vous fournissent un cadre de travail (je mets le jeu de mot en évidence, quand même)
Pour le coup je ne vais pas critiquer une fois de plus symfony puisque cette reflexion m’est venue alors que je me renseignais sur propel, un framework ORM utilisé notamment dans le framework sus-évoqué plus haut.
En y réflechissant bien, je pense que tout cela vient de ma volonté naturelle à vouloir comprendre, et à connaître ce que j’utilise, et je ne m’en plains pas du tout. Si j’écris tout ça, c’est parce que j’ai une crainte quand à l’avenir de tout ça, plus j’ouvre mon agrégateur, et plus je vois des articles avec “woua ce framework est trop coule”. De plus, on m’a parlé d’une boite qui recherchait un développeur “PHP5 Symfony” pour début juillet. Alors l’avenir ce sera quoi ?
- Bonjour monsieur, vous savez coder ?
- Ah non, mais je sais utiliser du code
- Ok, vous êtes embauché
Ben moi, je trouve ça plutôt triste…
Palleas @ mai 10, 2008
Yeah un nouveau billet sur les frameworks comme tu les aimes. Je vais prendre un peu le parti des frameworks.
Déjà pour commencer, Propel est un framework ORM pour PHP5. Il est connu pour être implémenté comme ORM par défaut de Symfony comme tu l’as dit. Néanmoins, cet ORM est réputé pour sa lenteur… D’autres moteurs de mapping comme jDao (ORM de Jelix) ou Doctrine révèlent de meilleurs résultats. Laurent Jouanneau, auteur du framework Jelix, avait écrit un billet fort intéressant de benchmarking de ces frameworks ORM :
http://www.ljouanneau.com/blog/2007/11/29/723-comparatif-des-performances-des-orm-php
Quant à ta remarque sur les frameworks en général et la façon de coder, je ne suis pas tout à fait d’accord. On n’est d’accord que le framework t’oblige (presque quasiment) à respecter une syntaxe particulière et des conventions de codage. Mais la prise en main et l’adoption d’un framework requiert selon moi un certain nombre de connaissances en développement. Dans le cadre des frameworks PHP 5, il faut déjà posséder une bonne connaissance de la programmation orientée objet pour tirer partie des spécificités du framework. Qui dit bonne connaissance de la POO PHP5 implique implicitement une bonne connaissance des bases de programmation fonctionnelle avec PHP. Je suis aussi convaincu que prendre un framework en main sans comprendre comment il est structuré et comment il fonctionne est complètement idiot. Le développeur ne sera pas capable de développer correctement avec. Ces outils là sont complexes et obligent le programmeur à analyser leur fonctionnement avant de les utiliser.
Bref, je suis partagé sur la question. Je suis pro-frameworks dans la mesure où ils apportent toute une structuration, des conventions de nommage et de multiples outils qui facilitent le développement. Ce sont donc des aides non négligeables qui peuvent être intéressant de savoir utiliser pour accélérer le développement (et sa qualité). En revanche, l’adoption d’un framework, ne devrait pas se faire tant que l’on ne maîtrise pas les bases essentielles de programmation fonctionnelle et orientée objet, de sécurité et de bonnes pratiques de développement.
Je ne suis pas complètement d’accord avec Hugo (et il le sait).
J’ai pu essayer Symfony, et j’ai pu constater qu’utiliser ce framework n’est pas n’apporte pas spécialement un gain de temps.
Coder “from scratch” ça parait long, mais on maîtrise parfaitement ce que l’on fait, et les téméraires qui préfèrent coder comme ça savent se qu’ils font, donc le projet peut aboutir. Après la question de la maintenance c’est autre chose.
Coder avec un framework c’est déjà le connaître et surtout anticiper les problèmes que l’on va rencontrer pendant le projet. Et souvent, on n’anticipe pas tous les problèmes. Dans mon cas, Symfony en a causé plus qu’il n’en a résolu.
Alors l’argument du “gain de temps” ne tient pas je trouve. Toujours dans le cas de Symfony il y a l’aspect performance qui est loin d’être satisfaisant dans certain cas…
La question que Palleas soulève est très intéressante. Tout le monde s’extasie devant les frameworks (sauf les puristes
), mais se spécialiser c’est avoir moins d’ouverture d’esprit. Un “spécialiste Symfony” ne fera que du Symfony, et sera obligé de faire du code tout caca pour faire quelque chose qui aurait été moins crade sans framework.
Et il ne faut pas oublier que reposer sur un framework c’est s’exposer à tous les problèmes du framework, niveau performance, niveau choix des créateurs, etc.
(Ex dans Symfony : l’i18N discutable, les YML qui nécessite de vider le cache Symfony après chaque modification, la documentation incomplète et mal foutue, une communauté pas réactive, etc.)
Plus important encore, il y a l’aspect sécurité, si on découvre une faille dans tel version de tel framework, tous les sites qui ont été développé avec y sont exposé. Puis la pérennité de code, on développe avec tel version, la version 2 sort et la moitié de notre code devient obsolète, voire incompatible ! (ce qui nécessite des changements de code, donc une perte de temps et d’argent, alors que le framework devait solutionner ça…)
Bref, j’espère que vous aurez compris mon point de vue, je pourrai continuer longtemps comme ça, tiens ça pourrait même faire l’objet d’un billet ;).
Deviens ingénieur !
Bonjour, vous savez coder ?
Non, mais je peux apprendre à coder et j’ai trop la classe mec !
Ok, vous êtes engagé.
@Hugo : Ahah, toujours les mêmes arguments, c’est bien au moins t’es constant et on sent que tu penses ce que tu dis
@Neovov : toi je te kiffe, j’ai même pas besoin de sortir d’arguments vu que tu l’as fait avec brio
Tant mieux si ça te fait bloguer, j’attends ton billet!
@Olympi : ouais ou pas.
@Neovov : je vais te faire partager mes points de vue qui divergent des tiens concernant cette fois-ci les frameworks mais surtout Symfony, vu que tu l’as apprivoisé comme moi
>> J’ai pu essayer Symfony, et j’ai pu constater qu’utiliser ce framework n’est pas n’apporte pas spécialement un gain de temps.
Je suis moyennement d’accord là dessus… Je te plussoie dans les phases d’apprentissage du framework. Pour exemple, j’ai du développer un blog avec Symfony pour m’entrainer. Il m’a bien fallu plusieurs mois pour réussir à avoir quelque chose de potable. Si je l’avais coder “from scratch” à la manos, j’aurais mis 10 fois moins de temps. A présent, je maîtrise les rudiments du framework, donc je serai capable d’assurer le développement et économiser du temps. Plus tu t’entraines à l’utiliser et plus tu vas vite dans ton développement. Ne me fais pas croire que la génération du scaffolding, des CRUD et du backend te laisse si indifférent que ça. C’est quand même super appréciable. Par contre, Symfony est assez difficile à adopter rapidement. C’est le gros défaut que je lui trouve.
>> Coder “from scratch” ça parait long, mais on maîtrise parfaitement ce que l’on fait, et les téméraires qui préfèrent coder comme ça savent se qu’ils font, donc le projet peut aboutir. Après la question de la maintenance c’est autre chose.
Non sous Symfony tu n’es pas obligé de développer à chaque fois “from scratch”. C’est là qu’intervient le mécanisme des plugins. Une agence web, développera tous ses modules sous forme de plug-ins qu’elle viendra greffer dans chaque site client en fonction du devis. Quand on voit aussi le nombre de plug-ins pré-existants pour Symfony, c’est assez sympa. Ca permet d’accélérer encore davantage le développement et de ne pas avoir à partir depuis rien.
>> Coder avec un framework c’est déjà le connaître et surtout anticiper les problèmes que l’on va rencontrer pendant le projet. Et souvent, on n’anticipe pas tous les problèmes. Dans mon cas, Symfony en a causé plus qu’il n’en a résolu.
Le gros problème qu’il m’a causé c’est :
- Comment il fonctionne ?
- Comment on l’utilise ?
Après on s’y fait vite et dans l’ensemble les autres problèmes sont vite résolus. Je serai curieux de savoir quels problèmes tu as rencontré par contre
>> Alors l’argument du “gain de temps” ne tient pas je trouve. Toujours dans le cas de Symfony il y a l’aspect performance qui est loin d’être satisfaisant dans certain cas…
Hum mwé, pas tout à fait d’accord ! Certes Symfony est “lourd” du fait qu’il load beaucoup de classes au démarrage. Mais il a quand même un bon système de cache qui permet de pallier déjà à toutes les étapes de parsing des fichiers YAML en production. Et puis quand on voit les références comme Yahoo! qui l’utilisent, on peut se dire qu’il s’en sort pas trop mal. La version 1.1 améliore quant à elle aussi les performaces
>> La question que Palleas soulève est très intéressante. Tout le monde s’extasie devant les frameworks (sauf les puristes
), mais se spécialiser c’est avoir moins d’ouverture d’esprit. Un “spécialiste Symfony” ne fera que du Symfony, et sera obligé de faire du code tout caca pour faire quelque chose qui aurait été moins crade sans framework.
Tu es dur là quand même quand tu parles de code “caca”. D’un point de vue syntaxique et organisation du code, Symfony est bien foutu je trouve. Il se base sur de nombreuses bonnes pratiques. Entre coder sur Symfony et coder pour DotClear par exemple, je préfère carrément coder pour SF. DotClear par exemple, c’est de la merde en boîte au niveau du code.
>> Et il ne faut pas oublier que reposer sur un framework c’est s’exposer à tous les problèmes du framework, niveau performance, niveau choix des créateurs, etc.
Il faut savoir jauger les problèmes et raisonner en fonction de ce que tu attends comme résultat final. Est-ce que tu préfère un site ultra rapide mais qui est structuré à la va comme je te pousse, ou bien une application un peu plus lourde mais qui finalement est sécurisée, maintenable, évolutive… ? Perso je préfère le second point. Aujourd’hui, on dispose de machines de calcul toujours plus puissantes pour des prix toujours plus bas. Donc j’estime que l’on ne doit plus trop se prendre la tête si on gaspille un peu plus de bande passante et de ressources. Le prix des ressources ne changera pas en général. Et puis pourquoi un framework comme Symfony est plus lent qu’une application “traditionnelle” ? C’est du fait de sa complexité et des nombreux contrôles / opérations qu’il peut faire pour assurer la sécurité et la cohérence. Par exemple, utiliser Symfony avec MySQL InnoDB c’est sûr que c’est plus lent que d’utiliser MySQL MyISAM pour une application traditionnelle (ce que font beaucoup de boîtes en raison de la méconnaissance des avantages des différents moteurs de stockage de MySQL). Avec InnoDB on s’assure que toutes les requêtes se sont bien exécutées ou pas avec les transactions, que la base de données reste toujours cohérente et intègre… Symfony recommande de s’appuyer sur InnoDB pour pouvoir développer des applications professionnelles et robustes. Mais forcément ça demande un peu de temps de traitement en plus.
>> (Ex dans Symfony : l’i18N discutable, les YML qui nécessite de vider le cache Symfony après chaque modification, la documentation incomplète et mal foutue, une communauté pas réactive, etc.)
Pour la doc je ne suis pas du tout d’accord. Elle est relativement riche entre le bouquin, le tutoriel Askeet, le Wiki, les forums, le Newsgroup Google, les blogs annexes, les sites Symfony qui ouvrent leur code (Symfonians par exemple)… La documentation exhaustive de Symfony, c’est notamment ce qui fait son succès. Essaie de trouver autant de docs pour d’autres frameworks. Les frameworks français s’en tirent quand même bien à ce sujet. Copix et Jelix sont eux aussi bien documentés. Zend Framework est pas mal documenter aussi mais bon eux peuvent se permettre d’embaucher des gens pour le faire quotidiennement en plus de l’équipe de développeurs.
>> Plus important encore, il y a l’aspect sécurité, si on découvre une faille dans tel version de tel framework, tous les sites qui ont été développé avec y sont exposé
Je te renvoie la balle en te disant que c’est pareil avec les CMS (Joomla et compagnie), les applications open-source (PHPBB Daube par exemple). Surtout que ces outils là par rapport aux frameworks sont beaucoup moins secure. Notamment parceque déjà tout est placé à la racine web, contrairement à Symfony (et pour les autres grands FK c’est pareil), il faut créer un VHost pour placer tous les fichiers sensibles hors web.
J’ajoute aussi que Symfony (en l’occurence) jouit d’une communauté importante qui fait remonter les bugs et failles de sécurité quotidiennement. Sensio Labs publie très régulièrement les patchs de sécurité et de bugfixes du framework. Cette semaine : deux patchs sont sortis pour la branche 1.0 du framework. La version 1.0.14 publiée lundi ou mardi et la version 1.0.15 dévoilée tout juste hier. J’ai mis à jour mon code en une ligne de commande. C’est bien agréable
>> Puis la pérennité de code, on développe avec tel version, la version 2 sort et la moitié de notre code devient obsolète, voire incompatible ! (ce qui nécessite des changements de code, donc une perte de temps et d’argent, alors que le framework devait solutionner ça…)
Là encore Non ! Le code que tu développes pour Symfony 1.0 est compatible à près de 90% avec le framework Symfony 1.1. Il faut avoir à l’esprit que la branche 1.1 vient tout juste de sortir sa première version Release Candidate. La première version stable est prévue pour dans quelques semaines. Donc pour le moment, il n’est véritablement pas recommandé de développer des sites de production avec Symfony 1.1.
Enfin, on trouve sur le site de Symfony des guides de passage du code SF 1.0 vers SF 1.1. On ne te laisse pas tout seul dans la “merde” si je puis dire. Et vraiment si nécessaire, les entreprises peuvent payer un support auprès de Sensio pour s’occuper du portage des parties de code très précises.
>> Bref, j’espère que vous aurez compris mon point de vue, je pourrai continuer longtemps comme ça, tiens ça pourrait même faire l’objet d’un billet ;).
Je l’attends avec impatience alors ton billet ^^
@Hugo : Tu t’éloignes trop dans ton argumentation! Tu compares Dotclear et Symfony, Framework et CMS, ce qui pour moi n’est pas logique, mais passons.
Un truc aussi, mais c’est un argument très personnel, vendre à une entreprise un site composé de plugins codés par d’autres pour une somme aussi importante que si tout avait été codé “from scratch”, il y a un coté malhonnète…
J’pense que je suis un de ces puristes dont parle Neovov, j’trouve ça cool o/
@Palleas : quand on parle de sécurité, ça touche n’importe quelle application logicielle. On ne pourra pas y échapper à la question de la sécurité que ce soit une application déjà prête ou bien une application que l’on code soit même. Je comparais DotClear parce que malheureusement des entreprises développes par dessus ou bien par dessus des CMS par exemple.
Quant au côté malhonnête, trouve moi une seule entreprise web qui n’utilise pas de code open-source prêt à l’emploi ? Que ce soit un plugin Symfony, un forum, une classe pour faire ceci ou cela… ?
Moi aussi je suis un puriste mais quand il y’a des bonnes applis open-source qui peuvent faire gagner du temps de développement, on peut en profiter. C’est fait pour ça
Tu peux faire les deux aussi. Genre du MV-C.
Ton speech sur propel, c’est cool mais le billet l’évoque juste comme exemple.
LEA, CFA :p
J’plussoie Neovov et Palleas bien sur.
D’ailleurs, ce dernier me disait que des applications basés sur ROR avaient tendance à se casser la gueule en ce moment. P’tet bien les perfs
J’kiffe tes billets Romain
Salut les Duponds et Duponts,
c’est quoi le débat ? Coder avec ou sans framework ? Coder avec ou sans symfony ? Pour moi c’est avec symfony.
@Neovov : ton message donne l’impression que tu n’as jamais utilisé symfony. Combien de temps as-tu passé à l’essayer ? 10 minutes ?
> Alors l’argument du “gain de temps” ne tient pas je trouve.
Parce que tu ne maitrises pas l’outil, tout simplement.
> Toujours dans le cas de Symfony il y a l’aspect performance qui est loin d’être satisfaisant dans certain cas…
Parce que tu ne l’utilises pas correctement. Si vraiment tu as des gros soucis de performances, tu peux générer des pages statiques (extended cache)
> (Ex dans Symfony : l’i18N discutable,
J’aimerais que tu détailles. Quel est le problème ?
> les YML qui nécessite de vider le cache Symfony après chaque modification,
Quand tu changes la configuration d’une application, tu ne regénères pas le cache ?
> la documentation incomplète et mal foutue,
C’est une blague ? Ou un troll ?
> une communauté pas réactive, etc.)
Pas eu besoin de trop tester. Je suis abonné aux mailing-list française et anglophone et ça a l’air plutôt réactif.
> Plus important encore, il y a l’aspect sécurité, si on découvre une faille dans tel version de tel framework, tous les sites qui ont été développé avec y sont exposé.
Oui. Où veux-tu en venir ? Quand tu fais deux projets, tu réécris tout ? Si tu découvres une faille ce sera pareil.
> Puis la pérennité de code, on développe avec tel version,
A ma connaissance symfony est le seul framework (en php) qui assure le support d’un version majeure (la 1.X pour le momentà pendant 5 ans.
> la version 2 sort et la moitié de notre code devient obsolète, voire incompatible !
Décidément tes messages ressemblent de plus en plus à un troll.
à @Hugo :
> il est connu pour être implémenté comme ORM par défaut de Symfony comme tu l’as dit.
Non ce n’est qu’une brique, optionnelle comme pour toutes les autres et facilement remplaçable. D’ailleurs dans symfony 1.1, propel est un plugin.
> Néanmoins, cet ORM est réputé pour sa lenteur…
Terme bizarrement choisi.
> D’autres moteurs de mapping comme jDao (ORM de Jelix) ou Doctrine révèlent de meilleurs résultats. Laurent Jouanneau, auteur du framework Jelix, avait écrit un billet fort intéressant de benchmarking de ces frameworks ORM :
Laurent, le dit lui même, il manque plein de fonctionnalité à jDao. On jugera quand ce sera au même niveau. Et de toute façon, il y a plein d’autres choses à optimiser avant de se prendre la tête sur le choix de l’ORM. Dans symfony, tout cela est caché, une fois pour toute, même avant la première requête utilisateur si on génère le cache “à la main”.
@Nicolas : quel plaisir de te voir commenter ici
>> Non ce n’est qu’une brique, optionnelle comme pour toutes les autres et facilement remplaçable. D’ailleurs dans symfony 1.1, propel est un plugin.
Oui c’est bien ce que je dis. Il est intégré par défaut dans Symfony mais peut-être remplacé par un autre. Doctrine notamment.
>> Néanmoins, cet ORM est réputé pour sa lenteur…
>> Terme bizarrement choisi.
Oui j’aurais mieux fait de dire “qu’il a comme inconvénient d’être lourd et lent”.
>> Laurent, le dit lui même, il manque plein de fonctionnalité à jDao. On jugera quand ce sera au même niveau. Et de toute façon, il y a plein d’autres choses à optimiser avant de se prendre la tête sur le choix de l’ORM.
Je citais jDao comme ça parce que je me rappelais avoir lu son article. Après je n’ai testé aucun de ces ORM mis à part Propel.
>> Dans symfony, tout cela est caché, une fois pour toute, même avant la première requête utilisateur si on génère le cache “à la main”.
Euh là je serai curieux de savoir comment ça marche
Ca m’intéresse pour mon prochain projet Symfony qui utilisera intensivement MySQL.
> Quant au côté malhonnête, trouve moi une seule entreprise web qui n’utilise pas de code open-source prêt à l’emploi ? Que ce soit un plugin Symfony, un forum, une classe pour faire ceci ou cela… ?
Je n’ai pas dis que personne ne le faisait, je disais juste en terme de facturation. Le mec va te faire payer x€ parce que grosse application etc, alors qu’il aura installé du code préfabriqué et que ça lui aura pris une heure à l’integrer…
>> Je n’ai pas dis que personne ne le faisait, je disais juste en terme de facturation. Le mec va te faire payer x€ parce que grosse application etc, alors qu’il aura installé du code préfabriqué et que ça lui aura pris une heure à l’integrer…
Tu factures une installation d’un produit open-source…
Tu devrais, mais beaucoup ne le font pas, et ça j’en suis convaincu. Toutes les entreprises de création de site web seraient de bonne foi ? J’en doute!
Tu prends l’exemple des sites du gouvernement, ce sont des SPIP (faudrait que je retrouve lesquels si ce n’est pas tous), le design est moche et très peu évolué et pourtant je suis persuadé qu’ils ont facturé ça une blinde!
@Hugo: ce que je voulais dire concernant propel dans symfony est que comme tous les autres composants de symfony, tu peux le remplacer par un autre. C’est ce que j’apprécie énormément dans ce framework. Si tu n’aimes pas les fichiers yaml, tu peux utiliser du xml ou du php, c’est facile et surtout prévu. Si tu préfères utiliser smarty au lieu de php, tu peux le faire aisément.
Pour reprendre les propos d’un des intervenants d’un déjeuner symfony, quand tu en es à trouver propel lent, c’est que déjà tu as optimisé plein d’autres choses avant.
> Euh là je serai curieux de savoir comment ça marche
Ca m’intéresse pour mon prochain projet Symfony qui utilisera intensivement MySQL.
Tu fais un script (un peu comme les tests unitaires) qui fait toutes les requêtes que feraient tes visiteurs. Une fois cela fait tu déposes tout cela sur ton site. Cela a un énorme avantage, si par exemple, tu as des pages extrêment complexes, tu ne pénalises personne.
@Palleas: lorsque tu vends un site (ou une appllication) à un client, tu vends un savoir-faire, des compétences, une “expertise”. Peu importe les outils que tu utilises. Quelle importance, que tu utilises un framework opensource ou le tien fermé ?
>> Pour reprendre les propos d’un des intervenants d’un déjeuner symfony, quand tu en es à trouver propel lent, c’est que déjà tu as optimisé plein d’autres choses avant.
Oui je pense aussi. Pour le moment, Propel satisfait pleinement mes besoins. Je ne m’en plains pas.
>> Tu fais un script (un peu comme les tests unitaires) qui fait toutes les requêtes que feraient tes visiteurs. Une fois cela fait tu déposes tout cela sur ton site. Cela a un énorme avantage, si par exemple, tu as des pages extrêment complexes, tu ne pénalises personne.
Merci je note ça de côté
Petite question, tu utilises Symfony 1.0 ou Symfony 1.1 ?
> Petite question, tu utilises Symfony 1.0 ou Symfony 1.1 ?
en production (professionnellement) j’utilise bien entendu symfony 1.0 mais je commence tout doucement à lorgner du côté de symfony 1.1 notament pour le nouveau framework de gestion des formulaires
@Nicolas : ok. Il faudrait que je m’intéresse aussi à SF 1.1 qui me semble beaucoup plus prometteur d’après toutes les innovations dont j’ai eu connaissance
@Nicolas :
> Ton message donne l’impression que tu n’as jamais utilisé Symfony. Combien de temps as-tu passé à l’essayer ? 10 minutes ?
4 mois.
> Parce que tu ne maitrises pas l’outil, tout simplement.
C’est exactement où Palleas voulait en venir. On avance qu’un framework fait gagner du temps. Or, comme tu me le fais remarquer, il faut maîtriser l’outil. Sauf que la maîtrise ça prend du temps, et là c’est le serpent qui se mort la queue.
> Parce que tu ne l’utilises pas correctement. Si vraiment tu as des gros soucis de performances, tu peux générer des pages statiques (extended cache)
Très simple de sortir une technique qui va forcément m’aider à résoudre tous mes problèmes de performances. De même que de me signaler que je ne l’utilise pas correctement.
> J’aimerais que tu détailles. Quel est le problème ?
La tonne de fichiers n’est pas aisée à gérer, Object.php, Object_i18n.php, ObjectPeer.php, Object_i18nPeer.php, sans compter les fichiers de modèle généré. La gestion des traductions via des catalogues XML qui peut être bloquante quand tu veux “naviguer” d’une langue à une autre, etc. (pas envie de m’éterniser là dessus)
> Quand tu changes la configuration d’une application, tu ne regénères pas le cache ?
Non, encore moins en dev.
> C’est une blague ? Ou un troll ?
Non, et mon commentaire ressemblait moins à du troll que la suite de ta discution. Je n’ai pas voulu démonter Symfony, je l’ai utilisé en exemple
> Pas eu besoin de trop tester. Je suis abonné aux mailing-list française et anglophone et ça a l’air plutôt réactif.
Donc pour développer avec Symfony il faut se spécialiser en Symfony ? Pas le temps de m’abonner aux mailing-list, pas l’envie, pas le besoin. Quand je développe je veux trouver des solutions à mes problèmes, si je n’en trouve pas (à cause d’une doc trop maigre), je demande. Je considère qu’une communauté n’est pas réactive quand il n’y a pas de réponse sous 24h (surtout dans le cas d’un framework qui se dit “professionnel”), manque de pot, à chaque fois j’ai du attendre plusieurs jours pour ne pas avoir de réponse satisfaisante.
> Oui. Où veux-tu en venir ? Quand tu fais deux projets, tu réécris tout ? Si tu découvres une faille ce sera pareil.
J’ai du mal m’exprimer. Prenons un exemple. Un framework X, 2 sites développés avec ce framework. On trouve une faille dans X, les 2 sites y sont exposés. Les développeurs n’ont pas le temps de mettre à jour leurs frameworks car ils travaillent sur d’autres projets et que ça les emmerdent d’avoir ça à faire. Là où je veux en venir, c’est qu’à partir du moment où le framework est open-source il est plus exposé aux fouineurs qui cherchent une faille pour l’exploiter sur un site. Ce qui est déjà plus difficile dans le cas d’un projet sans framework (ou avec un framework maison). Je ne dis pas du tout qu’il ne faut pas utiliser de framework ! Je dis simplement que c’est utopique que de croire que puisqu’on utilise un framework on va forcément faire une application sécurisée. Je suis plus clair ?
> A ma connaissance Symfony est le seul framework (en php) qui assure le support d’une version majeure (la 1.X pour le momentà pendant 5 ans.)
Qu’entends-tu par support ? Le fait de payer le créateur du framework pour adapter le code au fur et à mesure des versions ? Dans ce cas je n’imagine même pas le budget TMA… Je rebondis sur un passage du commentaire de Hugo (désolé Hugo, j’ai la flemme de répondre au tiens) :
> Là encore Non ! Le code que tu développes pour Symfony 1.0 est compatible à près de 90% avec le framework Symfony 1.1
1. 90% C’est trop peu
2. Qui va me payer pendant que je dois corriger les 10% ?
3. D’où sort ce chiffre ? Peut-être que dans mon application les changements de la 1.1 vont me valoir 70% de code à réécrire
> Décidément tes messages ressemblent de plus en plus à un troll.
Arrête de tout prendre contre Symfony…
Palleas : ironie inside oeuf course
@Neonov:
je vais essayer de ne pas tout ramener à symfony!
> C’est exactement où Palleas voulait en venir. On avance qu’un framework fait gagner du temps. Or, comme tu me le fais remarquer, il faut maîtriser l’outil. Sauf que la maîtrise ça prend du temps, et là c’est le serpent qui se mort la queue.
Je ne dis pas le contraire. Quel que soit l’outil que l’on utilise, il y a un temps d’adaptation avant de se sentir à l’aise, d’être performant, et surtout plus rapide que sans l’outil. Aujourd’hui je développe un site plus rapidement avec symfony que sans. Pour élargir mon propos, j’ai aussi utiliser cakePHP (par exemple) et c’est la même chose.
J’ai mis du temps avant de franchir le pas. Cela fait déjà des années que je développe et comme tout un chacun je me retrouve avec des portions de code (librairies, fonctions, …) que je réutilise d’un projet à l’autre. Ce n’est pas particulièrement intéressant de développer ces parties là à chaque fois. C’est dans ce sens que je gagne du temps.
> Parce que tu ne l’utilises pas correctement. Si vraiment tu as des gros soucis de performances, tu peux générer des pages statiques (extended cache)
Très simple de sortir une technique qui va forcément m’aider à résoudre tous mes problèmes de performances. De même que de me signaler que je ne l’utilise pas correctement.
Ce que je voulais dire (je ne suis pas sûr que le terme que j’utilise soit d’ailleurs le bon) c’est que symfony offre la possibilité de fabriquer les pages html telles que lues par apache. Après plus de problème de performances puisqu’on ne passe plus par symfony.
[i18n]
Rien n’est aisée ou innée dans un framework. On ne peut pas forcément deviner comment cela fonctionne. La ou les personnes qui ont développé le machun n’ont pas forcément les mêmes approches.
> Quand tu changes la configuration d’une application, tu ne regénères pas le cache ?
Non, encore moins en dev.
J’ai du mal m’exprimé. Par cache j’entends tous les fichiers que tu ne génères qu’une seule fois. Par exemple, généralement je mets mon vocabulaire dans une base de données car c’est plus facile à sauvegarder, à mettre à jour, … Mais je ne veux pas que tout mes scripts fassent systématiquement un appel à la base de données juste pour le vocabulaire donc je fabrique un cache en extrayant le vocabulaire dans des fichiers php que j’inclus dans mes scripts. J’ai modifié la conf,je refabrique le cache. Tu ne fais pas comme ça ?
> Oui. Où veux-tu en venir ? Quand tu fais deux projets, tu réécris tout ? Si tu découvres une faille ce sera pareil.
J’ai du mal m’exprimer. Prenons un exemple. Un framework X, 2 sites développés avec ce framework. On trouve une faille dans X, les 2 sites y sont exposés. Les développeurs n’ont pas le temps de mettre à jour leurs frameworks car ils travaillent sur d’autres projets et que ça les emmerdent d’avoir ça à faire. Là où je veux en venir, c’est qu’à partir du moment où le framework est open-source il est plus exposé aux fouineurs qui cherchent une faille pour l’exploiter sur un site. Ce qui est déjà plus difficile dans le cas d’un projet sans framework (ou avec un framework maison). Je ne dis pas du tout qu’il ne faut pas utiliser de framework ! Je dis simplement que c’est utopique que de croire que puisqu’on utilise un framework on va forcément faire une application sécurisée. Je suis plus clair ?
Tu es plus clair, certes mais je ne partage absolument ton point de vue. Je travaille essentiellement seul professionnellement et j’ai travaillé quelques mois avec une personne qui a mis le nez dans mon code et m’a corrigé certaines parties, améliorés d’autres.
J’ai peur de comprendre ce que tu veux dire : un code non ouvert est-il à ton sens plus sécurisé qu’un code ouvert ? Est-ce cela que tu veux dire ?
>> A ma connaissance Symfony est le seul framework (en php) qui assure le support d’une version majeure (la 1.X pour le momentà pendant 5 ans.)
> Qu’entends-tu par support ?
sensio-labs s’engage à corrige toute faille de sécurité.
Pour finir, et pour finalement tenté de répondre à la question que Palleas se pose, j’ai mis moi aussi beaucoup de temps avant de me décider à réutiliser le code fait par d’autres. Au début, je n’avais pas le choix car d’une part je n’avais pas les connaissances suffisantes et je reprennais un énorme projet que je devais faire évoluer. Mais petit à petit j’ai tout réécris. Puis avec le temps et les nouvelles évolutions, j’ai commencé à utiliser du code externe (phpmailer par exemple).
Après est venu le temps où j’ai voulu “mettre au carré” mon code, mes bibliothèques, pour gagner du temps à chaque nouveau projet. J’ai pas mal avancé mais ce n’était pas suffisament générique, pas suffisament souple.
J’ai ensuite découvert, bien plus tard, symfony que je connais symfony depuis le mois de mai de l’année dernière. J’ai passé un peu plus de 20heures à faire le tutoriel askeet et j’ai passé de nombreuses semaines à comprendre comment fonctionnait le framework. Je pense aujourd’hui être à même de dire que je maîtrise l’outil. Je n’ai rencontré aucun problème majeur ou bloquant.
J’ai franchi le pas d’utiliser le code de quelqu’un d’autre! Puis-je savoir comment tu travailles Neonov ?
Je sais pas ce que ce document vaut (pas eu le temps de le lire) mais c’est pile dans le sujet de ce billet
ça se passe ici : http://www.ziserman.com/blog/2008/05/17/livre-blanc-sur-les-framework-php/
Déjà lu, mais merci