Comment réparer un projet sans structure?


25

Je travaille sur un projet logiciel principalement en solo depuis plus de 5 ans. C'était un gâchis au début (je suis le troisième ou le quatrième développeur à y travailler), et bien que ce soit moins un désordre maintenant, il est toujours incroyablement désorganisé. Le rythme des progrès pour le maîtriser est glacial et je commence à me sentir découragé par l'état dans lequel il se trouve. Comment puis-je vraiment commencer à le réparer?

Spécificités du projet: Il s'agit d'un programme de vente écrit presque entièrement en Visual Basic Classic (VB6) avec un back-end MySQL et un moteur de reporting écrit en C #. Le module de création de rapports C # est un plaisir de travailler, il n'a été écrit que ces deux dernières années et avant que tous les rapports aient été effectués dans Crystal Reports 9 (oui, nous avons encore certains rapports qui en dépendent).

Cependant, le programme lui-même est un désastre complet. Il n'y a pas tout à fait 90k LOC et environ 10k lignes de commentaires (surtout pas de documentation, mais de l'ancien code qui a été commenté). 158 fichiers de formulaire et 80 fichiers de module. Je n'ai aucune idée du nombre de ceux qui sont réellement utilisés, car certaines fonctionnalités du programme sont simplement obsolètes et (euh, parfois) notées comme telles sans que le code associé soit supprimé du programme. Je suppose que seulement 50% du code est réellement utilisé de manière productive.

J'ai peur de toucher une grande partie du code simplement parce que je ne sais pas si je casse quelque chose sur lequel un client obscur s'appuie, cela s'est produit plus d'occasions que je ne peux en compter. C'est comme s'il y avait des mines terrestres disséminées dans tout le code.

Il n'y a pas vraiment de structure au projet. Il n'est pas orienté objet, sauf dans les rares endroits où j'ai eu la patience de réformer jusqu'à présent. Si vous avez besoin d'obtenir des données sur un formulaire, vous instanciez un objet de base de données, déclarez votre requête directement dans la fonction, l'exécutez et faites ce que vous voulez avec l'ensemble de données.

Lorsque j'ai commencé à travailler sur le projet, aucun contrôle de code source n'était utilisé. J'ai essayé d'encourager les autres personnes sur lesquelles je travaillais à l'utiliser, mais j'étais le nouveau gars et mes tentatives pour amener les gens à utiliser la subversion ont échoué. Le développeur principal de la société a finalement détecté un bug mercurial au cours des deux dernières années et il s'est assuré que tous les développeurs utilisent le contrôle de code source sur tous les projets, donc au moins c'est un progrès.

Je pense que si je pouvais travailler à la réforme du projet à plein temps, je pourrais faire des progrès décents et peut-être même avoir une estimation du temps qu'il me faudrait pour refaire complètement le projet, mais il est en cours d'utilisation et je suis constamment demandé d'éteindre des incendies, de corriger des bogues, d'ajouter des fonctionnalités, etc. etc.

Alors, comment puis-je vraiment réparer ce projet? Essayez d'utiliser l'outil VB6 avec une autre langue? Essayez de réécrire le programme pendant mon temps libre? Ou est-ce complètement désespéré?

Mise à jour

Après ce poste, je suis retourné au projet avec un zèle renouvelé, mais je suis retombé dans le désespoir en quelques mois après avoir vu un rythme si lent de progrès. J'ai ensuite répété ce cycle 2 ou 3 fois de plus au cours de la prochaine année.

Depuis, je suis passé à un autre emploi. Bien qu'après tant d'années de vb6, et seulement une expérience périphérique avec d'autres technologies, la recherche ait été difficile et j'ai fait face à de nombreux refus en cours de route (une dizaine d'interviews au cours d'une année). Mon conseil aux autres dans cette situation est d'envisager de partir seul pour ce facteur. Considérez les dommages que vous pouvez faire à votre carrière en restant dans une impasse comme celle-ci.


