Discussion :

[gene69]

Si le débat c'est framework contre spaghetti, je vous laisse deviner quelle structuration de code à ma préférence. Pour avoir fait du spaghetti pendant trop longtemps...

Est-ce qu'un framework induit de la pensée unique ou est-ce qu'il apporte une réponse standard à une question standard? Parce que c'est deux formulations de la même question, au final. Oui un framework permet de sélectionner une méthode pour accéder aux données, oui un framework permet de fixer une organisation des différents modules de l'application, oui un framework force le développeur a respecter beaucoup de contraintes. Moi je dis, rien que ça, c'est bien.

Oui un framework apporte aussi ses défauts (faille de sécurités à la pelle etc...) Et alors? Pour paraphraser Tristan Nitot, c'est pas parce qu'on publie plus de bug et qu'on les corrige qu'on met plus l'utilisateur en danger. Au contraire !

Que dire d'autre? Le grand scandale de la pensée unique c'est pas tant le framework qui impose une structure au projet, le framework s'adresse au projet plus qu'à un algorythme en particulier. Le scandale dis-je, c'est que pour calculer le plus court chemin tout le monde utilise Dijkstra (tant qu'on a des couts positif bien sur, sinon c'est Ford-Bellman ) et pour trouver un milieu on fait tous une dichotomie. Ah oui mais contester ça revient à passer pour un ignorant du fait mathématique et de la théorie des graphe. Saperlipopette! Je pense que pour le framework c'est un peu pareil. Je crois qu'il y a un fait industriel informatique, ça s'appelle le framework et c'est bien.

C'est "je crois". C'est personnel, je ne cherche pas et ne souhaite pas convaincre l'excellent Manulion, d'ailleurs je crois c'est impossible vu qu'il est plus dans une dynamique "je lutte donc j'existe" qu'autre chose.

[Michel Rotta]

Non mais, allez les mec, vous êtes tous à côté de la plaque. Manulion à parfaitement raison, les framework sont un frein à la construction d'application sécurisées, ils accélèrent trop le développement, ils empêchent le développeur d'exprimer son talent à sa juste valeur.

D'ailleurs, les langages informatiques ne sont-ils pas assimilable à un framework ? PHP avec ces "design patterns" n'est qu'un carcan destiné à nous enfermer. Il faut jeter ces normes imposées qui nuisent à notre créativité.

Et apache, il nous force à utiliser des fichiers de configuration, à avoir un protocole définit pour communiquer, à respecter une hiérarchie dans les répertoires. Encore une barrière à notre liberté.

Moi je le dis, et je suis sur que Manulion me suivra : "IL FAUT JETER TOUTES CES BARRIÈRES A NOTRE CRÉATIVITÉ !"

Donc, dorénavant, nous allons coder nos application en assembler avec un vim de base comme éditeur !



Là, je me réveille d'un long cauchemar et réalise que, je vis dans un vrai monde... Où, heureusement pour les utilisateurs de l'informatique, il existe des normes, des langages de développement et des développeurs qui produises des sites qu'il est possible d'utiliser depuis n'importe quels outils connectés à internet.

Et je reviens sur les framework tel le phénix qui renait de ses cendres.

Faut-il utiliser un framework ? NON ! Pas plus qu'il ne faut utiliser du PHP ou tout autre langage, on peut développer en assembler.

Mais le premier qui se pointe chez moi ou me propose de participer à un tel projet, je le vire manu militari.

Je pense que prétendre proposer du code de qualité en refusant toutes normes et toutes factorisation est une énorme erreur. C'est faire belle une total méconnaissance du développement, de la coordination du travail d'équipe, de la gestion financière d'un projet, du suivi du code dans le temps.

Faut-il utiliser un framework ? OUI ! Quel intérêt à écrire dans chaque page pour chaque lien, la même routine qui va le mettre en forme ? Quel intérêt à écrire sur chaque page le code qui va valider la session et récupérer les données ? Quel intérêt à écrire sur chaque page les codes d'accès à la base de donnée et la routine de connexion ? ... AUCUN.

Il faut permettre au développeurs d'un projet de ce concentrer sur la partie qui les intéresses, la partie métier de leur site, cette partie qui est propre à leur site. Le reste doit être mutualisé au maximum, soit par un framework interne, né au fil de l'eau pour les usages internes, soit par un framework plus généraliste qui permet de mutualiser le travail dans un groupe encore plus grand.

Dire que l'utilisation d'un framework est de la paresse est la démonstration ultime de la méconnaissance d'un travail réel dans "la vraie vie" et ne mérite même pas le mépris pour réponse.

Dire que la finance n'a pas à se mêler de ce qui ne la regarde pas, est l'expression même de la méconnaissance du monde du travail. Qui paye les salaires des développeurs d'un projet ? Qui paye les serveurs ?

Pour prétendre qu'il n'y a pas d'algorithme dans un framework est une injure à toues les personnes qui ont contribuer à le faire fonctionner. Et une démonstration de l'ignorance même de ce qu'est un algorithme.

Je ne vais pas aller plus loin, je vais juste citer un de mes maîtres (qui est hélas parti il y a presque 20 ans) : "pour former un développeur (mais c'est vrai pour presque tous les métiers) avec 10 ans d'expériences, il faut 10 ans après les études". Je pense, cher Manulion qu'il te reste à commencer tes études, après, dans 20 ans, si je suis encore là, nous reprendrons cette discutions et je pourrais sourire à ton air ahuri devant les absurdités de ton raisonnement.

[danielhagnoul]

[...] Là, je me réveille d'un long cauchemar et réalise que, je vis dans un vrai monde... Où, heureusement pour les utilisateurs de l'informatique, il existe des normes, des langages de développement et des développeurs qui produises des sites qu'il est possible d'utiliser depuis n'importe quels outils connectés à internet.

Et je reviens sur les framework tel le phénix qui renait de ses cendres. [...]

Bonsoir

Le simple fait que l'on puisse s'intéresser à ce genre de débat est symptomatique. Dans quel autre métier envisagerait-on l'espace d'un instant d'abandonner l'acquis.

Du point de vue de l'université et de la recherche fondamentale et appliquée, il est logique de tout reconsidérer et de tout remettre en question.

Du point de vue de l'industrie, la seule bonne question est : "Quel langage et quels outils choisir pour accomplir en équipe tel travail pour un coût minimal ?"

Mais l'industrie dépend de l'université et de la recherche pour se voir proposé de meilleurs outils. Débattre du mérite de chaque chose n'est donc pas inutile. Mais vouloir tout faire soit même, c'est une utopie !

[HeadCoder]

Deux visions du code : l'idéaliste et le pragmatique. Tu envisages le code comme certains envisagent de philosopher toute leur vie ; en face, des gens qui envisagent le code comme un gagne-pain. Il est donc évident que les points de vue soient fort divergents : celui qui code pour (sur)vivre veut avoir un truc qui ne l'ennuie pas trop à la maintenance mais il ne veut pas trop réfléchir non plus car peu d'envie. L'idéaliste veut faire le meilleur code possible, etc., il ne réfléchit pas du tout à ce niveau, il peut envisager de se passer d'outils facilitant au final un tant soit peu la maintenance, il peut voir la philosophie, la beauté des objets fractals se cachant dans son code, il va réfléchir à quarante deux fois avant d'écrire quelque chose : est-ce bien là le meilleur à faire ? ; son pendant plus terre-à-terre réfléchira seulement deux fois : est-ce bien ce qui m'apportera le moins de soucis ?

