Comment puis-je être payé pour réduire la dette technique?


16

Je travaille actuellement pour une petite entreprise qui a peu de produits techniquement compliqués. Je suis le seul et unique développeur pour l'un d'eux. Il y a environ un an, j'ai obtenu la version héritée du produit et j'ai commencé à la "prendre en charge".

Le client ne parle que de nouvelles fonctionnalités, de valeur commerciale et d'autres de ce type. Le problème est que, bien que le code soit en C #, il est assez procédural. Il n'y a pas d'abstractions, les classes ne sont utilisées que lorsque Visual Studio en a besoin - Formulaires, par exemple. Les implémentations de ces classes sont vraiment horribles et le code est vraiment difficile à maintenir.

Pendant toutes ces années, je passe mon temps à refactoriser. Dans la dernière version, il y a de jolies abstractions et autres. J'ai dû réimplémenter un certain nombre de composants à partir de zéro et je pense vraiment que l'ajout de nouvelles fonctionnalités ou le changement de comportement à ces composants est BEAUCOUP plus facile qu'à d'autres.

Le problème est que je passe mon temps. J'aime vraiment les résultats, mais je n'aime pas travailler 12 heures par jour. Avez-vous déjà été dans une situation similaire? Que dois-je essayer? J'ai déjà essayé d'en discuter, mais toujours pas de succès.

J'ai juste peur du moment où nous décidons de mettre en œuvre la nouvelle fonctionnalité qui nécessite de nombreuses modifications du code hérité. Cela pourrait choquer le client: pourquoi avez-vous besoin de 8 heures pour changer ces icônes? Le client ne se soucie simplement pas qu'il y ait 500 places dans le code que je dois changer. Et je devrais aussi trouver tous ces 500 places en premier.

Des idées?


3
Quelle est ta question? Si vous êtes un employé, pourquoi avez-vous ce code et pourquoi l'avez-vous modifié par vous-même? Qu'est-ce que tu veux? Pour être rémunéré pour votre temps non rémunéré à y travailler? Ou tout simplement pour travailler moins d'heures? Votre employeur sait-il que vous avez amélioré votre temps libre? Votre question est sans réponse car elle est actuellement rédigée.
Robert Harvey

3
OK, alors quelle est votre question spécifique? Pourquoi voudriez-vous le garder procédural si l'architecture que vous avez développée à votre rythme est meilleure?
Robert Harvey

8
Ils ne parlent pas votre langue, vous devez donc apprendre la leur. Voilà comment c'est très SOUVENT. Ce n'est pas une raison pour s'enfuir, car c'est comme ça presque partout. Vous avez besoin d'une raison à moitié vraie mais plausible pour intégrer un autre BON codeur à bord, puis intégrer le temps de reconditionnement. Sinon, faites de votre mieux pour compléter vos propres estimations et ajouter du temps de recomposition à tout projet que vous faire. Les gens d'affaires ont généralement un faible pour quelque part. Certaines tâches sont plus importantes que d'autres à leurs yeux. Remplissez les "grands". Oh, et n'oubliez pas d'écrire des tests :) Aussi, continuez de faire les heures supplémentaires pour l'instant - invstmnt
Job

2
@Robert Harvey, le demandeur sait comment faire les choses correctement, mais est coincé avec la merde de quelqu'un d'autre et est le seul à voir de nombreux risques, est le seul à être responsable de la faute de la merde. La petite entreprise essaie de survivre et ses ventes / revenus sont agressifs, mais la dette technique croissante le stresse sans que d'autres le reconnaissent. Il a besoin d'une feuille de route et de conseils pour sortir de ce trou.
Job

1
J'ai changé le titre de votre question. Espérons que le nouveau titre reflète plus précisément votre intention. Je ne suis pas sûr que vous puissiez récupérer les heures perdues; Je ferais ce que les autres suggèrent et ajouterais du rembourrage à certaines de vos estimations afin qu'il y ait de l'argent disponible pour incorporer vos améliorations.
Robert Harvey

