Discussion :

[NBoulfroy]

Bonjour à tous,

Je me permets de de venir à vous pour vous demander un avis sur une question qui me taraude.

Jeune développeur backend faisant sa bosse sur Symfony et utilisant, à tord à et travers car on me l'impose au travail, Doctrine, je désirai savoir une chose : partisan sans faille de la méthode MERISE (MCD & MLD) et préférant l'optimisation de la base de données avant l'optimisation de l'application (partie base de données), je me bats pour qu'on utilise cette méthode au travail avant pour dans le cadre de la problématique d'une bonne analyse et conception.

Malheureusement, le lead developer de l'entreprise où je suis estime que c'est la vision objet qui prime alors que, durant mes années d'étude (dont une avec des professionnels uniquement), on nous a clairement expliqué que si une application à une base de données, elle prime et doit être réalisée avant la vision applicative.

Qu'en pensez-vous ?

[Tsilefy]

À partir du moment où on utilise Doctrine ORM (je précise bien ORM), on sacrifie déjà l'optimisation de la BDD au profit de la rapidité et la simplicité de développement.

La vraie question est quelle est la priorité? Le plus souvent, la priorité est d'obtenir très vite un "truc qui marche", çad un MVP, puis de faire des multiples itérations après. Les objets peuvent donc constamment changer au cours du refactoring, et dépenser du temps pour une conception parfaite de la BDD est une perte, puisque les schémas évoluent très vite. Et souvent au début de la vie de l'application, l'optimisation (ou même le type) de BDD n'est pas important. Dans ces cas, Doctrine ORM (ou n'importe quel autre ORM) aide énormément.

Il est donc dans ce cas préférable d'optimiser la BDD plus tard, lorsque le codebase de l'application est stable et lorsqu'on voit que la BDD est le goulot d'étranglement de l'application (soit en termes d'utilisation, soit en terme de développement).

Maintenant, si on a un temps infini, les choses peuvent être différentes.

[NBoulfroy]

Je comprends mieux certaines choses de ce fait mais j'avoue que, si le cahier des charges est bien fait et que le client a bien spécifié ses désirs en plus d'avoir un responsable métier présent dans le processus de développement, l'analyse et conception, base de données comme couche applicative, ne doivent, en théorie, que très peu changer de par le fait que de par ces éléments, nous obtenions un résultat concret et qui bougera très peu.

Après, si la question aujourd'hui est de produire un code dégueulasse, non standard, impossible ou difficile à maintenir mais en plus truffé d’ineptie, je ne vois alors pas l'intérêt d'entretenir dans certaines formations comme le BTS SIO (dont je suis un ancien étudiant) et la licence professionnelle que j'ai réalisé les principes de développement et d'analyse et conception si tout le monde s'en fou.

Je sais pertinemment que c'est un débat sans fin mais j'avoue que l'avis d'autres personnes m'aideraient car j'ai du mal à me rendre compte.

[Tsilefy]

si le cahier des charges est bien fait et que le client a bien spécifié ses désirs

Dans le web, que ce soit des sites, des API ou des apps, j'ai bien peur que ça soit une chose rare, à moins qu'on parle de site vitrine. Ce n'est pas forcément que le client ait mal défini ses besoins (même si ça arrive), mais les choses évoluent si vite que les besoins, les technologies et les usages changent.

Le Waterfall marche peut-être pour des gros projets enterprise (ERP etc...) où le domain est connu et maîtrisé, rien ne changera dans les mois et années à venir, et tout est planifiable. Dans le web, c'est agile et itérations.

Il n'est absolument pas question de maintenir du code déguelasse, je ne sais pas où tu travailles mais ce n'est pas du tout ça. L'objectif c'est d'avoir un code suffisamment robuste pour pouvoir éliminer des fonctionnalités lorsqu'on se rend compte que personne ne les utilise, et d'en ajouter des nouvelles qui correspondent à un besoin. Cela suppose de préserver une certaine flexibilité du schéma de la BDD, et c'est entre autres ce qui a poussé beaucoup de start-ups à utiliser des NoSQL qui accordent une très grande liberté (au détriment de l'ACIDité). Bref, la BDD n'est pas vraiment la première priorité dans ce cas.

un résultat concret et qui bougera très peu.

Le problème est que ce résultat bougera, et il doit bouger! Contrairement à un logiciel où tu peux sortir une version tous les 2-3 ans, une application web (ou une API, ou une appli mobile) vit et change constamment, sauf si elle est vraiment très basique.

[grunk]

si le cahier des charges est bien fait et que le client a bien spécifié ses désirs

Ahhhh la douce innocence du tout jeune développeur
Quand déjà le cahier des charges existe tu peux t'estimer heureux , alors qu'il soit bien fait c'est juste une utopie.
Ah oui et le client qui spécifie ses désir et qui s'y tient c'est pareil ca n'existe pas.

Après, si la question aujourd'hui est de produire un code dégueulasse, non standard, impossible ou difficile à maintenir mais en plus truffé d’ineptie, je ne vois alors pas l'intérêt d'entretenir dans certaines formations comme le BTS SIO (dont je suis un ancien étudiant) et la licence professionnelle que j'ai réalisé les principes de développement et d'analyse et conception si tout le monde s'en fou.

Comme le dit Tsilefy à part a travailler dans l'open source ce qui prime c'est les délais et donc le coût. Et donc inévitablement il arrive qu'on fasse les choses pas dans les règles de l'art pour ces raisons. Il faut essayer tant que possible de le limiter mais ça arrive.

on nous a clairement expliqué que si une application à une base de données, elle prime et doit être réalisée avant la vision applicative

Je dirais que ça dépend de la situation.
La base de données est elle là pour servir l'applicatif ? Du genre gestion d'utilisateur, de droit , etc ... Dans ce cas il est évident qu'il faut penser la base pour le code. Et les optimisation de la bdd sont secondaire.
Ou alors la base de données est le coeur du projet , par exemple un ERP. Toutes les données et tous le métier repose sur cette base => dans ce cas là on va plutôt adapter l'applicatif à la base et effectivement dans ce cas les optimisation de bdd on du sens.

Les optimisations de bdd c'est comme le code , faut que ce soit significatif. Refactorer une bdd pour gagner 3ms sur une requête c'est du vent. Par contre si je peux gagner quelques Go d'espace ou quelques minutes sur une requêtes , là oui ça vaut le coup.