Lutter contre la dette technique en tant que «développeur le plus bas»?

Disons que vous travaillez pour une entreprise et que vous développez des logiciels pour eux. Vous n'avez aucune idée de la vue d'ensemble ou peut-être légère. Ce que vous avez, ce sont des tâches qui vous sont assignées via le système de suivi des problèmes. On vous confie des tâches, vous les faites fonctionner comme la tâche les décrit, vous les renvoyez. Comme ajouter 2 entiers:

function add(a,b){return a + b;}

Mais plus tard, au fur et à mesure que le projet avance, vous remarquez qu'à mesure qu'il adddevient plus complexe, vous vous rendez compte qu'il aurait dû nécessiter une certaine forme d'architecture, plus qu'une simple fonction qui ajoute des paramètres et renvoie une valeur. Mais vous ne le saviez pas. En premier lieu, tout ce dont ils avaient besoin était aussi simple que cela add. Vous ne vous attendiez pas à ce que add devienne si complexe.

Le projet progresse avec plus de fonctionnalités, que vous ne vous attendiez pas à avoir en premier lieu. Et à la fin, vous continuez à empiler des hacks et couche sur couche de fonctions pour éviter de casser / réécrire le code existant.

Comment gérez-vous ces situations? Comment combattez-vous la dette technique en tant que "développeur le plus bas"?

Clarification:

• Vous êtes le "réalisateur", le plus bas de la hiérarchie.

• Vous voyez le problème, mais n'avez rien à dire sur la question.

• Je ne quantifie pas la dette technique ni ne cherche des outils.

• Concernant le troisième "duplicata"

  • Refactoring & Rewrite - Vous êtes verrouillé sur vos tâches. Vous n'êtes pas payé pour faire un supplément.
  • Présentation de l'architecture - Vous connaissez le système global, mais vous n'avez aucune idée de l'architecture.
  • Gel de code - Pas votre appel. Vous n'êtes pas gestionnaire.
  • Modularisation - Aucune idée de l'architecture. Les modules changent à mesure que les exigences changent.
  • Tests automatisés - Aucun n'existe.

Chaque fois que vous remarquez quelque chose comme ça, entrez un nouveau ticket dans votre système de suivi des problèmes.

Prenez l'habitude d'utiliser l' outil de suivi des problèmes comme outil principal pour communiquer des trucs comme ça, car à partir de là, il sera facile de choisir, d'évaluer et de hiérarchiser pour vos collègues seniors / lead / manager / quiconque est responsable du suivi des problèmes dans votre projet .

Utilisez le bon outil pour le travail. Je le fais toujours et je vous recommande fortement de faire de même.

À titre d'exemple, voici un ticket que j'ai créé il y a environ un mois. À la fin d'une fonctionnalité particulière, j'ai découvert que le code était devenu beaucoup plus compliqué qu'auparavant, mais je ne peux pas résoudre ce problème dans le délai imparti pour la mise en œuvre de la fonctionnalité.

(Les noms des fonctionnalités, des tickets et du code utilisés dans le véritable tracker sont masqués, mais le texte est copié tel quel).

Résumé: simplifiez la conception enParticularPieceOfCode

Description:
Au cours de la mise en œuvre par TICKET-12345, le code impliquant l'utilisation de ParticularPieceOfCodecompliqué a un peu compliqué et est devenu assez difficile à lire, à comprendre et à maintenir (voir l'exemple d'extrait de code ci-dessous).

Trouvez un moyen de le simplifier.

Un exemple de code qu'il serait souhaitable de repenser peut être trouvé dans ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW mes conseils s'appliquent indépendamment de votre "niveau".

Je l'ai utilisé à votre niveau actuel ("le plus bas") et je l'utilise maintenant que mon niveau est assez loin du "plus bas" et j'ai un "dire" satisfaisant comme vous l'appelez, et je vais l'utiliser toujours quoi qu'il arrive.

Pensez-y juste, pas de niveau, peu importe le degré d'autorité dont vous disposez, il n'y a tout simplement pas de meilleure façon.

Si vous "dites" que nous avons un problème , ce n'est que cliquetis. Et même si votre patron / lead est d'accord et dit que vous avez raison, nous avons un problème , cela ne change rien - ce n'est encore qu'une fois des cliquetis d'air, et cela ne peut pas être autre chose.

• ^{Vous pensez peut-être qu'avoir votre mot à dire (par exemple dans un e-mail) serait mieux, mais si vous y pensez, ce n'est vraiment pas le cas. Si votre projet a une activité de courrier importante, ce qui a été écrit sera perdu et oublié un mois plus tard.}

Utilisez le bon outil pour le travail. Pour le travail que vous décrivez, l'outil de suivi des problèmes est exactement le bon outil.

