Bon bon bon, ça devient de l'attaque un peu gratuite. Je me fais moinser sur mes messages et tu te fais plusser sur les tiens, donc j'ai tendance à croire que quoi je dise, je vais passer soit pour un méchant, soit pour un imbécile, soit pour un incapable :-/
Faut s'en foutre des cliques ça fait juste parti du folklore local.
Selon mon expérience, plus tu rajoutes d'intermédiaires, de fonctions qui appellent des classes, elles mêmes dérivées de plusieurs classes, etc.... plus ça devient compliqué à maintenir. Maintenir = corriger un bug. Maintenir != faire évoluer.
En fait c'est plus de la structuration de code. Si tu sais que pour tout ce qui touche à la base de données il faut aller toucher à l'objet DAO c'est nettement plus simple que d'aller voir avec grep toutes les utilisations de l'API SQL. Si en plus on a un moteur de template qui ne s'occupe que de la présentation des données et qui ne s'intéresse pas de savoir ce qu'elles représentent ni comment elles doivent être modifiées, alors tu as une application 3 tiers. C'est pas ajouter des milliards d'indiréctions, c'est juste avoir structuré son application de manière cohérente. Le sur-coût existe (on a plus de classes/objets, on appel des fonctions), mais à coté de ça l'application est nettement plus maintenable. Ça simplifie le travail collaboratif car chaque contributeur travailleras sur un sous ensemble du code qui s'utilisent entre elles avec le principe des boites noires.
J'ai travaillé avec des développeurs qui se prenaient la tête à prévoir que peut-être un jour on voudra faire ceci ou cela avec le code et donc il fallait le prévoir dans l'architecture. Moi je dis stop. Soit on en a besoin tout de suite, soit on ne le prévoit pas et on reste simple dans son architecture. Code simple = code facile à maintenir. C'est d'autant plus important dans un projet libre et ouvert comme Piwigo que le développeur d'une fonctionnalité ne va pas forcément être celui qui va y corriger un bug 3 ans plus tard.
Tu as raison l'un des grands principes de scrum est de ne pas hésiter à réécrire pendant chaque sprint. Cela n'empêche pas d'avoir une structuration de son code pour simplifier son développement (et simplifier les tests lorsque l'on fait des tests unitaires).
Quant à la capacité d'étendre Piwigo, je parle des thèmes et des plugins. Il y a plus de 200 plugins et plus de 100 thèmes. Pour un CMS "spécifique", c'est plutôt pas mal.
C'est même très bien. Prévoir la possibilité de créer des thèmes et celle d'avoir des plugins est un travail très complexes.
"Changer de SGBD" n'est en aucun cas un besoin récurrent. Et la problématique n'est pas de changer, mais d'être compatible multi-SGBD, ce qui n'est pas du tout la même chose. Si un jour on passe en MariaDB, ce sera bien plus simple que d'être compatible PostgreSQL/SQLite/Firebird/FuturSGBDopensourceAlamode.
Une méthode consiste à utiliser un paterne DAO. Pour chaque moteur, on hérite du DAO_MySQL et on réécris les méthodes qui en ont besoin. Ça ne me semble pas très couteux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par barmic . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 7.
Faut s'en foutre des cliques ça fait juste parti du folklore local.
En fait c'est plus de la structuration de code. Si tu sais que pour tout ce qui touche à la base de données il faut aller toucher à l'objet DAO c'est nettement plus simple que d'aller voir avec grep toutes les utilisations de l'API SQL. Si en plus on a un moteur de template qui ne s'occupe que de la présentation des données et qui ne s'intéresse pas de savoir ce qu'elles représentent ni comment elles doivent être modifiées, alors tu as une application 3 tiers. C'est pas ajouter des milliards d'indiréctions, c'est juste avoir structuré son application de manière cohérente. Le sur-coût existe (on a plus de classes/objets, on appel des fonctions), mais à coté de ça l'application est nettement plus maintenable. Ça simplifie le travail collaboratif car chaque contributeur travailleras sur un sous ensemble du code qui s'utilisent entre elles avec le principe des boites noires.
Tu as raison l'un des grands principes de scrum est de ne pas hésiter à réécrire pendant chaque sprint. Cela n'empêche pas d'avoir une structuration de son code pour simplifier son développement (et simplifier les tests lorsque l'on fait des tests unitaires).
C'est même très bien. Prévoir la possibilité de créer des thèmes et celle d'avoir des plugins est un travail très complexes.
Une méthode consiste à utiliser un paterne DAO. Pour chaque moteur, on hérite du DAO_MySQL et on réécris les méthodes qui en ont besoin. Ça ne me semble pas très couteux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)