Réponses:


37

Étape 1: arrêtez de faire des heures supplémentaires non rémunérées.

Vous avez déjà formé votre client et manager depuis un an à croire que le rythme de développement actuel est ce à quoi il faut s'attendre. Cela fait partie de la raison pour laquelle ils ne comprennent pas pourquoi une chose "simple" pourrait prendre une journée entière à faire. Vous n'avez pas besoin de les garder en otage et de tenter de nuire au projet. Mais vous devez expliquer que leurs attentes sont trop élevées et vous avez besoin d'un autre développeur ou plus de temps avant la date limite. Assurez-vous de mentionner spécifiquement à votre gestionnaire que vous avez effectué des heures supplémentaires non rémunérées et que vous prévoyez de ne pas en faire autant. Même si vous le réduisez à 9 heures par jour, la différence sera remarquée. Si votre manager vous demande pourquoi vous ne faites pas votre travail, vous pouvez signaler que vous avez tenu à l'avertir que ce serait le cas.

Étape 2: prendre des notes

Ce n'est pas parce que vous n'avez pas le temps de faire le travail que vous ne pouvez pas le rendre plus facile lorsque le travail (espérons-le) est terminé. Gardez une trace des idées que vous avez pour corriger le code et faites-les apparaître lors des réunions afin que les autres soient conscients de vos préoccupations. Finalement, vous atteindrez un patch lent ou les gens commenceront à comprendre que vos préoccupations ont de la valeur. Lorsque ce moment arrivera, vous aurez déjà quelques idées de base sur ce qu'il faut faire au lieu de le voir à sec car vous n'avez pas regardé une section de code depuis un moment.


ce que vous dites sont des idées absolument géniales. Il y a environ un mois, j'ai décidé d'ajouter des tâches dans notre bug-tracker. Peu m'importe que cette tâche ne soit pas confirmée, chaque fois que je vois un problème potentiel, j'ajoute une tâche et j'informe le client. La prochaine fois que je devrai réparer quelque chose que j'attendais dès que possible, je rappellerai simplement au client la tâche que j'ai déjà créée il y a quelques mois. J'espère que cela pourra aider.
Andrey Agibalov

17
«Arrêtez de faire des heures supplémentaires non rémunérées» devrait s'appliquer même si vous aimez absolument le travail. Vous ne bénéficiez pas de vos heures supplémentaires; elles sont. Si vous voulez passer du temps devant l'ordinateur, faites-le pour vos projets, chez vous.
Christopher Mahan

1
Après plus d'une décennie dans cette industrie, je n'ai encore jamais "touché un patch lent". Qu'est-ce que je fais mal?
sbi

@sbi Je pense que cela pourrait être "bien faire les choses" :)
Stephen

13

... le code est vraiment difficile à maintenir.

C'est votre chemin avec la direction. Démontrez que le coût de la «correction» des bogues et de l'ajout de nouvelles fonctionnalités est supérieur à celui de la refactorisation et de la réécriture du code.

Par exemple, si avec le code actuel, une nouvelle fonctionnalité prendrait 2 semaines à ajouter et ensuite un temps considérable à maintenir (par exemple 1 jour par semaine), montrez qu'avec une refactorisation d'une semaine, vous pouvez faire le développement en 1 1/2 semaines mais que vous réduirez l'entretien à 1 jour par mois (ou moins). Ces chiffres montreront que ce que vous faites est rentable à moyen et long terme même s'il y a un coût à court terme.

Bien que l'entreprise n'aimera peut-être pas dépenser de l'argent maintenant, elle verra que les avantages potentiels sont beaucoup plus importants - c'est-à-dire que vous serez plus productif en générant plus de code en moins de temps et que le code sera de meilleure qualité.


7

