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

20

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.
Joseph
la source
3
@gnat, je pense que les questions sont liées (en particulier la dernière), mais pas les doublons. Je vois cette question comme «étant donné que l'architecte d'un système n'est pas l'implémenteur et que les implémenteurs n'ont pas une vue de haut niveau du système, comment peut-il être assuré que les implémentations sont suffisamment flexibles ou évolutives?
MetaFight
1
Demandez-vous comment lutter contre la dette technique en général, ou demandez-vous comment lutter contre la dette technique lorsque vous êtes dans le rôle d'un codeur sans responsabilité assignée pour améliorer l'architecture?
Doc Brown
2
@JosephtheDreamer Oui, il y a beaucoup de choses qui peuvent être faites pour améliorer le code source, mais vous avez déclaré dans votre question que le problème est un manque d'autorité pour agir sur les changements. Je pourrais vous dire toutes les meilleures pratiques, mais si vous n'êtes pas autorisé à investir énormément de temps pour les mettre en œuvre, alors quel est l'intérêt? ;)
Reactgular
2
" Mais les tâches viennent des personnes supérieures " - qu'est-ce qui vous empêche de vous confier certaines tâches, à part " Je ne suis pas payé pour ça " aujourd'hui? Si vous agissez comme une abeille ouvrière recevant des commandes, vous serez traité comme tel.
JensG

Réponses:

22

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:>
http://i.stack.imgur.com/ARBSs.jpg


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» 1 ...

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.

moucheron
la source
7
+1 Bon conseil, mais le suivi des problèmes dans un environnement qui n'embrasse pas le processus devient simplement un trou noir. À quoi sert un outil de suivi des problèmes d'une personne. Au mieux, une liste de choses à faire.
Reactgular
@MathewFoscarini avant de poster, j'ai clarifié cela avec OP dans les commentaires (liés sous "votre système de suivi des problèmes" dans ma réponse) - 'Oui, d'où les "tâches" (problèmes, tickets, peu importe comment vous les appelez) ...' Je ne serais pas non plus pessimiste à propos des cas de "trou noir", à long terme, les choses ont tendance à changer, surtout si les développeurs de "niveau le plus bas" prennent une initiative et investissent des efforts pour maintenir le tracker et promouvoir lui-même son utilisation ( )
moucher
Et en plus, j'ai vu des gens blâmer pour avoir pollué le système de tickets (= ouvrir "trop" de tickets). Si la culture ne convient pas, aucun système de ticket ne sera utile. Malheureusement, techniquement, les gens ont tendance à rechercher un outil technique plutôt qu'une solution, et d'autres techniciens le considèrent comme un bon conseil car il correspond à leur processus de réflexion.
JensG
1
@JensG "personnes accusées d'avoir pollué le système de tickets" - c'est un phénomène connu, qui mérite probablement une question dédiée (ou peut-être a-t-on déjà posé une question et répondu, je n'ai pas cherché). Si la culture ne convient pas, des efforts spécifiques supplémentaires sont nécessaires pour que le système de tickets devienne utile (comme je l'ai écrit dans un commentaire précédent, je l'ai déjà vécu).
moucher
8

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.

JensG
la source
8

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).
svidgen
la source
Cette réponse est exactement ce que je ferais. Je ne mets pas de petites tâches de refactoring dans le suivi des problèmes. Je refaçonne juste. Mettre chaque petite dette technique dans l'arriéré des problèmes crée simplement une énorme liste de problèmes, ce qui rendra difficile pour eux de gagner en visibilité, et au moment où quelqu'un travaille sur une telle tâche, le problème peut avoir disparu, changé de forme , empiré, ému ou qui sait quoi. Si cela prend 5 minutes, corrigez-le!
Brandon
5

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.

DougM
la source
2
"La dette technique provoque rarement l'échec de l'emploi d'une entreprise." Je n'en serais pas si sûr. La raison de l'échec de nombreux projets logiciels est une dette technique.
Euphoric
2
Un projet n'est pas une entreprise, @Euphoric. Mozilla n'est pas disparu juste parce que Sunbird n'a jamais décollé. Si votre projet échoue, vous passez à un nouveau projet avec le même employeur. Si votre entreprise échoue, vous devez trouver un nouvel emploi.
DougM
Cette réponse est très fausse. J'ai vu une dette technique détruire un produit d'entreprise. Et quant à «techniquement, la dette n'est littéralement pas votre problème», à qui incombe-t-il, sinon aux développeurs de logiciels?
Brandon
2

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.

accolade
la source
4
est-ce seulement votre avis ou vous pouvez le sauvegarder d'une manière ou d'une autre? Au niveau OP ("le plus bas"), "marcher sur le frein, dire non" dans mon expérience s'est rarement avéré correct. Ni pour le projet, ni pour la carrière. Avec le recul, je me souviens clairement des cas où j'ai raté une chose ou deux en "disant non" contre la vision des collègues seniors / lead / manager
gnat
En termes de ressources humaines, mettre les gens derrière des tickets de travail sans gérer correctement leurs préoccupations de valeur au travail est susceptible de se terminer par une catastrophe. Des travailleurs heureux travaillent plus pour moins, il y a une preuve économique de cela. Appuyer sur les freins est une opportunité d'apprentissage pour le junior et la direction. Faire un pas sur les freins est la façon dont les startups peuvent être si compétentes en si peu de temps, nous n'avons pas de tickets. Cela peut déclencher un conflit, mais le conflit fait partie de la putain de vie. Le souci de la qualité doit être écouté et appliqué, je suis donc du côté des freins.
Arthur Havlicek
2
Je recommande cette lecture qui traite des développeurs de bas niveau habilitant joelonsoftware.com/articles/TwoStories.html
Arthur Havlicek