Vous remarquez le problème, vous le saisissez dans un système conçu pour les suivre et il s'occupe du reste, de la meilleure façon possible - simplement parce qu'il a été conçu pour cela :

progiciel qui gère et tient à jour des listes de problèmes , selon les besoins d'une organisation ... couramment utilisé ... pour créer, mettre à jour et résoudre les problèmes signalés par les clients, ou même les problèmes signalés par les autres employés de cette organisation ... Un suivi des problèmes système est similaire à un " bugtracker ", et souvent, une société de logiciels vendra les deux, et certains bugtrackers sont capables d'être utilisés comme système de suivi des problèmes, et vice versa. L'utilisation cohérente d'un système de suivi des problèmes ou des bogues est considérée comme l'une des «caractéristiques d'une bonne équipe logicielle» ¹ ...

Quels que soient les autres moyens que vous souhaiteriez choisir pour communiquer, avoir un ticket dans tracker ne fera que vous faciliter la tâche.

Même si vous préférez faire vibrer l'air , dire "Je voudrais discuter du TICKET-54321 ..." fait un point de départ plus solide que "Écoutez, je voudrais parler d'un morceau de code que j'ai traité il y a un moment ... "Et vous pouvez transmettre en toute sécurité les références au ticket par mail: même en cas de perte de mail, le problème sera toujours là dans le tracker, avec tous les détails dont vous vouliez parler.

Ce qui me fait me sentir mal à propos de votre scénario, c'est exactement ce que vous avez écrit dans le titre et plusieurs fois dans le texte de la question:

Vous êtes le développeur le plus bas de la chaîne

Pourquoi ce point est-il si important? Eh bien, tout d'abord, et d'un point de vue purement technique, vous avez certainement raison. Vous êtes embauché comme ce que vous appelez un «exécutant» des choses, une abeille ouvrière qui agit sur les commandes données.

Mais même si vous êtes le développeur le plus bas en termes de classement, ce n'est toujours pas tout à fait raison. La clé ici est de réaliser que vous ne vous percevez que comme le développeur le plus bas. Avez-vous déjà essayé de surmonter cette perception de soi et d' assumer la responsabilité de quelque chose ?

Prendre! N'attendez pas, jusqu'à ce que quelqu'un vous rende responsable.

• Vous voyez le problème, mais n'avez rien à dire sur la question.
• Je ne quantifie pas la dette technique ni ne cherche des outils.
• Vous êtes verrouillé sur vos tâches. Vous n'êtes pas payé pour faire un supplément.
• Pas votre appel. Vous n'êtes pas gestionnaire.

Généralement, c'est tout le contraire: vous êtes mieux payé et votre opinion est plus respectée, une fois que vous avez démontré que vous en valez la peine . C'est "à faire avant", et non l'inverse.

Ce que j'attends des gens de mon équipe, c'est exactement cela: un sens des responsabilités pour le projet ou le produit que nous essayons de construire et pour tous les processus liés à cet effort. Chaque fois qu'un membre de mon équipe m'impressionne en prenant des responsabilités, par exemple en proposant des améliorations ou encore mieux en commençant à améliorer les choses par lui-même, ce sont les personnes qui seront promues.

En d'autres termes: personne ne promeut les abeilles ouvrières, les gens attendant passivement que des tâches leur soient assignées, sans même le moindre clin d'œil " car ils ne sont pas payés pour cela" ", se plaignant finalement qu'ils n'ont jamais eu chance.

Bien sûr, tout cela dépend encore une fois de la culture de votre entreprise, de ce à quoi Joel se réfère dans les "Deux histoires" liées par Arthur. Si les chefs d'entreprise sont vraiment stupides pour empêcher leurs propres employés de progresser, le taux de fluctuation est probablement déjà très élevé et il est peut-être temps d'en tirer des conclusions. Mais si ce n'est pas le cas, le vrai problème pourrait être en vous.

Tu es un professionnel. Votre employeur vous a engagé pour être professionnel. Donc, traitez vos préoccupations de la même manière que vous voudriez que les professionnels que vous embauchez traitent leurs opinions professionnelles . En particulier, vous vous attendez à ce que d'autres professionnels fassent les optimisations et corrections nécessaires en cours de route, à condition que ces optimisations n'augmentent pas le coût de manière inattendue.

Par exemple, supposons que vous ameniez votre voiture chez un mécanicien pour faire remplacer une lampe. Le mécanicien remarque quatre choses:

