…du moins en PHP. Un jour Jérôme m’a demandé si j’avais déjà créé un Framework. A l’époque je lui avais répondu que non. Mais en fait, comme chaque développeur j’ai effectivement mis en place des packages destinés à mon usage personnel. Des fonctions non distribuées et qui pourtant ont pu faire leur preuve dans mes développements récents.
Mais de la simple bibliothèque de fonctions personnelles au Framework « corporate » il y a un grand pas à franchir à coup de démarche qualité, normalisation et autres contraintes liées à l’architecture des systèmes. Jonathan Snook, dans un billet très intéressant dit que dans la plupart des cas l’apprentissage d’un Framework revient à presque à apprendre un langage.
Learning a framework is really like learning a language.
On en vient à analyser les messages d’erreurs de l’API et non du compilateur ou du préprocesseur du langage… Attention toutefois, il reste modéré car il convient de dire, à juste cause que pour certains langage(il cite Ruby on Rail pour Ruby) la couche supplémentaire devient indispensable. Mais en [acronym]PHP[/acronym], a-ton besoin d’avoir un niveau d’abstraction. Pour ma part par exemple, je n’utilise pas PEAR et cela ne m’a jamais porté préjudice. Et vous, êtes-vous dépendant ou auto-dépendant?
Personnellement je commence tout juste à entrevoir les classes et leur possibilité de réutilisation…
Pour moi, l’utilisation de framework peut être très utile. A chaque développeur de trouver chaussur à son pied. J’ai développé un certains nombre de classe utiles qui peuvent ensemble former un framework. Le plus important étant, comme tu le dis Thanh, de se formaliser avec une nomenclature constante et bien faite. C’est, selon moi toujours, une des différences entre un framework et un tas de classes. C’est leur agencement, leur complétude, leur documentation et surtout l’homogénéité de celles-ci.
Mes classes sont toutes développées avec des interfaces, des classes abstraites. Une fois la documentation extraite, l’utilisation de ces classes est extrèmement simple. Il vrai qu’il est parfois genant de « perdre » une journée à documenter sa classe mais quand on sait que l’on peut, sur le projet suivant, en gagner plusieurs, cela vaut la peine.
Les frameworks, s’ils sont bien pensés, permettent de simplifier la vie du développeur, rendant le développement plus rapide, plus simple et facilement « upgradable »
En ce moment, les frameworks PHP se multiplient et c’est vrai que ça me paraît être vraiment compliqué à apprendre puis à mettre en place avant de pouvoir espérer aller plus vite que les méthodes de programmation que l’on met en place soi-même.
Pour PEAR, j’étais comme toi et j’ai découvert le package DB_Dataobject. Ce package m’a permis de manipuler mes données bien plus simplement qu’avant et après avoir compris comment ça marchait (c’est vrai que pour là, il y a quelques heures d’apprentissage pour bien tout comprendre), mon développement est allé beaucoup plus vite. J’ai un un mini framework perso basé sur le design pattern MVC et c’est avec cette classe PEAR que tout prend moins de temps. Les autres classes PEAR ne me paraissent pas avoir un grand intérêt mais celle-là est vraiment très utile et simplifie toute la programmation.
Maintenant tout le développement va plus vite et la modification de quelque chose n’est plus une corvée. Je te conseille d’aller y jeter un coup d’oeil (je ferais un petit tutoriel sur la mise en place de cette classe ce mois-ci je pense).
Le plus important, que l’on developpe son propre framework ou que l’on en utilise un, c’est de parfaitement le connaitre, ses forces et faiblesses comprises.
Il est impensable de tous les connaître, cette volonté – souvent extrêmement chronophage – peut pénaliser la progression et surtout l’efficacité.
Pour ma part je suis comme toi, j’ai développé une batterie de classes génériques qui me servent au quotidien. Et quand j’ai besoin de choses spécifiques, je me tourne en priorité vers les projets extrêmement maintenus et standardisés, comme PEAR.
J’ai commencé Java, et J2EE, avec l’apprentissage d’un framework ultra complexe, Struts. Et d’autres depuis.
Ceci m’a au moins appris qu’aujourd’hui, on ne programme plus, on configure une couche d’abstraction. ^^
C’est dans la logique des choses, de l’assembleur aux premiers langages, aux frameworks et super-frameworks aujourd’hui. C’est la même logique dans les applicatifs web : du simple appli web au portails les plus élaborés. On ne programme plus tellement.
Merci de vos témoignages
MonsieurN, je vais prendre le temps de jeter un coup d’oeil au package DB_Dataobject.
Soso, arrêtes de me parler chinois ::mrgreen