Comment prouver qu'une application est construite sur une mauvaise base de code?

23

J'examine actuellement un système construit par certains développeurs qui travaillaient auparavant dans mon travail. Le système fonctionne assez bien du point de vue de l'utilisateur, mais lors de l'examen du code, c'est un gâchis absolu. Je suis plus que convaincu que la façon dont l'application est construite ne résistera pas aux futures mises à jour, sans parler de fortes augmentations d'utilisation.

Le problème est que je sais à quel point c'est mauvais, mais mes supérieurs ne le savent pas. Comment puis-je le prouver à mon responsable afin qu'il voit réellement le problème et puisse être convaincu de faire un triage minimal sur la base de code actuelle, et dans un proche avenir, commencer une nouvelle ligne de développement pour la prochaine version de l'application?

ChrisR
la source
6
programmers.stackexchange.com/questions/59050/… Peut-être écoutez-vous à quel point la "grande réécriture" est mauvaise du point de vue commercial. Ce serait ce que ferait un programmeur plus "senior".
quentin-star du
22
@qes, la seule chose pire que de faire la "grosse réécriture" est une peur paralysante de la "grosse réécriture". Quand j'ai commencé ma position actuelle, j'ai hérité d'un désordre de Perl CGI de deux ou trois programmeurs différents sans contrôle de source, suivi de bogue ou test. Il a fallu convaincre, mais j'ai obtenu l'approbation de réécrire dans Ruby on Rails tout en conservant le code hérité. 5 mois plus tard, les outils étaient plus conviviaux et nous pouvions ajouter de nouvelles fonctionnalités en quelques jours ou semaines au lieu de mois. Les utilisateurs sont ravis et je ne perds pas la tête. La «grande réécriture» nécessite une justification solide, et non un évitement total.
Jason Lewis
1
@JasonLewis: (Je suppose que vous n'avez pas suivi le lien dans mon commentaire précédent?) Cela semble peu judicieux pour quelqu'un qui, il y a moins d'un an, s'est décrit comme manquant de compétences importantes qu'un niveau supérieur posséderait et ne possède pas. Je ne sais pas par où commencer lors du démarrage d'un nouveau projet.
quentin-star du
5
@JasonLewis Je suis entièrement d'accord avec vous. Chaque fois que quelqu'un pose des questions sur la réécriture d'une application en SE, beaucoup de gens ont cette idéologie «ne faites pas une grosse réécriture». Je pense qu'il y a certainement de nombreuses raisons de ne pas le faire, mais vous ne devriez pas l'éviter à tout prix. J'ai participé à la réécriture d'une application de code de 100 000 lignes et nous avons eu beaucoup de succès, très similaire à ce que vous avez décrit. Nous avons même pu le réécrire module par module (première partie de l'interface utilisateur, puis le serveur, puis le reste). 12 mois plus tard, nous avons une clientèle très très heureuse et tout le monde est fier de la décision que nous avons prise.
Alex
2
Cela fait partie d'un problème plus général: celui de votre prédécesseur recherchant des résultats immédiats à long terme. Lors de la prise de contrôle, vous devez expliquer pourquoi vous ne pouvez pas conserver la même sortie.
David Thornley

Réponses:

23

«Mais cela fonctionne maintenant» est la réponse de gestion standard aux frustrations légitimes des ingénieurs logiciels. La première chose que je ferais serait de compiler la documentation (le cas échéant) et de l'utiliser pour démontrer les contradictions entre le code et la documentation.

Si vous le pouvez, créez une suite complète de tests unitaires. Exécutez-les à chaque modification afin de pouvoir documenter les régressions qui peuvent être imputées à la base de code existante.

Enfin, si vous pouvez attirer un développeur d'un autre département dont vous faites confiance, obtenez une deuxième paire d'yeux sur le code. Un développeur qui dit «c'est de la merde» est plus facile à écarter que lorsqu'un développeur senior qui existe depuis un certain temps se porte garant de lui et dit: «Non, Jim, il a raison. C'est de la merde sur un cracker de merde.

Bien sûr, tout dépend de votre environnement, de la taille de votre entreprise, etc.