En fait, le problème il est là: il y a trop peu de projets qui ont une vision différente de celle des projets industriels. Du coup, ont a des développeurs qui sont butés et bornés sur une seule opinion. Je pense que la conduite d'un développeur web va de plus en plus mal à cause de cette façon de penser. Oui c'est bien beau de se foutre du projet et du potentiel technique car sa survie est plus importante, mais faut pas délirer non plus, si le développeur web est doté d'un cerveau et de certains sens de réflexion, c'est pas pour rien (et encore moins pour les chiens).
Ça se dit fier d'être sous Linux et d'utiliser des logiciels libres et open-source, ça se dit fier d'être avec le mouvement GNU et la philosophie du libre, mais ça ne fait rien pour suivre cette optique. En gros, j'appelle vouloir profiter sur le dos des gens. Des gens se sont cassés le cul à réinventer une roue qui possède une optique différente des autres et vous ne les utilisez que parce que c'est gratuit. Il y a trop de gens qui n'utilisent pas un outil parce qu'il suit un mouvement technologique à la philosophie différente de celle majoritairement imposée partout (cf philosophie propriétaire) mais plutôt parce qu'il est gratuit et qu'il offre d'autres points intéressants. C'est du foutage de gueule sur ceux qui ont bâti ce mouvement.

Aussi, quand j'ai fait mon choix de framework, je n'étais pas du tout guidé par la raison, plus par les on-dit, par les sites qui l'utilisent ; qu'avais-je d'autre comme choix ? Quand j'ai vu que DailyMotion, par exemple, utilisait une version beta de symfony... je me suis dit que les versions stables devaient être très stables ! (Le discours pro-framework, aussi appelé "source"). De plus, c'est un framework de français... Tant qu'à faire, autant que ce soit du presque local. Il y avait aussi le ZF. Mais bon, la doc me plaisait bien moins.

C'est un peu comme faire le mouton... Et ça démontre bien un point de l'article: le framework est une mode et on l'utilise pour être "in" et parce que les autres l'utilisent (et on ne veut pas se faire voir en négatif par les autres...).

[Michel Rotta]

Je ne me fous pas (entièrement) de ta gueule... si non, je n'aurais même pas pris la peine d'écrire. Ce qui m'inquiète c'est que certains développeur débutant pourraient ce laisser influencer par cette méthode complètement détachée de la réalité du développement et de foutre leurs carrière à l'eau. La tienne n'est pas encore commencée, donc, moins de risque.

"... depuis le début on parle de frameworks dédiés au langage PHP et toi tu nous parles de logiciels et autres produits qui n'ont pas rapport avec." Ah bon... Et c'est moi qui ne comprend rien à la programmation... Qu'est-ce qu'un langage de développement si ce n'est un énorme framework qui permet de transformer des lignes de code en commandes assembleur ? Quant on veut aborder un sujet, il faut être capable d'en assumer toutes les extensions, alors, assumes. Le framework est écrit en PHP, utilisons PHP ==> PHP est écrit en C++, utilisons du C++ ! Et on arrive à l'assembleur.

Ce qui te dérange dans ce raisonnement, c'est qu'il n'est que la démonstration par l'absurde de l'erreur du tiens. Et, accessoirement, de la méconnaissance que tu as du fonctionnement de la chaine de développement ainsi que de la chaine informatique.

Tu as développé 3 projets en collaborations. C'est bien, ils font des travaux pratiques en groupe dans ton école.

J'ai commencé à développer au même age que toi. J'ai donc plus de 30 ans d'expérience dans le développement et j'ai, hélas, perdu le compte des projets sur lesquels je suis intervenu, seul ou en groupe, partiellement, totalement, comme développeur, chef de projet, chef de produit, directeur informatique, responsable d'achat,... et j'en passe. Effectivement, je parle d'un sujet que je connais beaucoup moins bien que toi.

Si effectivement je n'ai rien compris, relève le défis, essaye d'expliquer et de démontrer la véracité de ton point de vue. Démontre que mon raisonnement par l'absurde est faux. Démontre que ma chaine de développement n'est pas la meilleur. Trouve un modèle économique dans lequel tu pourras faire évoluer ta chaine.

Dis-toi bien que si tu arrives à me convaincre, tu auras de quoi convaincre un paquet de développeur. Mais je vais être très dur à convaincre.

Dans ce qui a déjà été dis :

"le framework est moins sécurisé".
Je ne peux que m'élever en faux sur une tel assertion. L'utilisation d'un framework permet de sécuriser une application. En effet, combien de développeurs directes (sans framework) prennent la peine de vérifier la présence de tous les arguments et pas plus lors d'un retour ? Combien prennent la peine d'inclure systématiquement un contrôle par CSRF ? Combien mettent en place un système unifié de contrôle des droits dans leurs applications ? Et le tous en ne factorisant pas son code, ce qui impliquerait la création d'un ... framework.

L'avantage ici du framework est évidente, toutes ces opérations sont prises en charge par le moteur du framework et le développeur peut ce concentrer sur son travail métier.

Il arrive que l'on trouve une faille sur un framework, mais celle-ci corrigée, les applications peuvent rapidement être mise à jour et sécurisée, sans avoir à reprendre la moindre ligne de code propre à l'application. Imaginez la même erreur sur un modèle développé sans factorisation, il va falloir reprendre l'ensemble de l'application pour localiser où l'erreur existe et la corriger, puis reprendre toutes les autres applications en production et les corriger, une à une, écran par écran.

L'avantage immédiat de la factorisation du code saute aux yeux. Et l'existence du framework qui n'est que le résultat ultime de cette factorisation prouve, ici, sa force face aux failles, à l'opposé d'un développement direct.


"le framework est une bride à la créativité du développeur"
Là, effectivement, il y a matière à discuter. Suivant le framework on peut être limité dans ses choix et dans la manière de réaliser les choses. C'est là qu'apparaît la question du choix d'un framework. Les deux frameworks qui ont leur salle sur developpez.net, Zend et symfony, arrivent à éviter ces problèmes de bridages, par une grande souplesse et, à l'extrême, la possibilité d'inclure des codes n'utilisant pas le framework.

J'avoue que, sur les projets développés au cours de ces deux dernières années, cela ne m'est jamais arrivé, ni sur les projets que j'ai développé, ni sur ceux que j'ai aidé sur le forum.

Le choix d'un framework ne doit pas être pris à la légère et mérite une longue réflexion. Y compris la possibilité de monter son propre framework. Mais je ne parlerais pas des avantages des uns ou des autres, c'est un autre sujet. Une simple recherche sur le forum permettra de savoir quel est l'objet de mon choix, ici, je ne parlerais que du choix d'utiliser un framework où non.


Je suis prêt à débattre d'autre arguments argumentés. Mais que s'il sont argumentés.

[dourouc05]

C'est un peu comme faire le mouton... Et ça démontre bien un point de l'article: le framework est une mode et on l'utilise pour être "in" et parce que les autres l'utilisent (et on ne veut pas se faire voir en négatif par les autres...).

C'est vrai, je n'ai que ça à faire : suivre les modes. Tiens, on n'utilise plus de frameworks, je vais donc faire autre chose. Pourquoi utilise-t-on autre chose ? Quels en sont les avantages ? Au final, toutes choses ayant été discutées, on peut poser un chiox : on utilise la même solution que tout le monde car elle est meilleure que l'actuel, soit on fait à sa tête parce que cette solution universelle ne l'ets pas tant.

