La peur de la maintenance

[Xenos]

J'isole cette discussion du topic sur le C#

Je dérive peut-être un peu de ton idée originale, Vincent (j'ai l'impression de me parler à moi-même là...!), mais si l'OO, MVC et autres frameworks/méthodes sont intéressants à connaître, il n'en reste pas moins que la règle de base de tout procédé industriel est Make it work. Le fait de "coder propre" n'est que le second point de la doctrine ("Make it work, Make it right, Make it fast").


Certes, coder propre, dans le temps, cela aide, mais il faut aussi faire gaffe car beaucoup, mais vraiment beaucoup, de projets ici (dans le monde amateurs) se cassent les dents sur la recherche vaine de la perfection: la perfection n’existe pas, et si le créateur de projet veut un démarrage parfait, alors son projet ne démarre pas.

Ter-Rowan avait soulevé ce point déjà dans la question du " Le projet codé selon les règles de l'art... ou pas" [J'ai mal interprété alors, désolé]. Le jeu web, c'est avant tout le jeu en lui-même, ses règles, son background, son contenu. Osef un peu que ce soit OO, pas OO, MVC, codé avec les pieds ou autre. Et finalement, les projets qui ont été présentés ici sont bien plus souvent codés avec les pieds que des codes parfaits appliquant strictement les doctrines du moment (qui auront bougées avant que tu n'ai fini ton projet parfait).

Au fond, ce n'est pas sans raison que les projets industriels sont eux-même loin d'être parfaits: y'a un impératif de réalisation qui doit être respecté, et on se retrouve donc avec une balance en équilibre en "sortir un truc, même pas parfait" et "ne rien sortir, au moins, le rien est parfait".


J'ai formalisé un peu tout cela en article, pour le coup: https://toile.reinom.com/la-maintenance/ (je le paraphrase un peu ici mais bon).

[Ter Rowan]

Ter-Rowan avait soulevé ce point déjà dans la question du " Le projet codé selon les règles de l'art... ou pas".

non non, enfin pas là

dans tous les cas ma position :

soit on développe un jeu pour voir aboutir le jeu (et osef qualité du code)
soit on développe un jeu qui doit durer dans le temps (et faut essayer de le rendre maintenable par soit même)
soit on développe un jeu pour maitriser le langage (et là, focus qualité du code plutôt que le résultat final)


cependant je pense que d'un point de vue industriel il faut rendre le code le plus propre et maintenable possible. (et je bosse la dedans en tant que chef, j y connais rien en technique)

mais maintenable ne veut pas forcément dire le plus intellectuel, intelligent, ... il faut que ce soit ABORDABLE par le couillon (a peine compétent ou normalement compétent mais pas le petit génie) qui aura la charge de la maintenance

[Prélude]

Pour avoir bossé pendant une dizaine d'années dans une agence web en tant que DT, je dirais que je n'ai jamais vu un projet que l'on pouvait reprendre et améliorer 2 ans après son lancement. Une raison à cela : la technologie évolue, nos connaissances avec et on ne développe pas de la même façon 2 ans après (enfin, c'est souhaitable).
Par contre, maintenir un code propre et bien commenté (surtout bien commenté !), alors là, oui, c'est utile.
Mes projets, je les ai lancés en me fixant un calendrier auquel je me tenais. Quitte à faire un peu moins de fonctionnalités que prévu et les faire par la suite. Si le code n'était pas bien bien commenté, impossible pour moi de revenir sur une fonction 2 mois après l'avoir fait. Et le projet aurait été par terre.
On a toujours la possibilité de refaire une fonction qui n'est pas top au niveau du code une fois que le projet est lancé.
Pour un jeu, il est toujours possible de refaire l'intégralité du jeu si celui-ci fonctionne vraiment bien (on embauche). On lance une v2 et tout le monde est heureux. Mieux qu'une v1.x avec plein de rustines et un machin qui ne peut plus être maintenu car trop de codes différents.

[Xenos]

Oui, je rejoins vos deux points de vue, dans le sens où Make it work seul ne suffit pas. Mais Make it right, Make it work, je ne l'ai jamais vu marcher (ça a toujours fini en projets englués qui n'avancent pas, type "0 issue Sonar, 0 faille de sécu, 100% de code coverage, du commentaire partout... pour afficher juste un "Hello World!").

Après, pour le coup de "on repart de zéro pour coder la V2", mouais... j'hésite. C'est sûr qu'il y a des cas où c'est le seul moyen (genre Eclerd) mais quand cette situation arrive, c'est qu'on a zappé le "Make it right" (on a fait du Make it work, make it work!).

[Vincent G]

En fait ça reste plus une question de fond que de forme.

Avoir quelques potes pour y jouer le samedi soir ? Ou plutôt avoir des centaines de joueurs actifs tous les jours. Pour la première question, c'est sur que ce n'est peut être pas intéressant de partir sur des technos qu'on ne maîtrise pas ou très peu. Pour la seconde question, c'est sur que privilégier une techno qui est facilement maintenable sera un plus pour les updates.

Maintenant personnellement, je préfère m'orienter vers des choses nouvelles à chaque projet car même s'il s'agit d'un échec, le savoir acquis ne le sera pas.

D'ailleurs on a des stats de projets terminés / abandonnés par technos ?

[Xenos]

Perso, je pense que les jeux amateurs qui ont des centaines de joueurs actifs tous les jours ont commencé avec "quelques potes le samedi soir", ce qui fait un passage quasi-obligé. Ceux qui entament direct par des centaines de joueurs actifs sont en fait les "vrais" projets pros, montés avec 2 ou 3 porteurs de projets entourés d'une équipe, qui ont fait une levée de fond et tout le bazar (et qui, de toute façon, ont probablement démarré par un prototype sale et rapide pour avoir les "beaux pixels" à montrer pour attirer du monde).

Si tu veux les stats, tu peux aller gratter la section des "projets" de JeuWeb. J'y avais fait du tri, donc les projet en dev/en ligne/abandonnés le sont vraiment. Il ne te reste plus "qu'à" rechercher par techno pour faire des stats