Un tutoriel pour apprendre à développer des applications avec un framework ?

[Zamentur]

Le dieu de la programmation écrira simplement la même chose (à peu de choses près) que le framework, en spécialisant un peu plus selon ses besoins. En développement, les mêmes besoins mènent souvent aux mêmes solutions (d'où la naissance des design patterns).

Ben en même temps c'est vrai il y a beaucoup de boites qui ont leurs frameworks à eux. Et je pense pas que Symfony ou ZF soient parfait.

Je pense qu'un framework non-publié peut être très bon. Ceci étant quand on a rien et qu'il n'y a pas de limitation (technique, je parle pas de contrainte) du au framework, ben c'est vrai que çà vaut le coup.

Sauf si bien sur on tire une certaine fierté à se dire que c'est du 100% soi, ou que l'on a un objectif d'apprentissage particulier.

[Sephi-Chan]

Le dieu de la programmation écrira simplement la même chose (à peu de choses près) que le framework, en spécialisant un peu plus selon ses besoins. En développement, les mêmes besoins mènent souvent aux mêmes solutions (d'où la naissance des design patterns).

Ben en même temps c'est vrai il y a beaucoup de boites qui ont leurs frameworks à eux. Et je pense pas que Symfony ou ZF soient parfait.

Je pense qu'un framework non-publié peut être très bon. Ceci étant quand on a rien et qu'il n'y a pas de limitation (technique, je parle pas de contrainte) du au framework, ben c'est vrai que çà vaut le coup.

Sauf si bien sur on tire une certaine fierté à se dire que c'est du 100% soi, ou que l'on a un objectif d'apprentissage particulier.

On est d'accord : aucun framework n'est parfait.

La perfection dépend de ce qu'attend l'utilisateur. Difficile de fait l'unanimité avec des milliers de personnes. Même un framework interne ne satisfait pas forcément tous ses utilisateurs (infiniment moins nombreux).

Les frameworks comme Symfony et Ruby on Rails sont nés comme les autres frameworks privés : d'un besoin. La différence avec les centaines d'autres frameworks privés, c'est qu'ils ont été publiés.

En revanche, niveau qualité de code, on peut être sûr qu'un ZF, un Symfony, ou un Ruby on Rails, est plus proche de la perfection que les frameworks qui sont restés privés. C'est normal : ils ont des milliers de personnes qui testent, rapportent (et corrigent) des bugs, et peuvent apporter un œil critique.

Au final, donc, un framework open-source est forcément de meilleur qualité qu'un framework privé. Ensuite, les seul points encore discutables sont encore les questions comme "est-ce que ce framework répond à mes besoins ?", "mon environnement me permet-il d'utiliser ce framework ?", etc.

Même Twitter a finalement abandonné Ruby on Rails (qui n'est plus utilisé qu'en tant que front-end) au profit de Scala (qui porte bien son nom). Rails ne tenait plus la charge. Mais tout le monde n'est pas Twitter (vous imaginez le nombre de tweets par seconde ?).


Sephi-Chan

[Ter Rowan]

En revanche, niveau qualité de code, on peut être sûr qu'un ZF, un Symfony, ou un Ruby on Rails, est plus proche de la perfection que les frameworks qui sont restés privés. C'est normal : ils ont des milliers de personnes qui testent, rapportent (et corrigent) des bugs, et peuvent apporter un œil critique.

Au final, donc, un framework open-source est forcément de meilleur qualité qu'un framework privé.

Tu ne peux même pas conclure cela Sephi

d'un côté on a effectivement, des "milliers de testeurs" mais pour des "miliers d'utilisateurs" donc de besoin

==> le framework public couvre un large public donc un large panel de besoins (dont l'exhaustivité ne sera utilisé par personne)

==> le framework privé couvre lui un public beaucoup plus réduit donc un panel de besoins plus réduit aussi qui peut permettre une meilleure optimisation du code (car justement moins générique)

le framework public : plus exposé donc mieux testé et critiqué, mais aussi plus gourmand en ressources, plus complexe (je parle du contenu, pas de l'utilisation)

le framework privé : plus spécialisé, plus rapide, mais pas forcément dans les règles de l'art, donc potentiellement avec des failles (mais puisque dans un contexte spécialisé, ces failles n'ont peut être pas lieu d'être mais existeraient dans d'autres contextes).

je prendrais deux exemples qui illustrent cela

1) dans ma v0.01 j'avais démarré le développement d'une RIA avec moult drag & drop (pour la gestion de l'inventaire) avec de l'imbrication d'objets (au sens visuel j entends, pas poo) J'utilisais pour cela les framework prototype + script aculo.
constat : au bout d'un nombre assez faible d'objets à manipuler, ça ramait à mort. J'avais alors penser à choisir un concurrent (j'avais regardé jquery) et paf, je détecte la même lenteur

conclusion : je me suis aperçu qu'en gérant un peu mieux les événements que ce que proposait le standard "générique" de ces librairies, donc en développant ma propre couche spécialisée pour ce besoin mais assez générique (que ce soit de l'inventaire, de l'affectation de troupes ou autres, c'était la même "couche") je pouvais remplacer script aculo par mon propre "framework"
Alors bien sûr le niveau de développement était bien médiocre par rapport aux librairies (je suis rentré dans le code de script aculo et de prototype pour comprendre ce qui se passait, voir ce que je faisais mal, ma première hypothèse) mais niveau performance, ça arrachait (lent et saccadé ==> totalement fluide)

2) dans le cadre professionel cette fois il y a 5-6 ans peut être plus, un gars qui était en charge de nos datawarehouses avait développé (et fait développé avec ses équipes) un framework pl sql pour tout ce qui concernait les chargements de données (avec trace, etc...)
Malgré les attaques des "nan les etl du marché c'est mieux parce que tout le monde les teste, tout le monde l'utilise, ils gèrent tous les besoins" , ce framework a tenu comparativement d'un point de vue performance comme sécurité et fonctionnalité lors de tous nos tests (informatica et compagnie). Il était juste meilleur dans le contexte de la boîte à ce moment donné

[Sephi-Chan]

Je suis complètement d'accord, Ter Rowan. Je ne parlais pas de performance mais de qualité de développement. Pour les performances pures, bien sûr que la généricité a un prix.

C'est à nous développeurs de choisir quels outils utiliser : l'essentiel c'est d'utiliser des outils auxquels on peut faire confiance. Et c'est là que les frameworks open-source entrent en jeu.

Note aussi que pour développer son propre framework (si l'on sait vraiment ce qu'on fait), il est capital d'avoir des connaissances sur le fonctionnement des autres. Pour ça, il faut les utiliser, les étudier, etc.


Sephi-Chan