En fait, le problème il est là: il y a trop peu de projets qui ont une vision différente de celle des projets industriels.

Où est la différence avec un projet dans l'industrie ? Ne forme-t-on pas des ingénieurs en informatique comme on en forme en chimie et en aérospatiale ?

Tu pourrais objecter qu'on n'a pas besoin d'ingéniurs dans un projet Web... Vois-tu les projets Web si misérables que n'importe qui peut les mener ?

[gwinyam]

En fait, le problème il est là: il y a trop peu de projets qui ont une vision différente de celle des projets industriels.

Je vois pas en quoi c'est un problème bien au contraire. Un projet industrialisé, ça veut dire un projet qui est reproductible facilement, à des coûts absorbables par le chiffre d'affaires obtenu par la vente du produit généré. Et donc qui permet par la suite de maintenir le cycle: un développeur fourni un produit qui lorsqu'il est vendu apporte l'argent nécessaire à payer ce développeur pour qu'il puisse continuer à faire des produits qui seront vendus et ainsi de suite.

N'oublie pas que même si la technique doit rester aux techniciens, ça reste la vente du produit qui nourrit le technicien. Je me nourris pas de code même si j'aime ça.

[HeadCoder]

Et non le dossier n'est pas clos, c'est le temps qui m'a un peu manqué...

Je ne me fous pas (entièrement) de ta gueule... si non, je n'aurais même pas pris la peine d'écrire. Ce qui m'inquiète c'est que certains développeur débutant pourraient ce laisser influencer par cette méthode complètement détachée de la réalité du développement et de foutre leurs carrière à l'eau. La tienne n'est pas encore commencée, donc, moins de risque.

Justement, il est préférable pour un débutant de commencer sans framework pour comprendre la méthode de base. Comme à l'école: on apprend à calculer avant d'utiliser la calculatrice.

"... depuis le début on parle de frameworks dédiés au langage PHP et toi tu nous parles de logiciels et autres produits qui n'ont pas rapport avec." Ah bon... Et c'est moi qui ne comprend rien à la programmation... Qu'est-ce qu'un langage de développement si ce n'est un énorme framework qui permet de transformer des lignes de code en commandes assembleur ? Quant on veut aborder un sujet, il faut être capable d'en assumer toutes les extensions, alors, assumes. Le framework est écrit en PHP, utilisons PHP ==> PHP est écrit en C++, utilisons du C++ ! Et on arrive à l'assembleur.

Je sais, mais là on parle de PHP. Que le PHP et aucun autre langage. On parle des frameworks qui sont dédiés à PHP. Les couches d'en dessous sont peu importantes ici. Du moins, je n'en vois pas leur importance.

Si effectivement je n'ai rien compris, relève le défis, essaye d'expliquer et de démontrer la véracité de ton point de vue. Démontre que mon raisonnement par l'absurde est faux. Démontre que ma chaine de développement n'est pas la meilleur. Trouve un modèle économique dans lequel tu pourras faire évoluer ta chaine.

Faut commencer par trouver où se situe la source de la situation. Quel domaine (finance, GI, SI, développement web, etc)? La solution de "on l'utiliser parce que c'est gratuit et c'est vite" est relativement stupide. Stupide dans le sens où c'est du non respect de ceux qui ont créé cet outil, et c'est un manque de respect et d'intérêt envers la personne à qui le projet s'adresse. Il vaut mieux faire les choses bien et lentement que vite et instables. En tout cas c'est pas bête: pourquoi pas essayer d'en trouver une autre...

"le framework est moins sécurisé".
Je ne peux que m'élever en faux sur une tel assertion. L'utilisation d'un framework permet de sécuriser une application. En effet, combien de développeurs directes (sans framework) prennent la peine de vérifier la présence de tous les arguments et pas plus lors d'un retour ? Combien prennent la peine d'inclure systématiquement un contrôle par CSRF ? Combien mettent en place un système unifié de contrôle des droits dans leurs applications ? Et le tous en ne factorisant pas son code, ce qui impliquerait la création d'un ... framework.

D'accord, sûrement qu'un framework passe le point de la sécurité. Mais qu'en est-il de la sécurité de l'information? Qu'est-ce qui nous garantie que l'information est bien gérée par celui-ci? Dûr dûr de savoir comment il la gère... Pourtant, la gestion de l'information (par information, on entend les données de bases de données, fichiers, contenu du site, etc) revient au développeur mais celui-ci semble vouloir déléguer la tâche au framework.

L'avantage ici du framework est évidente, toutes ces opérations sont prises en charge par le moteur du framework et le développeur peut ce concentrer sur son travail métier.

Quel travail?

Il arrive que l'on trouve une faille sur un framework, mais celle-ci corrigée, les applications peuvent rapidement être mise à jour et sécurisée, sans avoir à reprendre la moindre ligne de code propre à l'application. Imaginez la même erreur sur un modèle développé sans factorisation, il va falloir reprendre l'ensemble de l'application pour localiser où l'erreur existe et la corriger, puis reprendre toutes les autres applications en production et les corriger, une à une, écran par écran.

Pas nécessairement.

"le framework est une bride à la créativité du développeur"
Là, effectivement, il y a matière à discuter. Suivant le framework on peut être limité dans ses choix et dans la manière de réaliser les choses. C'est là qu'apparaît la question du choix d'un framework. Les deux frameworks qui ont leur salle sur developpez.net, Zend et symfony, arrivent à éviter ces problèmes de bridages, par une grande souplesse et, à l'extrême, la possibilité d'inclure des codes n'utilisant pas le framework.

Ce n'est pas suffisant. La créativité du développeur est toujours mise de côté. Il n'y a que Zend Framework qui passe au delà.

Je suis prêt à débattre d'autre arguments argumentés. Mais que s'il sont argumentés.

Est-ce assez argumenté? Et sinon, au niveau théorique, qu'as-tu à me dire? Parce que là, c'est bien beau la technique, mais le problème il est au niveau théorique, dans l'abstrait.

C'est vrai, je n'ai que ça à faire : suivre les modes. Tiens, on n'utilise plus de frameworks, je vais donc faire autre chose. Comportement idiot au possible. Pourquoi utilise-t-on autre chose ? Quels en sont les avantages ? Au final, toutes choses ayant été discutées, on peut poser un chiox : on utilise la même solution que tout le monde car elle est meilleure que l'actuel, soit on fait à sa tête parce que cette solution universelle ne l'ets pas tant.

Il y a des jours où ça ne fait pas de mal d'aller à l'encontre des décisions des gens. Rien que pour essayer.

Où est la différence avec un projet dans l'industrie ? Ne forme-t-on pas des ingénieurs en informatique comme on en forme en chimie et en aérospatiale ?

Dans un projet industriel, il n'y a que l'argent qui compte. Le reste (innovation, technique, théorie, le code, technologie, etc) n'est bon que pour la poubelle.

Tu pourrais objecter qu'on n'a pas besoin d'ingéniurs dans un projet Web... Vois-tu les projets Web si misérables que n'importe qui peut les mener ?

J'avoue qu'il n'y a pas que les ingénieurs qui sont inclus. Ai-je trop cerné le public cible? Sincèrement, il y a des jours où j'ai l'impression que beaucoup de projets sont misérables. Heureusement, le web est grand et on ne peut obtenir une vue d'ensemble.

