19-02-2015, 01:07 AM
(Modification du message : 19-02-2015, 01:29 AM par Sephi-Chan.)
Je ne vois pas l'intérêt d'ajouter des couches de traitement là où ce n'est pas utile. Tu peux produire du HTML ou du JSON (selon ce que le client demande) depuis ton code plutôt que du XML qui sera transformé en HTML ou en JSON. Un XML commun ne me semble pas pertinent dans la mesure où on n'attend pas les mêmes informations d'une API (ou d'un appel Ajax) ou d'une page Web : les traitements effectués par le serveur (requêtes SQL, etc.) divergeront forcément à un moment ou un autre.
@ Max : ça représente du boulot de se mettre a niveau parce que tu n'as pas appris dans de bonnes conditions ; Simplement parce que ces bonnes conditions n'existaient pas quand tu (c'est un tu de généralité) as appris PHP "from scratch" : il n'y avait pas ou peu de frameworks, pas de design pattern, un modèle objet balbutiant (PHP 4 c'est déjà le moyen âge), bref : c'était un milieu amateur.
Maintenant la technologie PHP s'industrialise et c'est très bien (moi je m'en fous j'ai changé de crèmerie, mais je sais quand même que c'est une bonne chose). Ca permet d'utiliser facilement des libs écrites par d'autres sans galèrer a les intégrer dans son projet (pour charger les bons fichiers), ni à les installer en dezipant une archive (bonjour la corvée de mettre à jour les versions, vive le gestionnaire de paquet et l'écriture d'une liste des dépendances qui permet de voir d'un coup d'œil ce qu'on utilise).
Tu crois que Composer alourdit ton processus de developpement mais tu te trompes. Il l'accélére considérablement. Pas besoin de te connecter à un quelconque site, puis télécharger, puis desarchiver pour mettre à jour une dépendance (ou même pour savoir que tu n'es plus a jour), une petite ligne de commande suffit.
Idem pour les frameworks, tu crois gagner du temps a t'en faire un minimaliste (pour t'economiser un temps d'apprentissage ? Mais tu le perds 100 fois en redéveloppant-en-moins-bien) mais tu te trompes probablement. Quand une des fonctionnalités de ton framework (qui aura été copié/collé d'une app a l'autre) présentera des défauts (bugs, failles, etc.) tu devras maintenir chaque app séparément. Toutes les fonctionnalités recurrentes d'une app sont les mêmes pour beaucoup (quels que soient tes besoins, d'autres ont eu les mêmes), et de très bons développeurs ont déjà repondu au besoin avec une bonne vision d'ensemble.
Même de vieilles technologies comme Java on parfois un apport de sang neuf (avec des frameworks comme Play!) : ils sont soutenus par des petits groupes (des collègues d'une société, souvent) qui deviennent des communautés actives. Les initiatives individuelles (qui ont vocation à le rester) sont inutiles, inefficaces.
Une fois le retard rattrapé dans la techno, il suffit de 10 minutes de veille par semaine (ou plus si on est curieux) pour se tenir à jour.
Quant à GitHub (ou une alternative self-hosted) et le versionnement, c'est très utile pour ne pas perdre ton travail (avoir un dépôt local c'est bien, une sauvegarde ailleurs c'est mieux) et pour lui créer un historique. C'est également génial pour pouvoir faire du réfactoring sans crainte (on peut revenir en arrière), pour trouver quand a été introduit un bug (via git bisect) ou déployer du code (ceux qui font du drag and drop dans un client FTP ne sont pas sérieux).
Ah oui : le développement local est une chose, la mise en production une autre. Comment vas-tu synchroniser le schéma de tes based de données locale et de production (et les transformation de leur contenu parfois) ? Les frameworks proposent un système appelé migrations pour ça. Comment vas-tu proposer des CSS et Javascript compactés en un fichier et minifiés (tout en les ayant normaux et lisibles quand tu développes et debug) ? Les frameworks répondent a ça aussi, avec expiration automatique des caches chez les utilisateurs. Et j'ai plein d'autres exemples.
@ Max : ça représente du boulot de se mettre a niveau parce que tu n'as pas appris dans de bonnes conditions ; Simplement parce que ces bonnes conditions n'existaient pas quand tu (c'est un tu de généralité) as appris PHP "from scratch" : il n'y avait pas ou peu de frameworks, pas de design pattern, un modèle objet balbutiant (PHP 4 c'est déjà le moyen âge), bref : c'était un milieu amateur.
Maintenant la technologie PHP s'industrialise et c'est très bien (moi je m'en fous j'ai changé de crèmerie, mais je sais quand même que c'est une bonne chose). Ca permet d'utiliser facilement des libs écrites par d'autres sans galèrer a les intégrer dans son projet (pour charger les bons fichiers), ni à les installer en dezipant une archive (bonjour la corvée de mettre à jour les versions, vive le gestionnaire de paquet et l'écriture d'une liste des dépendances qui permet de voir d'un coup d'œil ce qu'on utilise).
Tu crois que Composer alourdit ton processus de developpement mais tu te trompes. Il l'accélére considérablement. Pas besoin de te connecter à un quelconque site, puis télécharger, puis desarchiver pour mettre à jour une dépendance (ou même pour savoir que tu n'es plus a jour), une petite ligne de commande suffit.
Idem pour les frameworks, tu crois gagner du temps a t'en faire un minimaliste (pour t'economiser un temps d'apprentissage ? Mais tu le perds 100 fois en redéveloppant-en-moins-bien) mais tu te trompes probablement. Quand une des fonctionnalités de ton framework (qui aura été copié/collé d'une app a l'autre) présentera des défauts (bugs, failles, etc.) tu devras maintenir chaque app séparément. Toutes les fonctionnalités recurrentes d'une app sont les mêmes pour beaucoup (quels que soient tes besoins, d'autres ont eu les mêmes), et de très bons développeurs ont déjà repondu au besoin avec une bonne vision d'ensemble.
Même de vieilles technologies comme Java on parfois un apport de sang neuf (avec des frameworks comme Play!) : ils sont soutenus par des petits groupes (des collègues d'une société, souvent) qui deviennent des communautés actives. Les initiatives individuelles (qui ont vocation à le rester) sont inutiles, inefficaces.
Une fois le retard rattrapé dans la techno, il suffit de 10 minutes de veille par semaine (ou plus si on est curieux) pour se tenir à jour.
Quant à GitHub (ou une alternative self-hosted) et le versionnement, c'est très utile pour ne pas perdre ton travail (avoir un dépôt local c'est bien, une sauvegarde ailleurs c'est mieux) et pour lui créer un historique. C'est également génial pour pouvoir faire du réfactoring sans crainte (on peut revenir en arrière), pour trouver quand a été introduit un bug (via git bisect) ou déployer du code (ceux qui font du drag and drop dans un client FTP ne sont pas sérieux).
Ah oui : le développement local est une chose, la mise en production une autre. Comment vas-tu synchroniser le schéma de tes based de données locale et de production (et les transformation de leur contenu parfois) ? Les frameworks proposent un système appelé migrations pour ça. Comment vas-tu proposer des CSS et Javascript compactés en un fichier et minifiés (tout en les ayant normaux et lisibles quand tu développes et debug) ? Les frameworks répondent a ça aussi, avec expiration automatique des caches chez les utilisateurs. Et j'ai plein d'autres exemples.