Appliquez la règle du boy-scout : laissez le code un peu plus propre (c'est-à-dire avec moins de dettes techniques) chaque fois que vous le touchez.

Prévoyez du temps pour le faire dans toutes les estimations que vous donnez. Ensuite, comme par magie, avec le temps, la dette technique disparaîtra et vous aurez été payé pour cela.

Cette approche est beaucoup plus facile que d'essayer explicitement de gagner du temps (et donc de convaincre les clients / gestionnaires de payer) pour la dette technique. Cela vous donne un sentiment beaucoup plus grand de professionnalisme et un "travail bien fait". Et enfin, vos clients et managers vous en remercieront à long terme, même s'ils ne comprennent pas très bien comment cela s'est passé .....


Cependant, cette approche rendra impossible toute refactorisation plus substantielle.
sbi

1
@sbi - vous seriez surpris: si vous avez de bons tests unitaires en place et un SCM décent pour la restauration, vous pouvez faire beaucoup en étapes contrôlées et vérifiées. J'ai une fois changé une grande hiérarchie d'héritage (classe 50+) en un modèle basé sur un prototype dans une série de refactorisations incrémentielles, dont aucune n'a nécessité plus de quelques heures de travail.
mikera

@sbi: Il ne faut jamais faire de refactoring substantiel - juste un changement / refactoring à la fois. De petites unités de travail, de petits changements, et bien sûr l'exécution de tous les tests et autres pour vous assurer (doublement) que vous n'avez rien cassé.
Cthulhu

@Cthulhu: Si vous avez de bons tests unitaires, vous pouvez supprimer et reconstruire presque autant de code que vous le souhaitez, car les tests détecteront la plupart des erreurs.
sbi

4

C'est plus ou moins la triste réalité des programmes de maintenance. Vous êtes coincé avec ce que vous êtes chargé de maintenir et si la personne qui paie les factures ne veut pas payer ce qu'il considère être des changements sans avantages sociaux, alors ces changements ont tendance à ne pas se faire.

Si vous souhaitez justifier le financement de ces modifications, conservez un journal de tous les emplacements que vous devez modifier, même pour la mise à jour la plus simple. Après quelques modifications, discutez de ce journal avec votre responsable. Si vous pouvez le documenter, il y a une chance (bien que très mince) que la personne avec les cordons de la bourse se rende compte qu'il est en fait moins cher à long terme de nettoyer le code maintenant car cela rendra les changements futurs moins chers.

Vos chances de vendre ce produit augmentent avec la durée d'utilisation de ce produit. Les chances augmentent également si une défaillance du produit est susceptible de provoquer un problème de relations publiques pour le client ou de coûter de l'argent au client.

Sauf cela, apprenez ce que vous pouvez et passez à une autre position avec moins d'entretien.


3

Vous devez montrer à votre direction comment la refactorisation et l'amélioration du produit bénéficieront à l'entreprise.

Le client ne se souciera probablement pas de savoir si le code est beau ou laid tant qu'il fonctionne, et la direction ne sera pas impatiente d'expliquer au client que ce qu'il a déjà payé a été mal conçu et mal mis en œuvre. Dans le même temps, la direction ne sera pas impatiente de consommer le coût du temps de développement qui n'améliore pas le produit d'une manière visible (facturable).

Alors ... vous devez convaincre la direction que les changements que vous proposez aideront l'entreprise:

  • Montrez-leur qu'une meilleure architecture vous permettra d'ajouter de nouvelles fonctionnalités plus rapidement.
  • Expliquez qu'en continuant le long du chemin actuel, ils vont se peindre dans un coin.
  • Donnez des exemples de modifications très coûteuses à effectuer dans le système actuel, mais qui seraient simples et bon marché avec une meilleure conception.
  • Gardez une trace du temps passé à maintenir le code hérité par rapport à l'ajout de fonctionnalités vendables. - Aidez-les à expliquer aux clients actuels et futurs que, même si le système existant était plutôt bon, la nouvelle architecture modernisée permettra de nombreuses nouvelles améliorations, une meilleure fiabilité, etc.
  • Atténuez le risque associé aux changements que vous proposez. Les gestionnaires sont peu enclins à prendre des risques, et les modifications radicales d'un système existant semblent intrinsèquement risquées.
    • Priorisez la modernisation des différents composants en fonction des coûts et des avantages et assurez-vous que la direction est en accord avec vos priorités.
    • Utilisez les tests unitaires pour vous assurer que les composants modernisés seront compatibles avec le code hérité restant.
  • Suivez l'avancement de l'effort de modernisation. Montrez les avantages dès que possible, mais rappelez à toutes les parties qu'il reste du travail à faire.

3

Vous ne le réalisez peut-être pas, mais Johnny Cash a prédit le mouvement de refactoring et a écrit une chanson sur la meilleure façon de refactoriser une grande base de code existante.

Bien sûr, il a dû l'envelopper dans une métaphore automobile pour que son public puisse s'y identifier.

"Une pièce à la fois" - Johnny Cash


2

Il semble que vous puissiez facturer au client le temps que le changement "devrait" prendre et que vous en sortirez bien à long terme.

Si vous aimez nettoyer le code (et il semble que vous en fassiez au moins un peu), allez-y et continuez à le faire, mais ne vous épuisez pas. Cela ne fait aucun bien à vous, à votre entreprise ou à vos autres clients.

Assurez-vous que votre direction et toute personne travaillant avec le client savent que le code n'est pas dans la meilleure forme afin qu'ils puissent prendre une décision éclairée - ce n'est pas parce que vous êtes propriétaire de ce code que vous devriez prendre les décisions commerciales à ce sujet, s'ils ne sont pas conscients des problèmes avec le code, ils ne peuvent pas faire leur travail.


1
@robertharvey: oui, il nettoie le code à son propre rythme afin que le client qui serait facturé pour les mises à jour n'ait pas à payer plus que si le code était bien écrit. Je pense que son entreprise doit manger la majorité des coûts (s'ils se produisent). Il est raisonnable que le client paie une partie du temps, mais si vous surfacturez parce que le code est de la merde, c'est un bon moyen de perdre la bonne volonté et les affaires futures.
DKnight