N'oublie pas que même si la technique doit rester aux techniciens, ça reste la vente du produit qui nourrit le technicien. Je me nourris pas de code même si j'aime ça.

À mon avis, ce n'est pas pour le code en tant que tel que nous devrions payer (payer celui qui l'écrit entre autres). Ça devrait plutôt être basé sur la réflexion et la solution au problème.

PS: Je ne suis pas un membre habitué sur ce forum. Qu'est-ce que le système de points? Y a-t-il un endroit où je peux trouver la réponse?

[grunk]

Je ne suis pas un membre habitué sur ce forum. Qu'est-ce que le système de points? Y a-t-il un endroit où je peux trouver la réponse?

Voir ici :
http://www.developpez.net/forums/d98...s-base-points/

Il y a des jours où ça ne fait pas de mal d'aller à l'encontre des décisions des gens. Rien que pour essayer.

Dans un projet industriel, il n'y a que l'argent qui compte. Le reste (innovation, technique, théorie, le code, technologie, etc) n'est bon que pour la poubelle.

À mon avis, ce n'est pas pour le code en tant que tel que nous devrions payer (payer celui qui l'écrit entre autres). Ça devrait plutôt être basé sur la réflexion et la solution au problème.

J'ai l'impression que tu vie pas dans le même monde que nous. Une entreprise à un client. Ce client veux X tu lui donne Z y t'envoi balader. Le client est roi , quand il demande de mauvaise chose , on essai gentilement du lui expliquer qu'il se trompe mais au final c'est à lui que revient la décision finale.

Il m'est déjà arriver de rendre des projets que je trouvais absolument infame (tant niveau fonctionnalité que design) mais qui représentait tout à fait ce que voulait le client.

A part les fondations qui vivent de gentil groupe altruiste , n'importe quelle boite à besoin de faire du chiffre et donc d'optimiser ses process de développement ce qui revient effectivement à limiter, parfois, la créativité.

Pour l'innovation c'est la même chose , une société ne peut pas se permettre de repartir "from scratch" avec les technos à la mode. Elle ont besoin de technos éprouvées et pérennes.
Chez nous je sais qu'en général les projets internes (donc non destiné à un client) sont en général l'occasion de tester de nouvelle chose qui pourront être intégrer dans un future plus ou moins proche. Mais jamais de la vie on va prendre le risque d'intégrer de nouvelle chose dans un projet ayant des dates butoire fixe et impliquant une somme d'argent conséquente (sauf si bien sur le dit projet nécessite ses évolutions).

[dourouc05]

Justement, il est préférable pour un débutant de commencer sans framework pour comprendre la méthode de base. Comme à l'école: on apprend à calculer avant d'utiliser la calculatrice.

Je comprends différemment la remarque de Michel : un développeur débutant connaît déjà le PHP, sait déjà s'amuser avec le core. Maintenant, quand il va commencer à faire de vrais projets, avec des dead lines et autres joyeusetés, s'il n'utilise pas de méthode plus industrielle de production d'application (alias framework), il n'en sortira jamais. Ou alors il a prévu des délais immenses.

Je sais, mais là on parle de PHP. Que le PHP et aucun autre langage. On parle des frameworks qui sont dédiés à PHP. Les couches d'en dessous sont peu importantes ici. Du moins, je n'en vois pas leur importance.

mais le problème il est au niveau théorique, dans l'abstrait

Si le problème est si abstrait, pourquoi serait-il contraint de rester dans le concret d'un seul et unique langage ? Tu as des frameworks dans tous les langages ou presque (même en Pascal). Ils fonctionnent grosso modo de la même manière. C'est pour ça qu'ils se piquent des idées les uns aux autres.

Stupide dans le sens où c'est du non respect de ceux qui ont créé cet outil, et c'est un manque de respect et d'intérêt envers la personne à qui le projet s'adresse. Il vaut mieux faire les choses bien et lentement que vite et instables.

Bien et lentement n'est possible que si tu en as le temps. Si le moindre retard risque de te mettre à la rue (en caricaturisant un peu), tu ne vas pas vouloir faire quelque chose de bien mais lent.

En quoi est-ce du non-respect ? Si tu utilises le framework et râle dessus tant que possible, ça, c'est du non-respect ; si tu l'utilises, que ce soit professionnellement ou personnellement, et que tu rapportes les bogues que tu rencontres, etc., est-ce du non-respect ? Si tu remarques qu'il y a du code à factoriser qui y aurait sa place, vas-tu le leur refuser ?

D'accord, sûrement qu'un framework passe le point de la sécurité. Mais qu'en est-il de la sécurité de l'information? Qu'est-ce qui nous garantie que l'information est bien gérée par celui-ci? Dûr dûr de savoir comment il la gère... Pourtant, la gestion de l'information (par information, on entend les données de bases de données, fichiers, contenu du site, etc) revient au développeur mais celui-ci semble vouloir déléguer la tâche au framework.

Le framework fera tout son possible pour que les données restent entre la db et l'application et l'utilisateur. Qu'ets-ce que déjà une bonne gestion de l'information ? Il s'assure qu'elle n'est pas trop disséminée partout, c'est déjà un bon pour pour la gérer correctement ; il n'y a pas de code qui s'occupe d'envoyer tout le contenu de la base à Facebook pour remplir ses propres bases de données, c'est un avantage de l'open-source.

Il y a des jours où ça ne fait pas de mal d'aller à l'encontre des décisions des gens. Rien que pour essayer.

Ces jours-là, ils s'appellent dimanche. Et il n'y en a qu'un par semaine. Et tu t'amuses ce jour-là. Et tu en profites pour tenter de lancer une révolution. Et tu remarques que l'existant est déjà excellent comme c'est (mai 68).

Dans un projet industriel, il n'y a que l'argent qui compte. Le reste (innovation, technique, théorie, le code, technologie, etc) n'est bon que pour la poubelle.

Tout dépend le milieu : certaines entreprises vont jusqu'à aider les projets environnementaux, faire en sorte que leurs usines ne polluent presque plus, en sus de ce que demandent les états. Ça ne leur rapporte rien, c'est un fait ; pourquoi le faire, ce n'ets que dépense inuitle !

L'industrie ne peut pas non plus se permettre d'oublier la théorie : comment arriver à concocter un procédé industriel dans sa cuisine ? L'industrie ne peut pas se permettre d'oublier la technologie et la recherche : comment être toujours suffisamment à la pointe pour toujours être compétitif ?

À mon avis, ce n'est pas pour le code en tant que tel que nous devrions payer (payer celui qui l'écrit entre autres). Ça devrait plutôt être basé sur la réflexion et la solution au problème.

Le problème, c'est que cette réflexion ne fait pas avancer les choses ; certes, elle est nécessaire. Assieds-toi dans un coin, réfléchis des heures au design de ta nouvelle application : pour le client, cette application a-t-elle avancé ? Non. Un certain Joel Spolsky (joelonsoftware.com) dit que pour le client l'état d'avancement du développement d'une application dépend directement de l'état de la GUI. Si la GUI n'avance pas, le client pense qu'on se fout royalement de sa gueule.

[grunk]

