Coder from scratch
Voilà l'heure de la réflexion sur mes 9 ans de développement PHP. Je suis passé par un paquet de frameworks, de CMS, et je ne peux qu'apprécier d'avoir une standardisation de travail. Cela dit, alors que je tente de coder un petit site interactif et communautaire... je me suis passé de CMS ou de framework. Les raisons sont obscure, je suis parti de tests et j'ai continué à implémenter du code... et du coup j'ai oublié de passer par un framework. Sauf que voilà, le résultat fonctionne très bien, il est rapide... et je dois alors me poser la question: est-ce si bien de travailler avec un framework ou un CMS ?
Non je ne crache pas dans la soupe qu'on me sert. Je ne suis pas là pour déblatérer des guerres de clochers sur tel ou tel framework ou CMS, mais après être passé par EZPublish, Drupal, Jumlaa, Copix, Zend et autre... je pense pouvoir me faire une petite idée.
Ce que je vais vous expliquer relève en fait qu'il y a beaucoup de cas où il est peu judicieux de passer par un framework ou un CMS. Mais aussi que ces outils peuvent être au contraire un gain de temps. Alors avant de me hurler dessus, lisez bien mes propos :)
Tout d'abord l'idée du projet: un blog... bon c'est peut-être simpliste mais c'est un projet franchement répandu hein. De quoi j'ai besoin:
- de faire un ticket (un article en fait, daté, tagué...)
- mettre en forme
- avoir un flux RSS
Ce que j'ai sous la main:
- un serveur linux avec accès root
- apache, php 5, sqlite ou mysql
Voyons ce que je peux faire. Soit j'utilise un CMS, au hasard: Drupal. Et voici ce que je dois faire:
- poser mon drupal sur mon poste
- le décompresser et commencer son installation
- travailler un design, l'intégrer
Pour ces opérations, je vais avoir besoin d'un recours technique. Normal, mais il faut connaitre l'outil Drupal... les templates et le thémage est peut-être facile, il n'en reste pas moins que la moindre petite erreur me vaut de fouiller sur le net pour comprendre ce que j'ai foutu...
Par contre, en passant par l'admin, je trouve comment mettre mon flux RSS en marche, tout fonctionne directement et je n'ai plus qu'à passer mon site sur le serveur... oui mais...
Et oui, pas le même PHP, pas la même base... et me voilà en train de passer du temps à corriger mon installation pour que ça passe.
Si je le codais moi même ?
Oui allez, on va faire simple... je suis développeur quand même !
Déjà je commence par un petit gabarit HTML. Bon il est pas mal... j'attaque le code. D'abord une table de données... on va y mettre les tickets (id, titre, short, content, date, draft). Ensuite me reste à faire simple: un foreach sur la table pour afficher mes ticket dans mon gabarit...
Tiens en passant, je traite vite fait mon ticket pour faire du pseudo wiki (quelques regexp et c'est finit). Et allez on ajoute un formulaire pour les commentaire, un captcha avec pear...
J'ajuote un pager, je génère mon RSS, un table de tags et une table de liaison entre mes tags et mes articles.
Temps de l'opération: 2 heure en tout (gabarit compris)... alors me diriez vous, pourquoi on se fait ch..er à prendre Drupal ? Ba simplement parce que Drupal voit son code retravaillé, sécurisé et vous allez avoir des tas de modules pour configurer et faire évoluer votre site.
Par contre mon code généré à la main, il va vite... sans compter que je génère mon cache avec apc... je vous dis pas. Et puis le code est simple, clair, précis, adapté.
Voilà je veux être clair avec vous, PHP est mal utilisé dans 95% des cas... Pourquoi passer par des DAO (Data Access Objects) alors que les classes PDO incluses dans PHP sont très bien faite, gèrent les transactions, corrige les failles d'injection...
Pourquoi se battre avec du cache alors que APC a une API qui gère parfaitement cela ? Pourquoi passer par un moteur de template alors que PHP lui même est un moteur de template ? Pourquoi passer des heures à créer de modules alors que nous savons coder des classes proprement et rendre notre site très fonctionnel ?
Il est clair que beaucoup de cas contredisent ce que j'avance, par exemple les site de e-commerce sont complexes et franchement il vaut mieux passer par Magento plutôt que de se taper un développement interminable tout seul...
Mais j'ai passé un moment à faire quelques site "from scatch" pour voir à quel point on peut coder vite et bien un site fonctionnel et interactif... je vous assure que pour la quasi totalité le développement a été plus rapide et plus optimal que ce que je fais avec des Frameworks.
Pensez aussi à PEAR et PECL qui vous donnent des classes toutes prête pour certaines choses bien complexes à réaliser de zéro (soap, captcha, graph...).
Voilà, je me prépare à écrire un e-book sur le développement from scratch et les méthodes les plus fiables... donc si vous êtes intéressé repassez voir le site.
PS: je recode mon blog à la main... je pense que dans la semaine qui suit vous aurez droit à mon code en opensource.
Trackbacks
Pour ajouter un trackback (retrolien) sur ce ticket, utilisez cette adresse: http://www.metal3d.org/index.php/trackback/default/tb?id=blog%2F262
Enfin un dev qui cesse de faire l'apologie des frameworks à tout prix, ça fait plaisir !
En fait je pense que pour être vraiment efficace avec un framework, il faut le connaitre sur le bout des doigts (ce qui est généralement très long à apprendre) et ne faire que ça. Et là, oui, on peut coder rapidement des sites, pas toujours performants...
À mon avis l'idéal c'est de se coder un petit framework perso qui sert plus de structure (MVC, gestion basique des sessions, cookies, cache...) que d'outil à tout faire. Parce que bon, générer des formulaires HTML avec que du PHP, ça devient un peu ridicule...
Voilà exactement ce que je pensais. PEAR est une base de librairies bien foutues, j'ai une 10 aines de classes bien fichues pour gérer mon cache, mes bdd (simple surcouche à PDO) etc... et honnêtement je pense que ça rend les choses plus simples à faire.
Je vais finir par vous filer mon code hein :)
Le pire c'est que tout est vrai !
Comme souligné, PHP est très souvent mal utilisé, véritablement pas utile de rajouter 50 couches par dessus.
Le passage "moteur de template" est tellement révélateur...
Cependant je pense que la voix de la raison est un peu de botter en touche.
Comme Skreo l'a écrit, il est sympa de se faire une petite structure MVC... Minute!
Combien d'entre nous ont écrit un router/dispatcher avec prise en charge MVC derrière; on se rend vite compte que l'on refait la roue (souvent carrée au final).
Il y'a aussi le fait selon les cas de se retrouver avec un code spaghetti salement indegeste (surtout en teamwork).
Coté FW, avez-vous testé Kohana 3 ?
Le bon point est qu'il n'intègre que la gestion des routes et HMVC, les quelques modules disponibles sont optionnels.
Cela permet de se lancer vite, mais de pouvoir tout coder à la main, d'utiliser PEAR, et pourquoi pas quelques libs Zend FW.
Au final, coder "à la main", cela va plus vite, ça ne fait aucun doute... Pour le peu que la base soit saine.
@evos C'est en fait ce que j'avance. Mon point de vue est d'avoir un FW assez souple pour coder "from scratch" certaines routes et le coté métier, mais de ne pas avoir les empilements de couches qui rendent le travail trop strict.
Je suis en train de coder un micro framework nommé "valaya" (comme la déesse de nains guerriers de Warhammer) qui se trouve sur googlecode. J'avance de temps en temps et je vous tiendrai au courant.
Je connais kohana mais je n'ai pas été emballé. Question de gout me direz vous :)
Bref, je suis content de voir que je ne suis pas le seul à me confronter à cette problématique.
Hello,
Pour une utilisation précise un code unique sera toujours plus rapide (plus sécurisé cela dépends...) par contre si tu utilises pear/pecl cela revient a utiliser des librairies ... et dans ce cas le même travers que des framework peut-être observés ...
L'avantage des framework/librairies/script-all-in-one se révèle dans le cadre d'une industrialisation, réutilisation, etc ...
Par contre, si on reprend ces mêmes outils et que l'on utilise les caches APC ou autre on obtient de sérieux gains de performance ...
Dans la lignée de ton article, j'ai trouvé cet article contradictoire :
http://blog.vincentgache.com/2010/08/26/php-je-ne-le-script-plus-je-le-framework/