2

Bien que l'application du client ait une dette technique, n'oubliez pas, ils ont probablement été facturés avec une légère remise. Ils n'ont peut-être pas été informés de cela, mais c'est ce qui se produit lorsque vous prenez l'offre la plus basse.

Ils doivent décider s'ils veulent payer le prix fort pour les changements de fonctionnalités ou s'en passer. C'est leur choix. Vous pouvez les laisser prendre la décision ou continuer à travailler gratuitement. Vous pouvez essayer de mentionner le travail de nettoyage que vous avez effectué et offrir une légère remise pour le travail terminé. Encore une fois, c'est leur choix.


1

La façon dont j'aborderais cela est de commencer par expliquer le concept de dette technique à vos patrons pour vous assurer qu'ils l'obtiennent. Abordez-le d'un point de vue commercial et commercial Chaque fois qu'ils demandent une nouvelle fonctionnalité, la dette technique accumulée dans le produit affecte votre efficacité, et chaque fonctionnalité coûte donc un peu plus en raison de cette dette.

Une fois qu'ils ont compris de quoi vous parlez, essayez de négocier un peu de votre temps pour réduire la dette technique. Dans mon entreprise, nous avons réussi à pétitionner 10% du temps de chaque développeur afin de travailler sur la réduction de la dette technique.

Une fois que vous avez du temps pour travailler sur cela, assurez-vous de l'utiliser réellement (et ne faites pas seulement 10% d'heures supplémentaires pour le faire - respectez vos armes). Créez un catalogue des éléments de dette technique, hiérarchisez-les et commencez à découper. Vous devez manger l'éléphant une bouchée à la fois.


1

Et n'oubliez pas de prendre en compte de meilleurs outils. Resharper est un excellent outil de refactoring qui se connecte à Visual Studio.

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.