Le problème, c'est que cette réflexion ne fait pas avancer les choses ; certes, elle est nécessaire. Assieds-toi dans un coin, réfléchis des heures au design de ta nouvelle application : pour le client, cette application a-t-elle avancé ? Non. Un certain Joel Spolsky (joelonsoftware.com) dit que pour le client l'état d'avancement du développement d'une application dépend directement de l'état de la GUI. Si la GUI n'avance pas, le client pense qu'on se fout royalement de sa gueule.

C'est d'ailleurs pas valable que pour les clients malheureusement. Je trouve très difficile de justifier d'une ou deux journée de conception à un directeur non technique :
"Non mais là tes carré avec les flèches (sous entendu diag de classe et mcd) c'est bien mais l'appli elle en est où ?"
J'étais tellement consterné que ma première réponse à été : "Baaaa euuhhhh"

[Joker-eph]

La créativité du développeur est toujours mise de côté. Il n'y a que Zend Framework qui passe au delà.

Oui un "cadre" bride la créativité, c'est inhérent. Mais à quel point est-ce un problème ?

On est déjà limité à plein de niveau, en fait dès que tu choisis une technologie à n'importe quel niveau, tu te "limites" d'une certaine manière.

Ensuite pour rester dans la créativité, oui le choix d'un framework va limiter ta créativité sur la partie structurante de l'application, et ce d'autant plus que le framework est "rigide". Mais d'un autre coté, le temps n'étant pas extensible, ça te permet de ne pas partir de zéro et tu pourras exprimer ta créativité à un autre niveau que le simple squelette de l'application ! Tu pourras aller peut être plus loin que si tu avais commencer from scratch et que tu avais du te limiter par manque de temps.

Tout est question d'objectif aussi, on a vu il y a pas longtemps sur ce forum un sujet avec un développeur qui a pris plusieurs années pour réécrire entièrement son système d'exploitation from scratch. C'est clair que niveau créativité on est au top ! Mais si l'objectif était de fournir un système à un client pour faire tourner une appli, était-ce la bonne partie de l'ensemble sur laquelle il fallait exprimer sa créativité plutôt que partir sur de l'existant ?

Les frameworks répondent de la même manière : j'ai un temps donné que je peux/veux consacrer à un projet d'application web, je peux refaire mon framework, ou estimer que la valeur ajoutée de mon travail sera mieux valorisée coté expérience utilisateur :-)

Enfin est c'est un point non "théorique" : est-ce que tous les développeurs on le niveau de réécrire les fonctionnalités d'un framework ? N'est-ce pas mieux de leur fournir un cadre dans lequel il pourront s'exprimer plutôt que de les laisser se perdre ?

A titre personnel, j'utilise Cakephp, qui est trop rigide par certains aspect, mais qui convient pour le type de projet que je développe. Il me laisse suffisement de latitude pour m'exprimer à un autre niveau. De plus sur un projet particulier il y a quelques années j'ai étudier le framework en profondeur et j'ai modifié superficiellement certaines parties pour l'adapter à un besoin particulier. On est jamais complêtement bridé ;-)

