Un nombre surprenant de problèmes de qualité, d’évolutivité et de charge se sont produits dans une application que je supporte actuellement et que je n’ai pas écrite à l’origine. Heureusement, j'ai de nouveaux projets que j'ai entrepris depuis le début pour conserver un semblant de santé mentale.
L'équipe initiale comprenait 20 développeurs (la plupart d'entre eux avec des compétences obsolètes), aucun document d'exigence professionnelle ni testeur d'assurance qualité, et mal géré dès le début de manière cascade. Les débuts de la production étaient un cauchemar embarrassant qui consistait à appliquer des correctifs encore plus fragiles à un code semblable à une procédure. Des fonctionnalités ont été ajoutées par la suite et ont été incorporées dans un modèle de données qui n’a jamais été conçu pour les prendre en charge. Il n’est pas rare de voir le même code dupliqué 10 fois et de voir les ressources ne pas être fermées en toute sécurité et les requêtes ORM qui extraient des dizaines de milliers jeter tout sauf une poignée.
C’est juste moi maintenant et chaque fois qu’un nouveau problème surgit, je réécris un module afin d’améliorer les normes et de le rendre BEAUCOUP plus stable, mais la direction a besoin d’une explication appropriée sur les raisons de tout cela.
Ils semblent choqués et perplexes à l'idée que cette application est de mauvaise qualité et qu'elle se noie dans la dette technique. Heureusement, ils comprennent le concept de dette technique et me soutiennent dans ma quête pour l’éradiquer. Ils me soutiennent et me remercient beaucoup, mais j’ai le sentiment que je ne fais que blâmer l’équipe initiale (qui est partie pour ruiner un autre projet dans un autre division).
En fin de compte, je ne veux pas être "ce type" qui se plaint toujours des développeurs du projet qui le précède. J'ai déjà vu cette attitude de personnes de ma carrière qui, à mon avis, étaient ignorantes et ne tenaient pas compte des circonstances et des influences conceptuelles qui encourageaient les choses à être comme elles étaient.
Habituellement, je vois cette attitude de blâmer l’ancienne équipe pour la mauvaise conception et la mauvaise mise en œuvre de développeurs juniors idéalistes qui n’ont pas vécu les expériences de la vie vécues par les membres plus âgés.
Pensez-vous qu’il existe une meilleure façon, peut-être plus douce, de signaler ce type de problèmes à la direction sans compromettre la réputation de la personne / de l’équipe qui vous a précédé?
la source
bad-codeparce que le code cause effectivement des bugs et des problèmes. Je l'ai étiquetébad-programmerparce que je crains d'en devenir un en blâmant l'équipe précédente, une excuse fatiguée et clichée que nous avons tous déjà entendue. En ce qui concerne les trois premiers paragraphes, je n'ai peut-être pas besoin d'être aussi descriptif, mais je voulais brosser un tableau fidèle de ma situation immédiate et donner l'historique de ce que j'ai rassemblé jusqu'à présent.Réponses:
La dette technique est comme une dette financière. Vous le prenez (espérons-le) de manière stratégique dans le développement d'un programme avec l'intention de le payer à l'avenir. Parfois, les gens prennent de mauvaises décisions en matière de dette technique (par exemple, utiliser une carte de crédit), mais parfois, un certain montant de dette technique est tout simplement normal. Il est tout à fait normal de décider de ne pas consacrer le temps nécessaire à la réalisation du projet "correct" aujourd'hui, en partant du principe qu'il devrait être modifié à l'avenir. Bien sûr, la ligne est fine, mais le fait de penser que vous le ferez correctement dès le premier essai peut engendrer son propre ensemble de problèmes (paralysie de l'analyse).
En fin de compte, tout projet non négligeable qui dure plus de deux ans devra consacrer du temps supplémentaire au développement en réduisant la dette technique. Le fait est que cela est vrai même si vous écrivez votre application correctement . Sinon, vous accumulez de la dette, et la direction peut certainement comprendre cela si vous la présentez ainsi.
Expliquez-le à la direction et au lieu de "blâmer" l'équipe précédente à tout moment, vous pouvez présenter ceci comme étant "comme d'habitude".
la source
OMI, vous vous en sortez déjà dans le bon sens: vous ne proposez pas une réécriture de fond en comble parce que "l'ancien code est nul", mais vous corrigez une chose à la fois.
Pour ne pas avoir l’impression de blâmer l’ancienne équipe, imaginez qu’elle devait probablement produire ce code avec une grande pression temporelle. La direction à cette époque ne comprenait probablement pas vraiment que le fait que le code "fonctionne plus ou moins" ne signifie pas qu'un entretien est possible sans beaucoup de peine et de travail supplémentaire.
Appréciez l’ancienne équipe qui a réussi à créer un produit qui apporte réellement une valeur commerciale - il ne serait plus utilisé s’il ne le faisait pas. Vous serez peut-être surpris de la fréquence à laquelle un projet ne parvient pas à générer de la valeur commerciale, même s'il est magnifiquement écrit.
la source
Quand on me demande de commenter l’état actuel d’un produit problématique, je me rabat toujours sur «c’est ce qu’il est», puis je commence à parler de plans pour l’améliorer.
Vous ne connaissez pas tous les facteurs qui ont contribué à la création du problème - ils étaient peut-être même raisonnables à l'époque. Tout ce que vous pouvez faire, c'est avancer et améliorer les choses demain. Et on dirait que vous faites du bon travail - vous avez la bonne attitude face à cette situation.
Concentrez-vous uniquement sur le fait de rapporter des faits lorsque vous y êtes invité Vous n'avez pas à ajouter de récit ou de commentaire. il suffit de dire "le système échoue dans le cas X" ou "les rapports sont incorrects pour le cas Y". Ajoutez ensuite rapidement comment vous envisagez d’améliorer la situation actuelle.
la source