non, on ne developpe pas une appli pour une config donnée, dans un environnement donné, rêgle général.
Car l'appli evolue. Les besoins évoluent. Aujourd'hui c'est du mysql parce que tu sais que tu aura peu d'utilisateur ou peu d'éxigences. Mais plus tard ? Qui sait si ton site ou ton appli ne connaitra pas un boom ? un succés ? Des demandes d'évolutions importantes ? Et donc changer de base, de config php et autre ? Peut être voudras tu la plugger plus tard sur des services web ou autres ? Donc réutiliser tes objets métiers, ou d'autres parties de l'appli pour d'autres besoins ?
Les objets, la modularité, c'est pas pour se la jouer. C'est pour anticiper sur les évolutions. Èviter de tous réécrire à chaque évolution. Découper pour réaliser plus facilement des tests unitaires (trés important dés qu'une appli devient complexe, pour vérifier qu'il n'y a pas de régressions). Découper pour ne pas avoir à tout modifier. Utiliser des templates par exemple (qu'elles soient en php ou non), c'est un premier découpage. Séparer le code métier du code coordination( en utilisant mvc par ex) en est un autre.
Une appli, surtout complexe, c'est pas du jetable. Faut essayer d'anticiper les évolutions, éviter d'avoir à tout réécrire, parce que ça coute cher. Le seul truc qui fonctionne sur le moyen et long terme, c'est de programmer un minimum modulaire (sans tomber dans l'ultra modulaire, il faut modulariser en fonction de la complexité de l'appli, et de son temps de vie).
je dis pas ça par ce que ça fait "in", mais bien parce que c'est ce que j'ai effectivement remarqué dans tous les developpements professionels que j'ai effectué depuis plusieurs années. Y a qu'à voir le succés et le nombre de nouveau framework ces derniers mois.
[^] # Re: Curiosité...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Offre d'emploi Développeur Web (Paris). Évalué à 2.
Car l'appli evolue. Les besoins évoluent. Aujourd'hui c'est du mysql parce que tu sais que tu aura peu d'utilisateur ou peu d'éxigences. Mais plus tard ? Qui sait si ton site ou ton appli ne connaitra pas un boom ? un succés ? Des demandes d'évolutions importantes ? Et donc changer de base, de config php et autre ? Peut être voudras tu la plugger plus tard sur des services web ou autres ? Donc réutiliser tes objets métiers, ou d'autres parties de l'appli pour d'autres besoins ?
Les objets, la modularité, c'est pas pour se la jouer. C'est pour anticiper sur les évolutions. Èviter de tous réécrire à chaque évolution. Découper pour réaliser plus facilement des tests unitaires (trés important dés qu'une appli devient complexe, pour vérifier qu'il n'y a pas de régressions). Découper pour ne pas avoir à tout modifier. Utiliser des templates par exemple (qu'elles soient en php ou non), c'est un premier découpage. Séparer le code métier du code coordination( en utilisant mvc par ex) en est un autre.
Une appli, surtout complexe, c'est pas du jetable. Faut essayer d'anticiper les évolutions, éviter d'avoir à tout réécrire, parce que ça coute cher. Le seul truc qui fonctionne sur le moyen et long terme, c'est de programmer un minimum modulaire (sans tomber dans l'ultra modulaire, il faut modulariser en fonction de la complexité de l'appli, et de son temps de vie).
je dis pas ça par ce que ça fait "in", mais bien parce que c'est ce que j'ai effectivement remarqué dans tous les developpements professionels que j'ai effectué depuis plusieurs années. Y a qu'à voir le succés et le nombre de nouveau framework ces derniers mois.
PS: je ne travaille pas dans la boite de mat...