Je termine sur une citation : "Standing on the shoulders of giants" (ou en français : "Des nains
sur des épaules de géants")

[Michel Rotta]

Mais non, je ne suis pas méchant...

Bon anniversaire Manulion.

Les choses sérieuses maintenant (et j'insiste sur sérieux).

Juste une remarque qui va permettre de réduire le périmètre de l'interprétation que l'on pourra faire de mes propos. Ils concernent le développement en entreprise, où assimilé, celui qui doit nourrir le développeur et les équipes qui tournent autour de lui (et le centre des impôts, mais c'est une autre histoire...). Je respecte les Amateurs qui développent sans soucis de rentabilité et de se nourrir avec. Notez la "A" majuscule pour Amateur, ce terme étant pour moi honorifique et non pas péjoratif (Amateur - amateur de « celui qui aime (qqn) » ).

Justement, il est préférable pour un débutant de commencer sans framework pour comprendre la méthode de base. Comme à l'école: on apprend à calculer avant d'utiliser la calculatrice.

On ne parle pas du même débutant. Pour moi le débutant arrive en entreprise après 2 ans, au moins, d'études en développement. Ils arrivent enfin dans le dur monde du travail et il est important qu'ils permettent à leur entreprise de gagner de l'argent, si non, ils vont perdre leur travail. Ils peuvent être des Amateurs, mais, dans le cadre d'une entreprise, ils doivent produire du code modifiable (par d'autre), sur, rapide, et rentable. Chez eux, le soir, ils font ce qu'ils veulent. Il est évident, là, que le framework est un cadre qui apporte beaucoup plus d'avantages que d'inconvénient.

Je sais, mais là on parle de PHP. Que le PHP et aucun autre langage. On parle des frameworks qui sont dédiés à PHP. Les couches d'en dessous sont peu importantes ici. Du moins, je n'en vois pas leur importance.

Tu ne peux pas limiter la discutions d'une manière arbitraire, simplement parce que tu sais que tu n'as pas la possibilité de justifier tes arguments dans le reste de l'espace informatique. C'est un peu comme si tu décrétais que les nombres possèdent tous une racine carrée dans R. Ce qui est faux. Et quant on te met le nez dedans tu veux limiter ta démonstration aux nombres >0, les autres n'étant pas importants !

On ne peut pas limiter une démonstration abusivement à un domaine qui est arrangeant. Et si tu ne comprend pas comment fonctionnent les différentes couches logiciels, apprends, après, nous pourrons rediscuter de ton présupposer et, ensemble, démontrer qu'il est faux.

On va aller un coup plus loin. Dans mes débuts sur PHP, j'ai utilisé un framework d'accès aux données qui rajoutait une sécurité dans les échanges avec MySql. Il s'appelait Créole et n'existe plus aujourd'hui. Pourquoi ? L'équipe de PHP a considéré que cet échange devait être sécurisé. Ils ont donc créé un ensemble de commandes, appelé PDO qui rend les mêmes services, plus rapide vu que codé dans le système. Notre framework est donc devenu commande intégrée. Mais faut-il l'utiliser vu qu'elle vient d'un framework ? Et ce n'est qu'un exemple parmi de nombreux possible, c'est même un des principes de développement du langage PHP. Intégrer les framework spécialisés au cœur du langage.

Ne pas y voir ici, la démonstration de l'absurdité de ton raisonnement constitue une grosse erreur.

Faut commencer par trouver où se situe la source de la situation. Quel domaine (finance, GI, SI, développement web, etc)? La solution de "on l'utiliser parce que c'est gratuit et c'est vite" est relativement stupide. Stupide dans le sens où c'est du non respect de ceux qui ont créé cet outil, et c'est un manque de respect et d'intérêt envers la personne à qui le projet s'adresse. Il vaut mieux faire les choses bien et lentement que vite et instables. En tout cas c'est pas bête: pourquoi pas essayer d'en trouver une autre...

Deux question en une. La première trouve sa réponse ci-dessus.

Pour l'utilisation d'un framework parce qu'il est gratuit, je trouve cela mignon. Une démonstration par le fait que tu ne sais pas de quoi tu parles. Tu penses vraiment que les frameworks sont gratuit ? C'est méconnaitre le coût d'un framework. Je ne tiens pas à citer de nom de framework, mais le seul coût d'acquisition est loin d'être la seul chose à prendre en compte. Le plus grand coût, sur un framework ou un langage, c'est l'apprentissage. Ceci à un coût certain. Cela met le prix d'un framework bien au delà du gratuit.

Et je ne parle pas de l'erreur de choix ou de la dissolution de l'équipe qui le maintient. Ce qui va entrainer des adaptations, voir des re-développements pour coller à un autre framework.

Non, un framework n'est pas gratuit, pas plus que d'installer du Linux sur tous les postes de travail, ou de passer toutes ses machines d'une suite de logiciels bureautique payante à Libre Office. Tous cela à un coût qui peut être plus important que de reconduire les licences existantes.

D'accord, sûrement qu'un framework passe le point de la sécurité. Mais qu'en est-il de la sécurité de l'information? Qu'est-ce qui nous garantie que l'information est bien gérée par celui-ci? Dûr dûr de savoir comment il la gère... Pourtant, la gestion de l'information (par information, on entend les données de bases de données, fichiers, contenu du site, etc) revient au développeur mais celui-ci semble vouloir déléguer la tâche au framework.

Encore la démonstration de ta méconnaissance du sujet. Il est bien plus simple de savoir comment un framework traite les données que de savoir comment PHP ou MySql (sans parler des couches systèmes) les traitent. En effet, le framework est écris dans le langage du développeur qui l'utilisent. Pour comprendre comment PHP va traiter les mêmes données, il faut commencer par comprendre le C. Ce qui n'est pas évident pour tous les développeurs PHP.

Et qu'est-ce qui va me rassurer sur le traitement des données par un développeurs qui n'utilise pas un framework ? A-t-il protégé son application contre l'injection SQL ? Cf l'exemple sur la couche PDO.

Quel travail?

Développe une vraie application avant de te moquer du travail qui est effectué par une majorité des personnes présentes sur ce forum.

La bêtise, la méchanceté et l'ignorance ne peuvent constituer une quelconque démonstration de tes propos. Juste mettre en avant l'absence d'argumentation.

Pas nécessairement.

(sur la nécessité de reprendre les bugs découverts dans l'ensemble du code produit).

C'est l'illustration de ta méconnaissance du monde réel (sorti des murs de ton école). Deux possibilités.

Tu es constant dans tes développement, refuse de factoriser ton code, vu que cela va te conduire à utiliser un framework, même personnel, ce qui va te brider. Tu trouves une erreur sur un code important et répété dans l'application. Comment pourras-tu justifier à ton client que tu ne le corrige pas partout et que tu lui laisses une application potentiellement dangereuse ? Et à l'autre client, celui que tu as développé juste avant, que lui réponds-tu lorsqu'il vient te voir pour te demander des comptes sur cette erreur, que tu connaissais et a choisi de ne pas corriger ?

L'autre possibilité est plus inquiétante, pour renforcer ta volonté de ne pas factoriser ton code, tu développes à chaque fois d'une manière différente en brodant autour des algorithmes. Il est sur, alors, qu'une erreur existante à un endroit ne sera pas identique ailleurs. Mais est-ce plus sur ?

Ce qui est sur, c'est que si je suis le client, dans le meilleur des cas, plus jamais je ne travaillerais avec toi. Dans le pire (mais très probable) des cas, on se retrouvera très vite devant un tribunal pour le calcul des dommages et intérêt. Et tu payeras le re-développement, fait par d'autre, à l'aide d'un framework, un comble...

Est-ce assez argumenté? Et sinon, au niveau théorique, qu'as-tu à me dire? Parce que là, c'est bien beau la technique, mais le problème il est au niveau théorique, dans l'abstrait.

Argumenter ? Je te conseil de passer sur un dictionnaire pour apprendre le sens de ce mot. Non, ce n'est pas assez argumenté. Ce n'est absolument pas argumenté. A part ton intime conviction, il n'y a rien dans ton raisonnement.

Pour le niveau théorie, je ne peux que te conseiller de terminer ton bac (ou l'équivalent) de faire une bonne école préparatoire en mathématique, puis un diplôme d'ingénieur en génie logiciel. Ce que je ne peux te donner dans une réponse ici.

Quant à considérer que le problème du développement doit rester dans l'abstrait. "Non, monsieur le procureur, ne le condamner pas ! Il ne voulait pas tuer le juge en sortant de tel choses, il n'avait en aucune manière l'idée de l'étouffer de rire." Il n'y a rien d'abstrait dans le travail d'un développeur, il doit rendre un travail, dans un délais, à un coup, qui répond à un cahier des charges.... et j'en oublie.

Il y a des jours où ça ne fait pas de mal d'aller à l'encontre des décisions des gens. Rien que pour essayer.

Parfois, on peut ce retrouver. C'est ici que l'Amateur peut trouver. C'est ici que le chercheur pour exister. Mais pas un développeur dans son travail courant (je parle bien du travail de tous les jours).

Dans un projet industriel, il n'y a que l'argent qui compte. Le reste (innovation, technique, théorie, le code, technologie, etc) n'est bon que pour la poubelle.

Encore une fois, tu parles de choses que tu ne comprends pas. Il y a de l'innovation dans les projets industriels, pas dans tous, mais l'innovation, peut-être rentable. Les exemples sont tellement nombreux autour de toi qu'il te suffit d'ouvrir les yeux. Regarde bien, tu as une innovation industriel juste devant tes yeux. Sans oublier celle qui est sous tes mains.

À mon avis, ce n'est pas pour le code en tant que tel que nous devrions payer (payer celui qui l'écrit entre autres). Ça devrait plutôt être basé sur la réflexion et la solution au problème.

C'est désespérant comme réflexion. Une méconnaissance total de ce qui est juste de l'autre côté du mur de l'école.


Cette discutions tourne en rond sans aucun intérêt. Je pense que la seul solution pour la rendre viable, plutôt que de démontrer que tu sais utiliser un outil de forum et de faire des messages de réponses avec plein de citation serait de construire une réel argumentation de ce que tu veux démontrer, si non, tu retomberas très vite dans le néant de la méconnaissance et des idées sans suites.

[Joker-eph]

Mais non, je ne suis pas méchant...

Ouch, heureusement qu'il y a ce "disclaimer" ;-)

Encore la démonstration de ta méconnaissance du sujet. Il est bien plus simple de savoir comment un framework traite les données que de savoir comment PHP ou MySql (sans parler des couches systèmes) les traitent. En effet, le framework est écris dans le langage du développeur qui l'utilisent. Pour comprendre comment PHP va traiter les mêmes données, il faut commencer par comprendre le C. Ce qui n'est pas évident pour tous les développeurs PHP.

Et qu'est-ce qui va me rassurer sur le traitement des données par un développeurs qui n'utilise pas un framework ? A-t-il protégé son application contre l'injection SQL ? Cf l'exemple sur la couche PDO.

Je vois un bémol à ce que tu dis : framework ou pas, un bon développeur doit être "aware" des problème de sécurité type injection SQL ! Rien à voir avec le C

Et j'ai du mal à voir de quoi tu parles : "Il est bien plus simple de savoir comment un framework traite les données que de savoir comment PHP ou MySql (sans parler des couches systèmes) les traitent."

[smoser]

Bonsoir,

Je me suis mis à lire ici-même les commentaires qui y ont été postés. Je me rends compte que l'on a passablement dévié de l'article de base. Cependant, les interventions étant intéressantes je vais y amener mon propre point de vue.

Selon moi il est tout d'abord nécessaire de distinguer le public cible, car la réponse peut fortement diverger selon celui-ci.

** Public cible / but **
- Etudiant-Amateur / Apprendre les concepts :
Débuter par l'apprentissage de l'utilisation d'un framework sans passer d'abord par l'apprentissage des concepts de base... n'est pas une bonne chose. Utiliser un framework c'est se simplifier la vie, ne coder que le "strict nécessaire", le code "métier". Or lorsque l'on apprend... le but est plutôt d'apprendre les concepts sous-jacents, "comment ça marche", "comment c'est construit". Or les frameworks imbriquent des concepts (algorithmes, designs patterns, ...) complexes et les assemblent le tout pour que vous n'ayez pas à vous en soucier lorsque vous codez. Il vaut mieux : 1) apprendre les concepts de base et ensuite 2) ouvrir le code source d'un framework pour voir comment ils ont été implémentés... que l'inverse.

- Professionnel / Développer des applications :
On peut voir un framework comme une boîte à outils. Si cette boîte correspond à nos besoins... autant l'utiliser ! Cela nous fait gagner du temps et assure par le biais de la communauté qui est autour du framework : 1) une certaine stabilité du produit 2) une certaine sécurité d'implémentation 3) une certaine évolutivité 4) la re-usabilité du travail déjà fait par d'autres personnes (modules, plugins, extensions, ...)

Si la boîte à outils ne correspond pas à nos besoins :
a) en choisir une autre qui correspond mieux à nos besoins
b) modifier/adapter l'existant à nos besoins (quitte à créer un "fork" du framework)
c) ne pas utiliser de frameworks existants car aucun ne convient (et/ou cela demande trop de temps/argent de les adapter) et coder soi-même le produit qui répondra aux besoins soit sous la forme d'un framework, soit sans framework (cela dépend du temps et des besoins/objectifs).

