Hisse et ho !

From The Joel on Software Translation Project

Revision as of 22:23, 4 February 2010 by Pakter (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Article original: Rub a dub dub
Date de publication: 23 janvier 2002
Traducteur: Pakter
Vérifié par:
Navigation: Retour à Main Page Retour à French FrenchFlag.png




Une des raisons qui font que les gens sont tentés de réécrire tout leur code de zéro, est que le code d'origine n'était pas conçu pour ce qu'il fait à présent. Il était conçu en tant que prototype, expérience, exercice d'apprentissage, course contre la montre de neuf mois vers l'introduction en bourse, ou encore pour une démonstration jetable. Et voilà qu'il a enflé jusqu'à devenir un bazar fragile, au code impossible à modifier.

Et tout le monde gémit.
Et les vieux programmeurs, de désespoir, s'en vont.
Et les nouveaux qu'on fait venir n'y comprennent goutte.

Au point qu'ils parviennent à convaincre la direction d'abandonner et de tout recommencer — pendant que Microsoft ramasse la mise à leur place. Aujourd'hui, laissez-moi vous raconter comment ils auraient pu faire autrement.

FogBUGZ a démarré il y a six ans comme une expérience pour m'apprendre la programmation en ASP. Assez rapidement, c'est devenu un système de suivi d'anomalies maison. Il a été amélioré presque chaque jour avec des fonctions dont les gens avaient besoin, jusqu'à ce qu'il soit assez bon pour ne plus justifier de travaux supplémentaires.

Plusieurs amis m'ont demandé s'ils pouvaient utiliser FogBUGZ dans leur société. Le problème était qu'il y avait trop de trucs codés en dur, ce qui rendait particulièrement pénible de le faire tourner n'importe où ailleurs que sur la machine où il était déployé à l'origine. J'avais utilisé pas mal de procédures stockées SQL Server, ce qui signifiait qu'il fallait avoir SQL Server pour utiliser FogBUGZ, ce qui était cher et superflu pour certaines des équipes de deux personnes qui voulaient l'utiliser. Et ainsi de suite. Donc je disais à mes amis, « allez, pour 5000 $ de frais de conseil, je passe deux ou trois jours à nettoyer le code pour que vous puissiez le faire tourner sur votre serveur, en utilisant Access au lieu de SQL Server ». En règle générale, mes amis trouvaient ça un peu trop cher.

Après plusieurs répétitions de ce scénario, j'ai eu une révélation -- si je pouvais vendre le même programme à, mettons, trois personnes, je pourrais demander 2000 $ et m'en sortir mieux. Ou trente personnes à 200 $. Le logiciel, ça marche comme ça. Alors fin 2000, Michael s'est assis, a porté le code pour le faire fonctionner avec Access ou SQL Server, a placé tout ce qui était spécifique au site dans un fichier d'en-tête, et on a commencé à vendre le truc. Je n'en attendais pas grand-chose d'extraordinaire.

A l'époque, je pensais, bon sang, on trouve des palanquées de logiciel de suivi d'anomalies. Tous les programmeurs ont écrit leur gestionnaire de suivi d'anomalies. Pourquoi est-ce que quiconque achèterait le nôtre ? Il y avait une chose que je savais : les programmeurs qui créent des sociétés ont la mauvaise habitude de penser que tous les autres sont des programmeurs comme eux, et veulent les mêmes trucs qu'eux, et du coup, ils ont une tendance malsaine à créer des sociétés qui vendent des outils de programmation. Voilà pourquoi on voit tant de sociétés squelettiques essayant de vous refiler des bidules générateurs de code, des bidules de gestion d'erreur, des bidules débogueurs, des zinzins éditeurs avec coloration syntaxique, des machins qui transfèrent par ftp, et, hem, des outils de suivi d'anomalies. Le genre de trucs qu'un programmeur adorerait. Je n'avais aucune intention de tomber dans ce piège-là !

Bien sûr, les choses ne marchent jamais vraiment comme prévu. FogBUGZ a eu du succès. Pas mal de succès. Il représente une part significative des revenus de Fog Creek, et les ventes augmentent régulièrement. Les Gens n'arrêtent pas de l'acheter.

Alors nous avons créé la version 2.0. C'était une tentative pour ajouter certaines des fonctions les plus manifestement nécessaires. Pendant que David travaillait sur la version 2.0, nous ne pensions honnêtement pas que ça valait tant d'effort. Il a donc eu tendance à faire ça d'une manière qu'on pourrait qualifier d' « expéditive » plutôt que, disons, « élégante ». Certains, hem, problèmes de conception dans le code d'origine ont pu se transformer en abcès. Il y avait deux jeux complets de code presque identique pour afficher la page principale d'édition des anomalies. Des instructions SQL étaient dispersées dans le code HTML ici et là, de ci de-là, par-ci par là. Notre code HTML grinçait, et était conçu pour ces navigateurs antiques qui étaient si bogués qu'ils pouvaient planter rien qu'en chargeant about:blank.

Ouais, ça a marché du feu de dieu, ça fait un moment que nous sommes à zéro bogue connu. Mais à l'intérieur, le code était, pour utiliser le terme technique, un « énorme bazar ». Ajouter de nouvelles fonctions était un supplice. Ajouter un champ à la table centrale des anomalies requerrait probablement 50 modifications, et vous seriez encore en train de trouver des endroits que vous auriez oublié de modifier, longtemps, longtemps après avoir acheté votre premier aérocar familial pour vos week-ends en bord de mer sur Mars.

Une société moins importante, peut-être une dirigée par un cadre issu du métier de la livraison express de paquets, aurait pu décider de mettre le code à la poubelle et de recommencer.

Ai-je mentionné que je n'étais pas partisan de repartir de zéro ? Je crois que j'en parle assez souvent.

De toute façon, au lieu de repartir de zéro, j'ai décidé que ça valait bien trois semaines de ma vie de briquer le code. Hisse et ho ! Dans l'esprit de la refactorisation, j'ai posé quelques règles pour cet exercice.

  1. Pas de nouvelles fonctionnalités, même petites.
  2. A n'importe quel moment, à chaque remontée du code, le code continuerait à fonctionner parfaitement.
  3. Je ne ferais rien d'autre que des transformations logiques -- le genre de choses qui sont presque mécaniques, et pour lesquelles vous pouvez vous convaincre immédiatement qu'elles ne changeront pas le comportement de votre code.

Je suis passé sur chaque fichier source, un par un, de haut en bas, en regardant le code, en réfléchissant à une meilleure structure, et en faisant des changements simples. Voici le genre de choses que j'ai faites au cours de ces trois semaines :

  • Changé tout le HTML en xhtml. Par exemple, <BR> est devenue <br />, tous les attributs ont été entourés de guillemets, toutes les balises imbriquées ont été refermées, et toutes les pages ont été validées.
  • Supprimé tout le formatage (balises <FONT> etc.) et tout mis dans une feuille de style CSS.
  • Retiré toutes les instructions SQL du code de présentation, et en fait toute la logique du programme (ce que les gars du marketing aiment appeler les « règles métiers »). Ça a été réparti dans des classes pas vraiment conçues -- j'ai simplement ajouté des méthodes quand je découvrais que j'en avais besoin. (Quelque part, quelqu'un avec une grosse pile de cartes de 10x12 affûte son crayon pour me crever les yeux. Comment ça, vous n'avez pas conçu vos classes ?)
  • Trouvé les blocs de code répétés et créé des classes, des fonctions ou des méthodes pour éliminer la redondance. Eclaté les grandes fonctions en de multiples fonctions plus petites.
  • Ôté tout le texte en langue anglaise restant du code principal, et isolé celui-ci dans un seul fichier pour faciliter l'internationalisation.
  • Restructuré le site ASP pour qu'il y ait un seul point d'entrée, au lieu de plein de fichiers différents. Cela rend très simple des choses qui étaient auparavant difficiles : par exemple, nous pouvons maintenant afficher des messages d'erreur dans le formulaire même où la donnée invalide a été entrée, ce qui devrait être facile si vous avez mis les choses en place correctement, mais je n'avais pas mis les choses en place correctement quand j'apprenais à programmer en ASP, à l'époque.

En l'espace de trois semaines le code, en interne, s'est nettement amélioré. Pour l'utilisateur final, pas grand chose de changé. Certaines polices sont un peu plus jolies grâce à CSS. J'aurais pu m'arrêter à n'importe quel point, parce qu'à chaque instant j'avais du code 100 % fonctionnel (et je transférais chaque mise à jour vers notre serveur FogBUGZ interne pour m'en assurer). Et en fait, je n'ai jamais vraiment eu à réfléchir beaucoup, et je n'ai jamais eu à concevoir quelque chose, parce que tout ce que je faisais, c'était des transformations logiques simples. De temps en temps je rencontrais un grumeau bizarre dans le code. Ces grumeaux était habituellement des corrections d'erreurs, implémentées au cours des années. Heureusement, je pouvais conserver intacte la correction. Dans bien des cas, je me suis rendu compte que si j'étais reparti de zéro, j'aurais refait la même erreur, sans peut-être la remarquer pendant des mois ou des années.

En gros, j'ai fini maintenant. Ça a pris, comme prévu, trois semaines. Presque chaque ligne de code est différente à présent. Ouaip, j'ai regardé chaque ligne de code, et changé la plupart d'entre elles. La structure est complétement différente. Toute la gestion de suivi d'anomalies est complétement séparée de la gestion de l'affichage.

Voici les avantages de mon activité de nettoyage de code :

  • Ça a pris considérablement moins de temps qu'une réécriture complète. Supposons (en se fondant sur le temps que cela nous a pris jusqu'ici pour FogBUGZ) qu'une réécriture complète aurait pris un an. Eh bien, cela signifie que j'ai économisé 49 semaines de travail. Ces 49 semaines représentent la connaissance dans la conception du code que j'ai préservée intacte. Je n'ai jamais eu à me dire, « oh, j'ai besoin d'un retour à la ligne ici ». J'ai juste dû changer <BR> en <br /> sans y penser, puis passer à la suite. Je n'ai pas eu à me demander comment faire marcher le mode multipart pour les envois de fichiers. Ça fonctionne. On nettoie juste un peu.
  • Je n'ai pas introduit de nouvelles anomalies. Une ou deux petites, bien sûr, sont probablement passées au travers. Mais je ne faisais jamais le type de choses qui entraînent des anomalies.
  • J'aurais pu m'arrêter et livrer à n'importe quel moment si nécessaire.
  • Le calendrier était entièrement prévisible. Après une semaine, vous pouvez calculer exactement combien de lignes de code vous nettoyez en une heure, et en déduire une sacrée bonne estimation pour le reste du projet. Essayez donc, vous les navigateurs à la dérive de chez Mozilla !
  • Le code se prête maintenant bien mieux à l'ajout de nouvelles fonctions. Nous regagnerons probablement les trois semaines à la première fonction majeure que nous implémenterons.

La plupart de la littérature sur la refactorisation est due à Martin Fowler, même si, bien entendu, les principes du nettoyage du code sont bien connus des programmeurs depuis des années. Un nouveau domaine intéressant est constitué par les outils de refactorisation — ce qui est juste un nom sexy pour les programmes qui font ce genre de boulot automatiquement. Nous sommes loin d'avoir tous les bons outils dont nous aurions besoin — dans la plupart des environnements de programmation, vous ne pouvez même pas faire une transformation aussi simple que de changer le nom d'une variable (et voir ce changement répercuté automatiquement sur les références à cette variable). Mais cela s'améliore, et si vous voulez lancer une de ces sociétés décharnées qui fourguent des bidules d'outils de programmation, ou apporter une contribution utile à l'Open Source, le champ est ouvert.

Personal tools