Je recommande toujours de jeter un œil au programmeur pragmatique si vous ne l'avez pas lu. Non seulement cela devrait être une lecture obligatoire pour tous les professionnels du logiciel, mais il a de bonnes suggestions pour traiter avec la direction, les collègues, les utilisateurs, etc. qui ne considèrent pas le génie logiciel comme un métier.

Jason Lewis
la source
7
Il n'y a pas de documentation et le code est à peu près impossible à tester, sauf si nous allons en refactoriser l'enfer. Je suis assez confiant d'être soutenu par plusieurs collègues, donc obtenir un autre développeur dans la discussion pourrait aider.
ChrisR
@ChrisRamakers C'est une excellente nouvelle (le support, pas le manque de documentation!). Il est plus difficile (mais pas impossible) pour les gestionnaires de nier / rejeter l'opinion professionnelle de plusieurs développeurs. Et si vos partisans travaillent depuis plus longtemps dans l'entreprise, ils peuvent avoir une expérience précieuse dans la navigation dans la politique interne de l'organisation. Bonne chance!
Jason Lewis
De plus, si vous pouvez obtenir un logiciel de test de charge, vous pouvez montrer comment il peut se casser sous une charge élevée.
HLGEM
13

Du point de vue de la direction, il n'y a rien de mal avec le système et vous vous plaignez simplement parce que [vous voulez juste le réécrire / vous ne comprenez pas ce que les ingénieurs précédents ont fait / vous voulez que votre travail soit facile]. Un peu un homme de paille, mais quand quelqu'un au sommet voit que les choses fonctionnent bien en ce moment, il n'est pas disposé à voir une crise où vous le faites (je suis sûr qu'il y a une allégorie du changement climatique quelque part là-dedans ...) .

Dans une certaine mesure, ils ont raison. La direction voit des problèmes lorsque les versions vont bien au-delà de leur estimation d'origine, les estimations semblent trop élevées pour le travail en cours, "c'est impossible avec notre base de code existante", et des occurrences élevées de bogues dépassant le contrôle qualité. Si les choses ronronnent bien, il est facile de vous tapoter la tête et de vous dire de faire de votre mieux, car cela n'affecte pas le résultat net.

La procédure à suivre dépend de votre organisation et du logiciel lui-même. Fondamentalement, cependant, je suggère de documenter toutes les complications qui surviennent à la suite d'un mauvais code hérité. Lors de l'estimation des tâches, expliquez clairement à la direction pourquoi vous pensez que cela prendra autant de temps, avec des explications détaillées sur les aspects de l'ancienne base de code qui ajoutent ce coût supplémentaire. Lorsque des bogues sont introduits dans le code, indiquez les raisons pour lesquelles ce bogue a pu se glisser et comment les problèmes dans l'ancienne base de code sont responsables.

Je suggérerais d'exprimer vos préoccupations aux parties prenantes d'une manière qui suggère que le logiciel a dépassé sa conception d'origine et qu'il est maintenant difficile de continuer à l'améliorer.

Stefan Mohr
la source
5

Il existe différents outils disponibles qui peuvent effectuer la couverture du code et la révision du code. Les outils Google adaptés à votre technologie, ce sont normalement des outils standard de l'industrie. Je vous suggère d'utiliser ces outils et de créer un rapport sur la qualité du code et de le présenter au gestionnaire. Assurez-vous que votre critique est constructive et apolitique.

ViSu
la source
oui, j'ai pensé à calculer la complexité cyclomatique moyenne et à l'utiliser comme argument, mais je suis certain que cela ne prouvera rien à la direction. Mais ça vaut le coup d'essayer, thnx
ChrisR
5
@ChrisRamakers: Rien ne peut être "prouvé" à un manager. Oubliez la "preuve". Recueillir des données. Les faits sont tout ce que vous avez. Plus de faits sont plus convaincants. Mais il n'y a pas de "preuve".
S.Lott
4

Choisissez un exemple facile à comprendre où la direction penserait qu'il s'agit d'une simple demande de changement, mais en raison de la conception existante, elle est beaucoup plus difficile.

Vous ne voulez pas qu'ils s'attardent sur la demande spécifique, mais assurez-vous de leur faire savoir à quoi ressemblera TOUTE demande de changement. Personne ne veut être peint dans un coin avec une application. Les développeurs croient en YAGNI, mais la direction croit en CYA.