En industrie, ce qui compte c'est :
1) Satisfaire aux besoins du client
2) Dans les délais
3) En retirer un bénéfice suffisant pour faire tourner la société
4) Assurer une formation continue suffisante à son personnel (ou renouveler le personnel ... c'est une question de choix) pour qu'il effectue son travail : efficacement, rapidement, de manière "professionnelle".

Le choix d'utiliser ou non un framework dépend des points précédents....

- Chercheur / Créer de nouvelles technologies :
Dans ce cadre, utiliser un framework n'est pas toujours la bonne solution. Les frameworks ont souvent des limitations assez contraignantes intrinsèques à l'architecture choisie lors de son développement. Un chercheur qui doit innover aura parfois avantage à créer son propre framework qui correspond à ses besoins précis! Par contre, il est toujours intéressant pour le chercheur de comparer les différents frameworks et les différentes architectures qui ont été implémentées pour se faire son propre avis, sa propre idée de ce qu'il veut ou ne veut pas. Il utilisera plutôt les frameworks en regardant "comment ils sont faits" pour s'imprégner des idées/fonctionnalités qui les composent pour créer le sien, quitte à réutiliser du code source (fonctions, class) dans sa propre application.

** Découverte de vulnérabilité **
Concernant le point évoqué sur la découverte d'une vulnérabilité, je pense que l'on est hors sujet. Que l'on utilise un framework ou non, le problème se pose. La différence va se situer sur 2 points importants :
- La vulnérabilité est intrinsèque au framework utilisé. Dans ce cas, la mise à jour du framework par le client (s'il n'y a pas eu de modifications de son code source pour y implémenter de nouvelles fonctionnalités "maison") va résoudre le problème sans se soucier de l'application créée et vendue par le fournisseur.

- La vulnérabilité est intrinsèque au code créé par le fournisseur. Dans ce cas, soit le client a sousrcit à une "garantie de support" auprès du fournisseur, auquel cas il demande au fournisseur un patch pour corriger le problème; soit le client n'a rien souscrit de tel et se débrouille lui-même pour créer le patch.

Créer une application sans framework ne sous-entend pas que l'on n'utilise pas de classes, de fonctions, ... qui évitent de répéter le même bout de code source à plusieurs endroits !

** Gratuité du framework **
Le critère de choix d'un framework pour sa gratuité n'est pas un argument valable. On ne choisit pas un framework plutôt qu'un autre pour son prix, on le choisit pour sa capacité à répondre à des besoins réalisables en un temps donné dans un budget donné.

** Transmission des informations / Gestion de l'information **
Je pense que la critique sur le manque de transparence de la gestion de l'information n'est pas raisonnable. Dans un framework, on va justement utiliser des couches d'abstraction pour pouvoir séparer les données du reste du code. A cet effet, on concentre toute l'information dans des lieux connus. Si on a un doute sur la sécurité du transfert de l'information, rien n'empêche d'ajouter une couche d'abstraction qui traitera de la sécurité, du chiffrement, ... de l'information et qui restera indépendante (ne touchera pas au code) du reste du framework.

** De l'utilisation d'un framework **
A mon sens utiliser ou non un framework ne remet pas en question les connaissances "métiers" du développeur. Ce n'est pas parce que l'on utilise un framework que le développeur perd ses compétences. C'est à lui de se tenir à jour, cela fait partie de sa formation continue. Cela n'a rien à voir avec l'utilisation d'un framework ou non.

Utiliser un outil plus simple permet d'être plus efficace, et donc de se concentrer sur les véritables problèmes que le développeur aura à traiter : les algorithmes métiers à implémenter. S'il doit se soucier à chaque fois de la sécurité des données, de l'usage des sessions, de la persistence, de la mise en cache, ... dans son développement il va perdre beaucoup de temps à coder des choses qui sont hors de ce qui lui est explicitement demandé ! : coder les algorithmes métiers !

** Confiance dans le code source du framework **
Ce point est crucial lors d'un développement ! Si l'on ne peut pas faire confiance à la qualité du code source déjà développé... il n'est tout simplement pas envisageable d'utiliser le framework en question. C'est pourquoi : la réactivité de la communauté aux bugs soumis, aux suggestions, ... est très importante. C'est également pour cette raison que certaines sociétés se spécialisent dans le support d'un framework et le font payer... Il faut utiliser un framework en connaissance de cause, en sachant si à chaque bug trouvé il va falloir passer nous-mêmes des heures, des jours, ... à le corriger nous-même ou si on peut faire confiance à la communauté pour résoudre rapidement le bug et proposer un patch, une nouvelle release, ...

** Framework = centaines de fonctions inutiles **
Sur ce point je suis souvent d'accord. A quoi sert-il d'utiliser un truc très complexe bourré de fonctionnalités si l'on veut en utiliser qu'un dixième ? Les deux gros points noirs des frameworks sont :
-- la lourdeur de la solution : nombre de fonctionnalités que nous n'utiliserons jamais et qui sont implémentées.... et qui sont susceptibles d'être buguées !!!
-- le temps d'exécution de la solution : plus le framework est évolué, complexe, plus il a de couches d'abstraction, moins il est rapide !!!
Il serait vraiment très judicieux d'édifier des frameworks sur lesquels on "compile" (comprendre "intègre" dans le cadre du php) que les fonctionnalités utiles et utilisées ! Des frameworks où l'on choisit à l'installation les modules que l'on veut et que l'on ne veut pas intégrer.... même au niveau du "core" du framework.

** Beauté du code **
La beauté du code source... C'est sympa de coder pour la beauté du code... mais cela ne permet pas de gagner son salaire. Cela n'est possible que si l'on est Amateur-Etudiant-Chercheur. Dans le cadre de l'employé, la beauté du code n'est pas un aspect très important... ce qui est important c'est que "ça marche" et que "en cas de problème le code puisse être vite corrigé" (temps de maintenance faible)

** Réunion d'une communauté autour d'un framework **
L'utilisation d'un framework a également un autre avantage. Celui de fédérer une communauté à sa cause ! Grâce à cela, n'importe qui peut proposer des nouvelles fonctionnalités, identifier et résoudre des bugs, et également avoir des idées que nous n'aurions pas eu nous-mêmes ! Oui car lorsque l'on fait un projet à plusieurs il est fortement probable que les collègues aient une autre vision que la vôtre, d'autres idées, d'autres suggestions... par le biais de leur propre expérience, formation... Cela est un avantage indéniable sur un projet ! Pouvoir avoir plusieurs idées différentes pour résoudre le même problème et pouvoir choisir celle qui nous convient le mieux !

[Joker-eph]

** Framework = centaines de fonctions inutiles **
Sur ce point je suis souvent d'accord. A quoi sert-il d'utiliser un truc très complexe bourré de fonctionnalités si l'on veut en utiliser qu'un dixième ? Les deux gros points noirs des frameworks sont :
-- la lourdeur de la solution : nombre de fonctionnalités que nous n'utiliserons jamais et qui sont implémentées.... et qui sont susceptibles d'être buguées !!!
-- le temps d'exécution de la solution : plus le framework est évolué, complexe, plus il a de couches d'abstraction, moins il est rapide !!!
Il serait vraiment très judicieux d'édifier des frameworks sur lesquels on "compile" (comprendre "intègre" dans le cadre du php) que les fonctionnalités utiles et utilisées ! Des frameworks où l'on choisit à l'installation les modules que l'on veut et que l'on ne veut pas intégrer.... même au niveau du "core" du framework.

C'est vraiment un des seuls points auquel j'ai du mal à adhérer...
Mon système d'exploitation possède plein de fonctionnalités qui me sont "inutiles", idem pour mon traitement de texte, etc.

Toutes ces fonctions "inutile" sont désactivés dans le framework si je ne m'en sert pas, par exemple : si je n'active pas explicitement les sessions, mon framework ne chargera pas les composants dédiés à la gestion des sessions, dès lors que m'importe qu'il y ait quelques (centaines de) lignes de php inutiles, puisqu'elles sont dans des fichiers qui ne seront jamais lu/chargés/exécutés/...

Pour rester dans le framework, mais en changeant de langage : on trouve beaucoup de "framework" javascript qui propose de personnalisé le package que l'on va télécharger en choisissant quelles fonctionnalités on souhaite utiliser. Mais ça se comprend mieux parceque le packaging se fait dans un fichier unique qui est toujours téléchargé et parsé par le navigateur du client.

[Michel Rotta]

** Framework = centaines de fonctions inutiles **

C'est aussi un point qui m'a interpellé sur ton intervention.

Effectivement, certains framework ne chargent que les modules utilisé ou permettent de désactiver les modules inutiles pour une application. C'est le mieux.

Mais si je sors du domaine des Framework et me jette à pied joint dans celui, différent, des tableurs. Que je prends comme référence les deux gros du marchés (excel et calc (OOo) ). Si je regarde les utilisateurs, ils vont utiliser, pour 95% d'entre eux, dans les 1% des fonctionnalités. Et encore. Et là, cela semble normal...

Je pense donc que, sauf question pertinente de performances, c'est un faux problème.

Et que l'on ne viennent pas me dire que PHP est plus rapide pour afficher "Hello word", et plus simple. C'est vrai ! Mais cela n'a aucun intérêt. Quoique, mon framework de prédilection, correctement configuré, affichera, à la deuxième lecture, le "Hello World", plus vite qu'un bête code PHP... Si si !

[smoser]

Concernant ma critique sur le code "inutile", je me base sur deux aspects :
- la sécurité
- le package minimal.

Pour la sécurité, si vous reprenez l'exemple des suites bureautiques... l'utilisateur a beau utiliser 1-10% des fonctionnalités..... toutes les autres sont présentes et actives. Il n'y a pas moyen de les désactiver ni de les retirer. Chacune de ces fonctionnalités (non utilisée par l'utilisateur) est susceptible d'être buguée et de conduire à devoir patcher le produit entier. Car le produit est considéré comme un "tout" non modulaire.