4
Cela semble assez mauvais. Un début serait d'enregistrer une copie du code actuel et de supprimer l'ancien code qui a été commenté (c'est juste du bruit). Lorsque je travaillais sur un système hérité, je mettais généralement une date en haut du code que je commentais. Puis vider le code commenté qui était âgé de 6 mois ou plus.
programmeur

4
Je commencerais par Jamison et je descendrais l'étagère. . .
Wyatt Barnett

1
Avez-vous déjà essayé de reprendre un projet C # écrit par un programmeur VB?
שינתיא אבישגנת

Réponses:


28

Maintenant qu'il est sous contrôle de code source, vous pouvez vous débarrasser du code mis en commentaire.

J'ai commencé ici dans une situation similaire (application 80KLOC VB6 sans contrôle de source, pas de structure réelle, presque tout ce qui se fait dans les gestionnaires d'événements).

En environ 2 ans, j'ai plus de la moitié converti en C # (généralement lorsque de nouvelles fonctionnalités importantes sont requises). Tout nouveau code C # a une couverture de test unitaire. Cependant, la conversion en C # prend beaucoup plus de temps. Si vous n'ajoutez pas de nouveaux modules importants, je n'irais pas dans cette direction.

J'ai créé une couche d'accès aux données rudimentaire qui s'est générée automatiquement à partir de la base de données. Cela a au moins attrapé des problèmes où un nom de colonne de table a changé et je n'ai pas trouvé tous les endroits dans le code. De plus, j'ai lentement déplacé la logique métier dans des modules, hors des gestionnaires d'événements de formulaire.

Cependant, j'ai eu l'avantage que la demande était uniquement interne. Comme je n'avais qu'un site à déployer, je pouvais prendre des risques plus importants que vous. Si je faisais une erreur, ce n'était généralement pas un gros problème pour le réparer. On dirait que vous n'avez pas ce luxe.

Je pense vraiment que votre meilleur pari est d'adopter l'approche suivante:

  1. Apprenez chaque détail dans les moindres détails. Cela rend moins probable que vous cassiez quelque chose par inadvertance.
  2. Refactorisez sans pitié pour améliorer la séparation et la structure, mais n'essayez pas de chausse-pied une nouvelle méthodologie comme la programmation orientée objet là-dedans, car VB6 ne fait que sucer.
  3. Traitez-le comme une expérience d'apprentissage. Comment sauriez-vous qu'une manière différente est meilleure si vous n'aviez jamais vu la voie inférieure?
  4. Ne vous embêtez pas à réécrire dans un nouveau langage / framework / plateforme à moins que vous n'ayez un module majeur à écrire. Même alors, réfléchissez bien.

N'oubliez pas que l'objectif du programme est d'être un produit qui rapporte de l'argent à votre entreprise. Cela ne doit pas être une œuvre d'art sans faille (et je suis un perfectionniste, donc c'est vraiment difficile pour moi de l'admettre). Parfois, il vaut mieux embrasser le pragmatisme.

Il y a censément beaucoup de programmeurs COBOL qui maintiennent des quantités massives de code hérité. Je doute qu'ils travaillent tous follement à la réécrire dans une nouvelle langue. :)


3
+1 Excellente réponse: tout ce que je peux ajouter, c'est être sûr que vous ne vous attendez pas trop. La maintenance du code est lente par rapport au nouveau développement, au code hérité, encore plus lent et au code non structuré non documenté comme vous l'avez décrit .... Les 5 dernières années, j'ai travaillé sur une variété de bases de code remontant aux années 80 et de mesures en millions SLOC ... Je connais votre douleur ...
mattnz

+1 mais une fonction OO VB6 est OK à ses interfaces. Si vous pouvez voir plusieurs fois le même code copié et copié, vous pourrez peut-être refactoriser une interface, sinon une classe complète.
Mark Hurd

