- Fil d'ariane : Accueil du devBlog
- / Détail du billet (Lien direct)
De l'usage ... ou non des Frameworks
...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 PHP, 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?
Commentaires
[#2] Commentaire rédigé le Samedi 03 Décembre 2005 à 10:18 par Antoine
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"
[#3] Commentaire rédigé le Samedi 03 Décembre 2005 à 10:56 par MonsieurN
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).
[#4] Commentaire rédigé le Samedi 03 Décembre 2005 à 13:15 par NiKo
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.
[#5] Commentaire rédigé le Dimanche 04 Décembre 2005 à 20:02 par soso
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.
L'ajout de commentaire a été désactivé pour ce billet.
Trackbacks
Pisteurs vers ce billet (trackbacks entrant)
Il n'y a pas encore de pisteurs pour ce billet.
Pistés par ce billet (trackbacks sortant)
Il n'y a pas encore de pisteurs effectué par ce billet.


[#1] Commentaire rédigé le Samedi 03 Décembre 2005 à 10:11 par Fetard