Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Êtes-vous pour la réécriture d'un projet de zéro ou le refactoring de code ?
Remesh a opté pour la première façon de faire et partage son expérience

Le , par Stéphane le calme

106PARTAGES

14  0 
Quelle stratégie préférez-vous adopter ?
Lorsqu’il faut aborder de nouveaux projets, deux écoles s’affrontent chez les développeurs : certains préfèrent exploiter un code existant et l’adapter à de nouvelles fonctionnalités, tandis que d’autres préfèrent partir de rien bien qu’il y ait un code existant.

Joel Spolsky, un développeur et écrivain américain, fait partie de la première école. Pour lui, écrire un programme à partir de zéro est la pire erreur stratégique qu'un développeur puisse commettre. Dans un billet, il a énuméré plusieurs cas pour mieux se faire comprendre entre autres, le navigateur de Netscape qui n'existe plus aujourd'hui. Netscape 6.0 allait entrer dans sa première version bêta publique à l'époque en sautant la version 5.0. La version 4.0 fut sa dernière version majeure et avait été publiée trois ans plus tôt. Trois ans, c'est terriblement long dans le monde de l'Internet, déclarait Joel : « Pendant ce temps, Netscape était assis, impuissant, alors que sa part de marché s'effondrait », ajoutait-il. La cause, selon Joel, est que ses développeurs ont décidé de réécrire la base de code à partir de zéro.

Vingt ans plus tard, Nicholas Tietz-Sokolsky a publié un billet sur le blog d’ingénierie de Remesh où il vient remettre en cause cette philosophie ne serait-ce que par l’expérience même de Remesh :

« Notre histoire commence en janvier 2019. Remesh était alors une entreprise beaucoup plus petite. Nous avions récemment embauché quelques ingénieurs et nous avions 5 ingénieurs focalisés sur le produit, et une poignée d'ingénieurs focalisés sur l'apprentissage automatique (ML) ou DevOps. Malgré l'embauche récente de ces ingénieurs, notre vitesse était toujours douloureusement basse. L'ajout de fonctionnalités simples a pris du temps. Nous avons eu beaucoup de bogues dans le produit que nous avons simplement reconnu comme étant ‘connus’ et que nous n'avons pas corrigés. Et le produit dans son ensemble semblait n'avoir pas changé de manière significative depuis un certain temps.

« Il est important de comprendre pourquoi nous avons eu ces problèmes. Nous avons supposé (et après la réécriture, validé) que le problème ne venait pas de notre côté : après tout, nous avions embauché des ingénieurs talentueux. Le problème venait en grande partie notre base de code et notre processus. La base de code héritée dans laquelle nous travaillions n'était pas adaptée à la fois aux compétences de notre équipe et aux problèmes que nous résolvions, et notre processus encourageait et s'appuyait sur des connaissances cloisonnées: il n'y avait pas de ‘stack full’ à Remesh ».

L'état de la base de code de Remesh en janvier 2019

L’ancienne application de Remesh a été conçue à l'origine pour quelque chose de très différent de ce à quoi elle sert actuellement. Au départ, Remesh permettait aux utilisateurs de tenir des conversations bidirectionnelles entre des groupes entiers ou un individu et un groupe. Nicholas a illustré le premier cas d’utilisation (conversations bidirectionnelles entre groupes) en parlant des démocrates et des républicains qui se parlent pour trouver un terrain d’entente, le second (conversations bidirectionnelles entre des groupes et un individu) en parlant du maire d’une ville qui s’adresse à ses citoyens pour mieux comprendre leurs besoins.

« Cependant, comme nous avons trouvé l'adéquation au marché des produits, le cas d'utilisation a changé. Nous nous sommes penchés sur un modérateur singulier parlant à un groupe de personnes », a-t-il noté.

À la suite de ce changement, certaines anciennes décisions de conception n'avaient plus de sens et le schéma nécessitait des changements majeurs. Au-delà des problèmes de base de données, il reconnait que la base de code elle-même était assez difficile à comprendre, car les fonctionnalités avaient été boulonnées sans beaucoup de refactoring majeur : « nous avions une couverture de test très médiocre dans les zones qui avaient le plus besoin de refactoring car il s'agissait du code le plus ancien, écrit avant d'établir de bonnes pratiques de test ».