3

Ce que vous devez faire, c'est refactoriser. Le refactoring est presque impossible dans une telle situation sans test unitaire qui vous donne la certitude que vous n'avez rien cassé. Par conséquent, commencez par créer des tests unitaires. Documentez le comportement du code - mais pas (seulement) sur papier, mais en plus de code - les tests unitaires. Une fois les tests en place, vous pouvez commencer à restructurer le code.


11
J'ai été dans cette situation. Tout d'abord, VB6 a de pitoyables suites de tests unitaires. Deuxièmement, les tests unitaires nécessitent presque toujours DI et c'est vraiment difficile dans VB6 en raison de son terrible support pour la programmation orientée objet. Je n'ai encore entendu parler de personne qui a pris un projet VB6, a écrit un tas de tests unitaires et a subi une crise de refactorisation, même si c'est la réponse standard que vous entendrez toujours pour une question comme celle-ci sur Programmers.SE. Savez-vous combien il est pénible d'écrire des tests unitaires pour la logique qui est intégrée partout dans les gestionnaires d'événements Form? Vous devez refactoriser avant de pouvoir écrire des tests!
Scott Whitlock

J'adorerais ajouter des tests unitaires à notre code, mais je ne sais pas par où commencer. J'ai fait des tests unitaires en .net et dans d'autres langues, mais uniquement à partir de zéro, sans jamais ajouter de tests à un projet existant. Et aucun des tests unitaires que j'ai effectués n'a porté sur des programmes utilisant des interfaces graphiques, en particulier des interfaces graphiques avec beaucoup de bases de données et de logique métier mélangées dans les gestionnaires d'événements!
Dylan Nissley

1
Si le code n'a pas été écrit pour être testable, tout ce que vous ferez sera d'écrire des tests unitaires qui couvrent les cas faciles et évidents, et manquer les cas de bord qui causent 90% des défauts. J'y suis allé, j'ai fait ça, j'ai perdu beaucoup de temps et d'efforts (lire Money). La meilleure approche consiste à s'assurer que le code que vous modifiez est facilement testable, ce que cela signifie dans l'environnement que vous avez, ce qui ne ressemble pas à des tests unitaires.
mattnz

3

Une règle du " débogage " de David Agan vient à l'esprit: arrêtez de penser et regardez. Il se trouve que vous avez à votre disposition une machine capable de traiter de grandes quantités de texte. Utilisez-le pour déterminer précisément quel code n'est plus utilisé et supprimez-le sans pitié. Si vous faites une erreur, c'est à cela que sert le contrôle de source.

Voilà la partie facile. Ce à quoi vous devez penser ensuite, comment mangez-vous un éléphant? Une bouchée à la fois. Reprenez le " Refactoring " de Martin Fowler et prenez-le fonction par fonction, fichier par fichier. Ne supprimez pas complètement quelque chose et réécrivez-le à partir de ce que vous pensez être les exigences. Travaillez comme un alpiniste, ne retirez jamais votre sécurité précédente jusqu'à ce que la suivante soit en place.

Avait-il encore assez de métaphores? Le fait est que si vous le prenez lentement et régulièrement, avec de nombreuses améliorations aussi simples que renommer ou fractionner une fonction, vous pouvez améliorer les mauvaises parties du code sans détruire les bonnes parties qui ont été construites au fil des années de débogage et de demandes de fonctionnalités. . Vous voulez que le code reste expédiable à tout moment. S'il est possible de le faire en utilisant une langue plus moderne, allez-y.


À moins qu'il ne soit fait correctement, le «Portage vers un langage moderne» donnera un «programme VB en syntaxe C #» - Travaille actuellement sur une application C portée sur Java qui est vraiment «Cava» et non Java - c'est la pire des deux et la meilleure des deux ........ Le portage correct est vraiment une réécriture en glissement, et comme Joel l'a dit - ce qui est haut dans la liste des "choses à ne pas faire".
mattnz