Les suggestions pour les tests de charge pourraient être une bonne approche, mais elles peuvent ne pas être convaincues que les préoccupations croissantes d'utilisation répondent à un potentiel de croissance réel (la société ne va pas doubler en un an).

Tout est relatif. Ils ne voudront peut-être pas investir les ressources dans ce projet lorsqu'ils ont des plans pour des projets plus importants sur lesquels passer votre temps. Ne soyez pas étiqueté comme ne voyant pas la vue d'ensemble.

JeffO
la source
1
Après avoir effectué la modification, montrez le fichier diff qui, dans une mauvaise base de code, touchera de nombreux fichiers source différents, a un "qu'est-ce que cela a à voir avec cela?" élément, etc. Expliquez à la direction dans quelle mesure ce travail, c.-à-d. temps == $$, était lié à la mauvaise base de code et que les changements à venir auront tous cette caractéristique.
Larry OBrien
3

Lorsque vous parlez de prouver quelque chose, toutes ces méthodes scientifiques entrent en jeu, et une partie de ce que cela signifie est que si vous acceptez des normes objectives pour décider de ce qui est vrai, vous devez accepter la possibilité que, lors d'une enquête, ces faits ennuyeux s'avérer ne pas être de votre côté.

Dans votre cas, je pense qu'il y a 2 choses à prouver.

Premièrement, que la base de code actuelle est "mauvaise". Ce que vous pouvez probablement prouver, c'est que "l'avis professionnel de presque tous les développeurs qui examinent ce code est qu'il est mauvais".

Deuxièmement, la société ferait mieux de réécrire la base de code. C'est un problème car même si le premier point est vrai, le second ne l'est peut-être pas. De plus, vous n'en savez pas assez pour prendre cette décision. C'est le travail de la direction et si vous voulez qu'ils respectent votre jugement professionnel sur le premier point, vous devez respecter le leur sur le second.

Mais ils ne peuvent pas se prononcer sur le deuxième point sans les informations que vous fournissez. Vous devez communiquer ce que vous savez sur la façon dont les problèmes dans le code affecteront l'entreprise et ce que vous savez sur la façon dont une réécriture aurait un impact sur l'entreprise. C'est difficile, car les deux impliquent de prédire un avenir plein d'incertitudes.

Mais vous pouvez essayer d'énoncer le problème en termes commerciaux. Combien de temps supplémentaire est consacré aux changements et régressions? Combien coûterait une réécriture? À quelle vitesse les coûts du système actuel augmenteront-ils au fil du temps s'ils ne sont pas réécrits? Et s'il y a une augmentation de l'utilisation, quelle est la probabilité d'une catastrophe si le code actuel est conservé? Vous ne pouvez pas vraiment savoir tout cela, mais vous pouvez mieux deviner que quiconque. Donnez une plage ou quelque chose pour communiquer avec quelle précision vous pensez pouvoir prédire ces choses.

La plupart des développeurs n'aiment pas maintenir le code moche. C'est pourquoi il peut être regrettable que le code qui est une évidence à réécrire du point de vue du développeur ne vaille pas la peine d'être réécrit du point de vue commercial.

Par exemple, même si la réécriture se révèle rentable, elle pourrait valoir moins que le coût d'opportunité de dépenser l'argent ailleurs dans l'entreprise. Ou la mauvaise base de code peut prendre plus de temps à changer et avoir plus de régressions, mais pas assez pour rentabiliser une réécriture. Ils chercheront peut-être à se faire racheter au cours des prochains mois, et dépenser de l'argent pour une réécriture apparaîtra dans les livres, mais pas les logiciels de buggy.

Essayez d'y penser du point de vue des entreprises et ne préparez pas les chiffres pour obtenir ce que vous voulez. Une grosse réécriture n'est presque jamais une évidence du point de vue commercial. Si vous voulez prouver quelque chose qui n'est pas directement prouvable, faites de votre mieux pour le réfuter. Si vous continuez à faire de votre mieux pour trouver un moyen de ne pas réécrire à partir de zéro, mais rien de ce que vous proposez n'a de sens, alors il est peut-être temps de réécrire à partir de zéro. Et faire cet effort montrera à votre direction que vous êtes sérieux pour représenter les intérêts de l'entreprise, pas les vôtres (vous représentez les intérêts de l'entreprise, pas les vôtres, non?).