Pour le package minimal, si l'on considère bêtement l'espace disque, notre solution n'est pas minimale si l'on a des centaines de lignes de codes désactivées dans le produit... Elles restent présentes.

Mon intervention minimale sur ce point provient du fait que je suis déjà tombé sur des produits (pas forcément des frameworks) qui proposent 36'000 fonctionnalités dans leur produit et qu'il n'est pas possible de ne pas les installer.... C'est également le cas dans certains frameworks.

C'est probablement parce que je viens d'une formation en informatique technique plutôt que logicielle que j'ai en tête ce genre de problématiques. Quand on est limité à 32k en mémoire vive... à 1-2Mb en mémoire disque, on fait attention à n'implémenter que le strict nécessaire. C'est également pour cela que j'ai parlé de "compiler". L'exemple est également flagrant lorsque l'on développe des malwares, on essaie d'avoir le package minimal pour limiter au maximum la détection de son téléchargement.

Concernant les frameworks qui implémentent des manières de désactiver les modules désirés (même au niveau core, si si j'insiste sur le core!), voire de ne pas les installer c'est parfait ! Personnellement je n'en connais pas.... J'en connais uniquement pour désactiver des modules additionnels, mais pas pour les fonctionnalités intrinsèques au core (caching,persistence,sessions,plurilinguisme,templating,...).

[Michel Rotta]

Zend, qui n'a pas à proprement de core, le permet.

symfony 1.x a aussi la possibilité de désactiver presque toutes les fonctionalités inutiles.

Symfony 2 est lui encore plus souple, il ne les charges que si c'est nécessaire.

Les autres, je ne les fréquente pas, donc je n'ai pas d'avis.


Pour ce qui est de l'installation, il faut bidouiller pour retirer ce qui ne sert pas. Mais, dans le monde des sites web, on est rarement limité en place par le framework. On peut l'être à cause des fichiers enregistrés par les utilisateurs, mais alors, la place récupérée par le framework est minime.

Il vaut mieux bien configurer son cache et son accélérateur PHP le gains en performance sera plus flagrant.

Et je maintient, je peux envoyer une page "Hello World", avec mon framework, plus vite qu'une simple page en PHP, à partir du deuxième envoie.

[Joker-eph]

Pour le package minimal, si l'on considère bêtement l'espace disque, notre solution n'est pas minimale si l'on a des centaines de lignes de codes désactivées dans le produit... Elles restent présentes.

Absolument négligeable vu les coûts du stockage de nos jours...

Concernant les frameworks qui implémentent des manières de désactiver les modules désirés (même au niveau core, si si j'insiste sur le core!), voire de ne pas les installer c'est parfait ! Personnellement je n'en connais pas.... J'en connais uniquement pour désactiver des modules additionnels, mais pas pour les fonctionnalités intrinsèques au core (caching,persistence,sessions,plurilinguisme,templating,...).

J'ajoute Cakephp à la liste : les "core components" ne sont pas chargés si non explicitement demandés.

Michel> Je suis étonné par ce que tu annonces sur le hello world : le temps de vérifier si la donnée est à jour dans le cache devrait être au moins aussi coûteux qu'un echo "hello world !" non ?