Bon point. C'est pourquoi j'ai dit "si c'est possible". Si vous ne pouvez pas le faire petit à petit et aussi écrire le code porté idiomatiquement, vous ne devriez pas essayer.
Karl Bielefeldt

3

Je déteste le dire mais j'irais avec "complètement sans espoir" au-delà de simplement continuer à faire un cycle sans fin de patch / amélioration et j'espère que rien ne casse. J'ai vu beaucoup trop de projets VB6 comme celui que vous décrivez et les tentatives de les refactoriser / réécrire / refaire en C # /. NET échouent terriblement, souvent avec les personnes en charge de la tentative.

Le fait est qu'une réécriture complète à partir de zéro va être nécessaire tôt ou tard. Les versions VB6 et Windows qui le supportent bien sont en déclin. Trouver des développeurs qui connaissent les bizarreries de VB6 et qui sont prêts à travailler sur des programmes comme celui-ci deviennent de plus en plus rares. Les limites internes de VB6 seront touchées sur d'énormes programmes comme celui-ci, provoquant des erreurs étranges.

S'il y a un bon consensus et un bon engagement pour un total, fonder, repenser et réécrire à ce stade, commencez à travailler dessus et déléguez la maintenance continue à quelqu'un d'autre (entrepreneurs, programmeurs juniors, tout ce qui fonctionne pour vous). Si les gens ne sont pas encore suffisamment convaincus pour commencer, attendez simplement que la douleur devienne suffisamment grande ou passez à des pâturages plus verts.


+1 Vous avez raison de dire que VB6 perd son support sur les versions Windows modernes. Tôt ou tard (probablement plus tôt), votre application cessera simplement de fonctionner là où elle doit.
Bernard

1

Quelques bonnes réponses ici déjà, je voudrais ajouter une chose. Au lieu d'essayer de tout réécrire, vous aurez peut-être la possibilité de porter au moins certains de ces modules principalement 1: 1 vers VB.NET (bien sûr, vous devez être très prudent non plus lorsque vous faites cela)? D'après mon expérience, un tel portage peut être effectué avec environ 5 à 10 fois moins d'efforts que d'essayer de reconstruire toutes les fonctionnalités existantes à partir de zéro. Et après avoir porté ce, alors vous pouvez commencer à refactor - avec tous les outils disponibles dans le monde .NET, comme les outils de test de bonne unité, des outils automatiques de refactoring, réel POO etc.

J'étais dans une situation similaire, où nous devions migrer un ancien programme C ++ 16 bits (150k LOC) dans le monde 32 bits, où le cadre GUI d'origine utilisé n'était plus disponible. Il nous a fallu un certain temps pour comprendre que la réécriture était irréaliste, mais après avoir décidé de porter cette chose vers le monde .NET, en utilisant C ++, C ++ / CLI et C #, nous avions besoin d'environ 9 mois seulement pour y arriver (avec environ 1 dev à plein temps sur ce projet). Et nous n'avions pas de tests unitaires disponibles pour la partie GUI, avons fait tout ce test de ces parties manuellement.


0

Bien qu'il met BEAUCOUP l'accent sur les tests unitaires de votre application, ce qui, bien que très important à faire, est quelque chose d'assez difficile à faire dans VB6, Steven McConnell a écrit un excellent livre sur la façon d'aborder un tel projet.

Jetez un coup d'oeil:

Steven C. MCCONNELL: Travailler efficacement avec Legacy Code, deuxième édition. Microsoft Press, juin 2004.

Fondamentalement, son but est de le prendre lentement, un peu à la fois. Il recommande également de commencer par utiliser des techniques de refactoring qui sont très peu susceptibles de casser quoi que ce soit, parfois de les aggraver à court terme, et de commencer à utiliser des techniques plus avancées car le code devient plus propre et a des tests unitaires pour le supporter.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.