psr
la source
2

Je suppose que cela dépend de ce qui est mauvais dans la base de code. Être «pas comme je ferais les choses» ne signifie pas que c'est une mauvaise base de code.

Choses qui font en fait une mauvaise base de code:

  • Trous de sécurité

    Problèmes qui rendent le serveur, l'application et / ou les données vulnérables. Surtout tout ce qui met en danger les données sensibles de l'entreprise, du client ou du client. Celles-ci devraient être faciles à documenter.

  • Travailler brisé

    Cela ne fonctionne que parce que vous massez les données et effectuez la maintenance de l'application presque en continu pour la faire fonctionner. Si vous deviez partir et que personne ne prenait le relais, cela ne fonctionnerait plus. - Documentez le temps que vous passez à le faire. Et notez combien vous pourriez économiser. Très souvent, ces processus sont également inefficaces pour les utilisateurs et vous pouvez également les documenter.

  • Ne fonctionne pas réellement

    Cela semble fonctionner mais les résultats sont incorrects. Cela entraîne généralement des problèmes sur toute la ligne, comme des numéros qui ne correspondent pas, un taux de défaut élevé, etc.

Ce qui n'est pas mauvais code base (tout simplement pas bon):

  • Écrit sur une technologie obsolète non prise en charge. (VB6, COBOL, .net1.1 Etc.)

Notez les avantages de la migration vers une nouvelle technologie. Essayez de trouver un chemin de migration qui déplace les pièces à la fois afin de minimiser les risques et de renforcer la confiance des utilisateurs et de la gestion. Assurez-vous que la logique fonctionne essentiellement de la même manière que l'original.

  • Code non documenté / mal formaté

C'est le plus simple à corriger car vous pouvez généralement ajouter des commentaires et corriger la mise en forme sans impact réel sur le code. Mais cela ne nécessite pas de réécriture. Si vous pensez que cela est combiné avec d'autres problèmes, la première chose à faire est de résoudre ce problème afin que vous puissiez mieux évaluer la viabilité du code.

SoylentGray
la source
1

Vous avez répondu à votre propre question d'une manière.

Le moyen de les convaincre de dépenser de l'argent sur le système est d'attendre qu'il ne fonctionne pas bien pour l'utilisateur. Si vous pensez qu'il ne s'agrandira pas, attendez que cela se produise ou faites un test de charge pour le prouver.

C'est alors une simple proposition de nettoyage à l'échelle qui coûtera X heures.

Jonno
la source
8
Le seul problème est que s'il est le principal responsable du système, il sera blâmé lorsqu'il ne fonctionnera plus. « Mais cela a fonctionné avant vous commencé! », Ils vont dire. C'est pourquoi j'ai conseillé une approche proactive. Prévenez - les à l' avance, documenter les questions, puis son cul est couvert quand il se casse, et non seulement peut - il dire : «Je te l' avais dit à son patron, mais il peut dire : « Je l' ai dit lui si » au patron de son patron.
Jason Lewis
3
@Jason - Je vois votre point, mais d'après mon expérience, le déni opère vers le bas et lui a dit que si vous montez la chaîne, vous rencontrerez très rapidement un «joueur non d'équipe» en descendant.
Jonno
2
Cela dépend beaucoup du lieu de travail individuel, mais je suis d' accord avec vous ... Je aurait pu formuler mieux ... Mon point principal documentait les raisons pour lesquelles il est en cours d'échouer à l' avance, en faisant valoir le point, et de garder la documentation disponible pour quand c'est le cas ... dans le meilleur des cas, vous êtes autorisé à le réparer. Moyenne, vous n'êtes pas foutu quand il échoue. Pire, vous appréhendez profondément le système et ses faiblesses et comment les corriger suffisamment pour expliquer de manière impressionnante (en détail) comment et pourquoi vous avez laissé votre dernier poste à votre employeur potentiel lorsque vous finissez par chercher un emploi après l'échec ;-)
Jason Lewis
1
@JasonLewis Si les joueurs de l'entreprise utilisent des phrases comme celles- I told you solà, c'est une culture toxique de blâme et non un endroit où l'OP voudrait travailler longtemps. Un bon gestionnaire ne blâme pas, un bon gestionnaire reconnaît les problèmes et propose un plan.
maple_shaft
@maple_shaft Je suis d'accord. Je ne voulais pas dire ces mots littéralement, je parlais plutôt de couvrir toutes les bases. Idéalement, nous aurions tous de bons gestionnaires de soutien tout au long de la chaîne de commandement. Souvent, cependant, nous acceptons le commerce équitable pour pouvoir utiliser le travail que nous avons comme tremplin vers le travail que nous voulons.
Jason Lewis
1