Au-delà de tout cela, les langages et frameworks utilisés ne marchaient pas avec leur équipe. La base de code backend a été écrite dans Elixir, que peu de leurs développeurs connaissaient très bien. L'une des bases de code frontend a été écrite dans une version très ancienne d'Angular et ils avaient deux autres frontend qui étaient en React : « peu de nos ingénieurs étaient à l'aise sur l’un d’eux, sans parler des trois. Les langages et les frameworks utilisés ne convenaient ni à notre équipe ni à notre problème, ce qui nous a un peu ralentis ».


Quelles étaient les options ?

À ce stade, Remesh a réalisé que sa base de code avait besoin d'un changement majeur. Dans ce cas de figure, trois options se posent à vous :
  • Le refactoriser jusqu'à ce que le problème soit résolu
  • Le réécrire d'une traite
  • Le réécrire au coup par coup

« Pour le frontend, le refactoring n'était pas vraiment une option. Notre version d'Angular était suffisamment ancienne pour que, malheureusement, nous n'ayons pas vraiment de chemin de mise à niveau clair vers une version moderne d'Angular (de toute façon nous ne voulions pas être sur une version d'Angular). Et puisque nous anticipions des changements majeurs dans l'interface utilisateur et l'API, un refactoring ne serait pas réalisable. Donc, sur le frontend, nous devions décider entre réécrire d'un seul coup ou réécrire au coup par coup.

« Le back-end avait quelques problèmes que nous voulions résoudre - notre schéma, notre langage et notre base de code ne correspondaient plus au problème que nous résolvions. Nous avons utilisé Elixir pour son support massif de concurrence, pourtant nous n'en avons jamais eu besoin et cela a fini par nous porter préjudice : la façon dont la concurrence est gérée dans la machine virtuelle Erlang a rendu le profilage très difficile, car vous savez ce qui est calculé, mais pas d'où il est appelé - et bonne chance avec le réglage des performances. La base de code Elixir a également limité la contribution de nos ingénieurs ML à la base de code backend : ils travaillaient en Python tous les jours et n'avaient pas le temps de se plonger profondément dans Elixir. Pour faire court, nous voulions quitter Elixir et passer à Python, car alors toute notre équipe aurait pu contribuer, le langage prendrait en charge les problèmes et nous aurions plus de facilité à profiler le code ».

Au bout du compte, l’argument en faveur de la réécriture se résumait vraiment à cette confluence de facteurs :
  • Remesh voulait que chaque membre de son équipe puisse contribuer à la base de code backend, et Python avait l’avantage d'avoir déjà une large adoption déjà au sein de l’équipe et d’être facile à apprendre
  • L’ancienne base de code était si fragile et si peu testée que sa refactorisation serait un processus ardu.
  • Remesh pouvait gagner en efficacité en passant à un framework « opinionated » comme Django, avec beaucoup de valeurs par défaut permettant de gagner du temps (comme Django Admin).
  • Remesh voulait avoir l'opportunité de créer une toute nouvelle version influencée par ce que l’entreprise avait appris des clients et pourrait ensuite gérer la transition vers la nouvelle version plutôt que de mener une bataille pendant 12 mois avec beaucoup de clients à chaque changement.

« Pour arriver à cette décision, nous avons fait une planification assez approfondie », indique Nicholas qui note que l’équipe devait impérativement déterminer quel serait le niveau d'effort pour chacune de ces options. « Il est apparu assez rapidement que la réécriture de l'application en gros prendrait du temps, mais que sa refactorisation ou sa réécriture fragmentaire prendrait beaucoup plus de temps, il y avait beaucoup, beaucoup plus d'incertitude autour d'une telle approche. Si nous options pour la refactorisation, nous risquerions beaucoup plus ».

Autant d’éléments qui les ont conduits à tout réécrire : « nous étions déterminés à réécrire, car cela nous permettrait de corriger les erreurs des années passées, et cela nous permettrait de faire avancer le produit en même temps ».

Remesh a donc commencé à tout réécrire à partir de février 2019 « après avoir planifié les fonctionnalités que nous devrions inclure pour la parité des fonctionnalités avec la plateforme existante dans le cadre d'un effort de diligence raisonnable pour nous assurer que c'était la bonne voie ».

« Le processus réel de construction de la nouvelle version s'est déroulé sans heurts après un démarrage cahoteux. C'était douloureux pour tout le monde de passer à une nouvelle pile technologique. Bien que nous ayons choisi Python pour l'accessibilité de toute l'équipe, il y avait encore ceux parmi nous qui avaient besoin de l'apprendre. Et aucun de nos ingénieurs backend ou fullstack ne connaissait Django au départ (alors que notre ingénieur frontend principal le connaissait bien). De même sur le frontend, beaucoup d'entre nous connaissaient React, mais peu d'entre nous avaient une expérience approfondie avec TypeScript, vers lequel nous avons également choisi de migrer. Cela dit, après avoir eu un temps d'apprentissage initial, nous sommes tous devenus assez productifs assez rapidement et nous avons pu apprendre ensemble. Ce fut notre première validation : même avec moins d'expérience dans cette nouvelle pile, nous avons pu créer des fonctionnalités beaucoup plus rapidement. Il faudrait plus de temps pour s’assurer que les gains de productivité provenaient de la nouvelle pile et de la nouvelle base de code, plutôt que du fait que le projet soit entièrement nouveau, néanmoins nous y sommes finalement arrivés ».

Les leçons tirées de cette expérience

Après cette expérience, il a noté des leçons qu’ils ont tirées de leurs échecs pendant le processus, mais aussi de leurs succès :

« Nous avons réussi parce que nous avons commencé avec une vision claire de ce que nous construisions (un vrai MVP, où nous savions que l'ancien produit était «viable»), et nous y avons réduit la portée selon nos besoins afin de rester avec une vision claire. Bien que nous n'ayons pas livré « dans les temps » (d’ailleurs personne ne le fait), nous n’avons pas pris autant de temps que Netscape. La durée totale du projet était inférieure de deux fois au temps que nous avions prévu si nous avions fait une copie exacte (en termes de fonctionnalités) de l'ancien produit, mais nous nous sommes retrouvés avec quelque chose de bien meilleur et avec de nouvelles fonctionnalités très souhaitées, comme la possibilité de télécharger et d'envoyer des vidéos et la possibilité de télécharger un rapport PowerPoint généré automatiquement de votre conversation.

« L'une des autres clés de notre succès a été d'obtenir des commentaires tôt et souvent. Pendant la réécriture, nous avons utilisé le produit en interne très souvent, découvrant des bogues critiques et des problèmes de performances. Nous avons également organisé des démonstrations régulières pour l'ensemble de l'entreprise afin d'obtenir rapidement des commentaires du service customer success, ventes, recherche et éventuellement des premiers clients qui pouvaient tolérer les échecs.

Il a reconnu qu’ils se sont trompés parce qu’ils ont décidé de s’appuyer sur deux technologies que l’équipe n’avait pas beaucoup utilisées beaucoup : « nous avions déjà utilisé TypeScript dans un prototype, mais nous n'avions pas de connaissances approfondies à ce sujet. Tout s'est bien passé, mais nous ne sommes toujours pas convaincus que la productivité est plus élevée et le taux de défauts est plus faible; le temps nous le dira, et je pense que le jury est toujours sur le typage statique ».

L'autre erreur était d'utiliser GraphQL. « Nous avions des niveaux d'expérience assez élevés avec REST et Redux, mais nous n'avions auparavant utilisé GraphQL que dans un prototype. Rétrospectivement, GraphQL a rendu le prototypage initial beaucoup plus rapide, mais à long terme, car il y a des décisions de conception critiques dans Apollo avec lesquelles nous ne sommes pas d'accord (comme ne pas exposer la capacité de détecter les déconnexions / reconnexions dans les abonnements sur le frontend) et notre expérience de la mise au point des performances sur le backend était ... disons simplement que ce fut un mois ou deux difficile de ma vie que j’espère ne plus revivre ». L’équipe est en train de se séparer progressivement de GraphQL.

Réécrire ou ne pas réécrire ?

« Sur la base de mon expérience ici, vous ne devriez probablement pas le faire si vous croyez dans le battage médiatique indiquant que la réécriture n'est jamais la bonne décision. Dans tous les cas, vous devez par défaut choisir la position ‘non’, puis travailler très dur pour la justifier si nécessaire. Voici quelques scénarios où une réécriture pourrait être justifiée :
  • Si votre architecture ou schéma est très loin de s’aligner avec ce dont vous avez besoin et qu'il n'y a pas de chemin de migration clair, car la mise à jour incrémentielle de l'architecture ou des schémas serait extrêmement difficile
  • Si ces problèmes ralentissent considérablement votre équipe
  • Si votre pile technologique actuelle empêche de nombreux ingénieurs de contribuer et les former à la pile technologique n'est pas une option.

« Même si vous cochez toutes ces cases, vous devez tenir compte des réalités commerciales et savoir si cela a du sens pour votre entreprise, votre équipe. Il peut y avoir plus de scénarios où une réécriture est justifiée. Il est difficile de le justifier, mais cela en vaut la peine et peut être couronné de succès ».

En définitive, une réécriture de code vous donne l'avantage de l'expérience : vous connaissez les faiblesses de l'ancien système, les défauts de conception, les exigences actuelles et la future feuille de route. Vous pouvez faire des planifications et concevoir un système qui surmontera les problèmes que vous avez anticipés. L'inconvénient est que vous devez maintenir deux systèmes pendant que vous écrivez le nouveau.

En revanche, le refactoring vous permet de remplacer lentement les anciens morceaux de code de votre système par de nouveaux. Prenez une fonction, une classe ou un module, et vous le/la réécrivez dans le cadre de votre projet. Tous vos tests et intégrations sont là, il est facile de vérifier que vous n'avez rien cassé, pour vous assurer que la fonctionnalité reste la même. Mais vous ne pouvez pas faire des merveilles avec le refactoring de code, vous ne pouvez pas choisir un langage de programmation différent et la plupart du temps, vous ne pouvez même pas remplacer le framework principal de votre projet.

Source : Remesh

Et vous ?

Êtes-vous pour le refactoring de code ou la réécriture d'un projet de zéro ? Dans quelle mesure ?
Que pensez-vous du cas de Remesh ?
Avez-vous déjà été amené à réécrire un code de zéro ? Pouvez-vous partager votre expérience ?
Quels sont les éléments qui pourraient pousser une équipe à envisager de réécrire son code ?

Voir aussi :

L'Allemagne a proposé en open source tout le code de Corona-Warn-App, son application de contact tracing qui va lui coûter 3 millions d'euros tous les mois
L'équipe du projet OpenZFS retire « les références inutiles à l'esclavage » de sa base de code en mettant de côté le terme « slave » qui fait remonter une expérience humaine douloureuse au souvenir
L'équipe du langage Go retire les termes "whitelist", "blacklist", "master" et "slave" de sa documentation et de sa base de code parce qu'ils véhiculent des stéréotypes raciaux
A-t-on besoin d'apprendre la programmation pendant 10 ans avant d'être un développeur accompli ? Partagez votre expérience

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Astraya
Membre expérimenté https://www.developpez.com
Le 29/06/2020 à 8:45
C'est surtout une question de combien ça coûte. Le refactoring peut avoir tellement d'impacts que tout refaire reste moins cher ( je pense surtout au régression)
11  0 
Avatar de axel584
Membre habitué https://www.developpez.com
Le 29/06/2020 à 9:44
Le problème de la réécriture est qu'on perd souvent des fonctionnalités importantes pour les utilisateurs (et pas forcement très bien connu/documenté).
7  0 
Avatar de user056478426
Membre régulier https://www.developpez.com
Le 29/06/2020 à 10:41
Ma boite a opté pour la troisième option : ne rien faire
7  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 29/06/2020 à 8:12
Parfois, il est plus simple de tout re-écrire, que de modifier / déboguer.
7  1 
Avatar de Pierre Fauconnier
Responsable Office & Excel https://www.developpez.com
Le 29/06/2020 à 23:15
Ca me fait rire qu'on tape sur "le stagiaire"... Comme si il n'y avait que les stagiaires qui codaient mal...

Un stagiaire, on l'épaule, on le forme, on vérifie son code, bref, on lui apprend son futur boulot. Si le stagiaire a pissé 100000 lignes, c'est que le gars qui le supervisait n'a pas fait son boulot. Peut-être qu'il aurait pondu les mêmes 100000 lignes...

J'ai déjà dû me plonger dans du code "pissé" par un pro qui allait m'en apprendre, selon lui... J'ai refusé la mission de refactoring que l'on me proposait (lui n'avait "pas le temps" car il était appelé à de plus nobles fonctions) parce que cela sentait l'oignon. On est venu me rechercher, on a viré le spécialiste et je suis reparti de zéro...

Donc, j'ai voté "Ca dépend du code à adapter"...
6  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 30/06/2020 à 10:06
Citation Envoyé par Neckara Voir le message
Toi t'as jamais repris le code d'un stagiaire.

Tu lances, ça lance des erreurs, tu t'aperçois qu'il a tout codé ses chemins en dur, en chemin absolu... sauf que toi t'es pas sur son PC.

Il a géré 2 langues... c'est un même dossier copié/collé avec le texte modifié (avec tout le code). Le code dans un foutoir pas possible, plein de code morts / inutiles. Franchement, j'ai pas cherché plus loin, et j'ai bien été content de ma décision.
J'ai vu des gens avec 10 ans d'expérience ne pas coder aussi proprement que ça

Citation Envoyé par abriotde Voir le message
Le code d un stagiaire ne fait pas 100 000 lignes. Dans ce cas oui tu peux reprendre 1000 lignes. Mais parfois juste le modifier est plus simple.
Citation Envoyé par Neckara Voir le message
(.../...)si son code de 100 000 lignes pouvaient être fait en uniquement 1 000.... c'est une autre question... et la réponse est oui.
Il fut une époque ou les développeurs étaient payés à la ligne de code. C'est depuis longtemps révolu, mais certains n'ont toujours pas reçu le message. Ou ne comprennent rien à ce qu'ils font, et ne fonctionnent que par copier-coller.

Citation Envoyé par Pierre Fauconnier Voir le message
J'ai déjà dû me plonger dans du code "pissé" par un pro qui allait m'en apprendre, selon lui... J'ai refusé la mission de refactoring que l'on me proposait (lui n'avait "pas le temps" car il était appelé à de plus nobles fonctions) parce que cela sentait l'oignon. On est venu me rechercher, on a viré le spécialiste et je suis reparti de zéro...

Donc, j'ai voté "Ca dépend du code à adapter"...
Je suis d'accord avec la conclusion. Il faut analyser la situation, et choisir en fonction. Mais le code n'est pas le seul élément à prendre en compte. La qualité de la doc et des specs aussi. Je suppose que tu avais sous la main des gens qui savaient ce qu'il fallait faire. Je n'ai pas toujours eu ce confort.

Le pire code que j'ai eu à reprendre était un cas à part : il avait 36 ans d'âge, était du COBOL codé come si c'était de l'assembleur (alors que les bonnes pratiques de l'assembleur ne se prêtent pas du tout au COBOL), et surtout, il avait eu des centaines et des centaines de maintenances empilées. De la vraie archéologie logiciel. Le piège, c'est que les gens qui avaient écrit les spécifications étaient morts ou à la retraite, et qu'ils n'avaient laissé aucune trace écrite. La chaîne était une horreur à maintenir, mais tournait comme du papier à musique, et donnait entière satisfaction (à part de menus soucis de performances). Dans ces conditions précises, repartir de zéro était inconcevable - puisque la seul spec était le code existant. La seule page blanche, le module central qui pilotait tout ça, peut-être 4% de page blanche.

J'ai pratiqué en deux phases. La première a consisté à ré-architecturer le tout pour éradiquer les doublons de code. Ca a aussi réduit le temps d'execution de 30%, sans même faire exprès. Ensuite, j'ai travaillé les algos, un par un, pour les rendre lisibles. Je n'ai fait que du nettoyage simple au sens de Joel Spolsky. 4 ans après, ils ont fait un calcul simple, l'ensemble leur a fait gagner plus d'un équivalent temps plein en maintenance. Pour 172 jours de boulot effectif(2/3 par moi, le reste par un collègue).

Mais parfois on a des specs précises. un autre projet que j'ai fait était du genre "bon, il s'agit juste de transformer la sortie papier en sortie fichier plat que mangeront les gens du JAVA pour les afficher sur l'espace agent dans leur appli". Avec 17 pages de specs...et tout changeait subtilement par rapport à l'existant. La chaîne faisait 110 programmes (la plupart courts, mais quelques gros aussi). J'en ai gardé 4, dont 2 sévèrement tronçonnés. Tout le reste, mon collègue et moi avons refait de zéro (en simplifiant quand même, on est arrivé à une soixantaine de programmes). Les deux grosses différences? (1)on avait des specs complètes, et (2)l'existant ne répondait plus vraiment au besoin. Alors même que le code existant était bien plus civilisé, nous l'avons tronçonné de manière bien plus brutale que dans le cas précédent, parce-que nous pouvions nous le permettre, voir que c'était la chose à faire. 93% de page blanche environ.

Donc voilà, les gens sérieux répondent "ça dépend", parce-que c'est effectivement le cas. Suivant la situation, l'une ou l'autre des méthodes sera à appliquer, plus ou moins partiellement. On est des ingénieurs, on est pas là pour appliquer des méthodes sans réfléchir, mais au contraire pour avoir le plus d'outils possibles dans notre boite à outils...et utiliser le bon outil dans la bonne situation. Je suppose que dans ton cas, le bon outil, c'était la page blanche (et les specs qui vont avec).
6  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 29/06/2020 à 20:34
Citation Envoyé par abriotde Voir le message
L argument qu il serait plus économique de tout refaire est falacieux car il ne prends pas en compte les problèmes en prod le plus souvent.
Toi t'as jamais repris le code d'un stagiaire.

Tu lances, ça lance des erreurs, tu t'aperçois qu'il a tout codé ses chemins en dur, en chemin absolu... sauf que toi t'es pas sur son PC.

Il a géré 2 langues... c'est un même dossier copié/collé avec le texte modifié (avec tout le code). Le code dans un foutoir pas possible, plein de code morts / inutiles. Franchement, j'ai pas cherché plus loin, et j'ai bien été content de ma décision.
5  0 
Avatar de mermich
Membre expérimenté https://www.developpez.com
Le 02/07/2020 à 16:39
Réécrire un projet entièrement ne garanti pas les bonne pratiques, ni que le suivi sera correct...

Désole de vous choquer, mais réécrire une application demande de comprendre le fonctionnement de l'application existante, y compris de ses bugs. Plus d'une fois un client m'a demande de reproduire les anciens bugs, car cela permettait une 'certaine' utilisation du produit.

Donc il faudra écrire des tests de non régressions, pour comparer les applicatifs, et au final on se retrouve avec les moyens de faire un refactoring efficace.
5  0 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 29/06/2020 à 14:44
Êtes-vous pour le refactoring de code ou la réécriture d'un projet de zéro ?
A qui s'adresse cette magnifique question?

Au développeur ou à celui qui le paye?

L'un et l'autre auront évidemment une réponse différente!
4  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 01/07/2020 à 13:43
Citation Envoyé par Lcf.vs Voir le message
Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.
pro-tip : quand on travaille plus proprement on est plus productif. Souvent dès la première itération. Le simple fait d'avoir pris le temps de penser correctement son architecture fait gagner un temps fou.

Citation Envoyé par Lcf.vs Voir le message
Dans ce genre de boites, les devs n'ont pas le temps de faire les choses proprement, en respectant les bonnes pratiques, en suivant tous les standards (ni même de les apprendre), etc. et c'est remis à plus tard, quand on aura le temps... les années passent et on se retrouve avec une dette technique d'au moins autant d'années, à force d'empiler rustines sur rustines.
en effet, beaucoup de gens n'ont pas écouté on pro-tip. Il m'est arrivé, dans les exemples que je donne ci-dessus, que des chefs techniques prennent l’occasion d'un changement fonctionnel pour faire faire une refonte complète. Ce n'est pas fréquent, mais il se trouve que je me suis retrouvé plusieurs fois dans ce cas-là. Et là, se pose la question : "refactoriser ou repartir d'une feuille blanche?" Question intéressante et complexe.

Citation Envoyé par Lcf.vs Voir le message
À un moment, ça devient intenable et si, par chance, les décideurs admettent qu'il est temps de de reprendre ça en main, il est souvent bien plus simple de tout reprendre de zéro.
Ben pas forcément, justement. Parfois, tu vas repartir de zéro pour un petit changement en fin de chaîne. Parfois tu vas juste refactoriser un monstre illisible. J'ai fait les deux. Dans les deux cas, il fallait considérer l'ensemble des contraintes pesant sur le projet, pas seulement de l'état du code. Un des trucs importants dits par Joel Spolsky, c'est que le vieux code pourri contient un tas d'astuces fonctionnelles dont la mémoire a pu se perdre par ailleurs. C'était mon cas quand j'ai fait un simple refactoring. Ca aurait été simple de tout reprendre à zéro, mais sans specs, tu fais comment? Alors qu'un refactoring systématique a permis de garder isofonctionnalité sur tous les éléments. Le code aussi atroce soit-il était la seule trace qui restait d'années de peaufinages. Ca a sans doute coûté plus cher...au départ. Le nombre de bugs au final était dérisoire.

Citation Envoyé par Lcf.vs Voir le message
Alors, oui, je suis vraiment étonné, car en plus de 15 ans d'entraide, sur différents sites, l'excuse du "pas le temps" représente 99.999% de celles invoquées pour ne pas faire les choses comme il faudrait.
Et c'est une mauvaise excuse. Quand on fait les choses bien, on finit plus vite. Cela étant, faire vite n'est pas la seule cause de dette technique. Les maintenances qui s'empilent pendant des années sont une autre cause de dette technique, parfaitement acceptable, et qu'il faut pourtant parfois traiter.
4  0