1. Le fil menant à la lampe est effiloché et dangereux. Mais, il peut être coupé sans augmenter notablement le coût. Vous vous attendriez à ce qu'il prenne quelques minutes pour couper le fil, sans même le remarquer.
2. Un boulon est desserré. C'est totalement sans rapport, il vient juste de le voir. Il lui reste 20 secondes pour saisir le pilote nécessaire et le serrer; vous vous attendriez donc à ce qu'il le fasse.
3. Le châssis de la lampe est fissuré, ce qui fera cliqueter la lampe. Son remplacement coûte cher. Et ce n'est pas essentiel. Donc, il vous appelle pour vous en informer - si vous dites «non», il met une recommandation écrite sur le résumé de votre visite.
4. Il y a une bonne quantité de liquide de frein sous la voiture. Il devrait, et peut même être requis en tant que professionnel, pour vous empêcher d'utiliser la voiture jusqu'à ce que vous permettez à quelqu'un de réparer la fuite.

Chacun de ces scénarios, et je suis sûr que d'autres, ont des parallèles dans le développement de logiciels - surtout si vous vous considérez comme un professionnel de tout niveau . En tant que professionnel, à de très rares exceptions près, votre travail consiste à atteindre l'objectif final d'améliorer le produit d'une manière particulière en fonction de votre compréhension professionnelle .

1. Si le correctif est trivial, qu'il soit indépendant ou non, effectuez le correctif.
2. Si le correctif n'est pas trivial et inutile, faites une recommandation formelle en utilisant le mécanisme officiel de communication / suivi des problèmes que vous avez convenu.
3. S'il est possible de prouver que le correctif est nécessaire pour accomplir la tâche principale, mais qu'il augmentera de façon inattendue les coûts, communiquez le changement de portée.
4. Si le problème identifié constitue une menace sérieuse pour la réussite du projet, clarifiez-le. Officiellement. S'il y a des problèmes éthiques à laisser le problème non résolu (comme dans les systèmes de santé, d'urgence ou de transport), insistez pour régler le problème avant l'expédition du produit (informez les médias ou les autorités si cela est éthiquement nécessaire).

Vous faites cela de la même manière qu'un employé d'un cabinet juridique combat un comportement contraire à l'éthique, un travailleur de la restauration rapide lutte contre un comportement insalubre ou un agent de contrôle du stationnement lutte contre la corruption de la police.

1. Soyez un bon exemple. Dans la mesure du possible, produisez un code propre et sensé. Lorsque vous avez le choix, choisissez celui qui répond à vos exigences avec moins d'inconvénients. (Sachez que la dette technique n'est pas différente de la dette hypothécaire - le simple fait de l'avoir n'est pas nécessairement une mauvaise chose.)
2. Communiquez vos préoccupations . Vous devez avoir quelqu'un, un chef d'équipe ou un client ou un architecte, qui a la responsabilité réelle de gérer la dette technique et d'allouer les ressources de votre entreprise. Lorsque vous voyez quelque chose que vous croyez mauvais, faites-leur part de votre inquiétude. Mettez-le par écrit (c.-à-d. Un e-mail) si vous n'êtes pas sûr qu'il comprendra, répondra et donnera du crédit pour votre contribution.
3. Ne stressez pas. La dette technique provoque rarement l'échec de l'emploi qui met fin à l'emploi. Tant que vous avez fait part de vos préoccupations et que vous faites votre travail, les problèmes d'architecture tels que la dette technique ne sont littéralement pas votre problème. Oui, ils peuvent vous affecter, mais ils ne vous inquiètent pas plus que la réélection d'un shérif n'est celle d'un officier de police subalterne.

Dans l'exemple que vous avez fourni, avec une addfonction qui a subi un fluage complet des fonctionnalités, prenez quelques minutes et rédigez le contour de ce qui pourrait l'améliorer. Envoyez cela à toute personne dont vous auriez besoin d'une autorisation pour la mettre en œuvre, et passez à autre chose.

En supposant que votre entreprise était gérée par des personnes extrêmement compétentes et structurée correctement, soit votre préoccupation serait acheminée au concepteur de système approprié pour une décision, soit vous auriez une latitude pour mettre en œuvre votre suggestion. En tant que développeur junior, je m'inquiéterais davantage d'apprendre le fonctionnement de votre entreprise que de la dette technique - et si vous connaissez le premier, la façon de gérer le second devrait être évidente.

Je n'ai jamais entendu parler d'une organisation qui ne voulait pas que ses employés participent. Vous dites que vous n'êtes payé que pour faire les tâches. Je doute sincèrement que vous ayez à l'esprit les bonnes tâches. Parce que vous êtes payé pour écrire un bon logiciel.

Prenez cette responsabilité. Dites non à l'ajout de fonctionnalités si vous ne pouvez pas prendre en charge la base. Conseillez le client avec votre expertise. Appuyez sur les freins maintenant, avant qu'il ne soit trop tard et que vous deviez jeter tout le projet, car il ne sera plus maintenable.