C'est une situation difficile à vivre, car du point de vue de l'utilisateur, tout est maintenant à un point acceptable et stable. Principalement avec des responsables non techniques, il n'y a rien à craindre pour le moment, mais demander de réécrire la base de code est une décision énorme et qui ne doit pas être prise à la légère, en particulier sur l'opinion et les efforts d'un seul homme (vous-même) .

Vous êtes donc dans une situation difficile pour essayer de plaider en faveur d'une réécriture en raison de la dette technique écrasante (à votre avis, nous n'avons pas d'exemples et nous devons vous croire sur parole) ainsi que dans la situation difficile d'avoir la difficulté de maintenir et d'ajouter des fonctionnalités dans ce système.

Vos estimations pour les nouvelles fonctionnalités seront élevées, justifiez ces chiffres élevés par des faits, prouvant que ces choses prendront en effet beaucoup de temps. Si vous ne transmettez pas cela correctement, votre gestionnaire peut simplement supposer que vous êtes incompétent et que vous ne le voulez certainement pas. Lorsqu'il remet en question les estimations élevées, expliquez pourquoi vous pensez que la dette technique accumulée entrave la possibilité d'ajouter rapidement et à moindre coût des fonctionnalités au logiciel actuel. Si votre manager a deux cellules cérébrales à frotter, il commencera à comprendre très rapidement.

Le fait est que vous ne devez pas essayer de convaincre votre manager, mais orienter votre manager avec des informations appropriées (et soigneusement sélectionnées) pour qu'il puisse se convaincre qu'une réécriture est un cours acceptable. Vous devez toujours faire croire au manager que c'était son idée.

maple_shaft
la source
1

Déterminez d'abord la dette technique accumulée dans votre base de code. Jetez ensuite un œil à cette question et réponses , où il est expliqué comment convaincre la direction de rembourser la dette technique avant de poursuivre.

BЈовић
la source
0

Il y a une raison pour laquelle tout logiciel mature ressemble à un gâchis:

  1. Tout le désordre encode la logique critique sur laquelle l'entreprise s'appuie. Sans cela, rien ne fonctionne. Chaque élément était nécessaire pour résoudre le problème de l'utilisateur.
  2. Il utilise une technologie légèrement obsolète. Les programmeurs actuels semblent penser que s'il n'utilise pas de magie de modèle, c'est juste un gâchis. C'est une vue brisée. Quiconque arrive en retard à un projet plus important aura cette étape tout en apprenant tous les détails.
  3. Les exigences qui étaient critiques il y a quelque temps ne le sont plus. En effet, le logiciel a déjà résolu ces problèmes. En arrivant tard dans le projet, il peut sembler que le logiciel est complexe sans raison valable - le problème n'existe plus, mais la complexité du code est toujours là.
tp1
la source
Ce type d'attitude amène les programmeurs à excuser l'énorme dette technique qu'ils encourent par ignorance ou paresse. Le travail d'un programmeur consiste à coder la logique métier à l'aide d'abstractions. Les spécificités mutables devraient vivre dans des métadonnées, pas des nombres magiques codés en dur. Deuxièmement, «légèrement dépassé» peut être subjectif. À mon humble avis, «légèrement obsolète» signifie que le cadre / la plate-forme est toujours activement développé, et j'ai un chemin de mise à niveau. L'alternative est «obsolète». Le numéro 3 est inexcusable. Vous venez de décrire la cruauté. Personne n'a refactorisé ou nettoyé la base de code, et cela est-il acceptable?
Jason Lewis
bien sûr, mais quel est le résultat après avoir codé la logique métier à l'aide d'abstractions ... Le code va paraître compliqué. C'est la définition du "gâchis". le (3) n'est pas vicié, car la complexité est toujours requise; le besoin de l'avoir n'a pas disparu même après la résolution du problème.
tp1