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 add
devient 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.
Réponses:
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).
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.
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 :
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.
la source
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.
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.
la source
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:
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 .
la source
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.
Dans l'exemple que vous avez fourni, avec une
add
fonction 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.
la source
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.
la source