Est-il normal que je ne puisse pas garder dans ma tête plus de trois bogues qui me sont attribués, ni comprendre mille lignes de code spaghetti?

Je travaille sur une ancienne base de code qui n'est ... pas parfaite , dans un environnement qui ne l'est pas non plus. Ce n'est pas la pire base de code que j'ai vue de ma vie, mais il y a encore beaucoup de problèmes: zéro test unitaire; méthodes avec mille + lignes de code; incompréhension des principes de base orientés objet; etc.

Cela fait mal de maintenir le code.

1. Chaque fois que je dois déboguer un millier de lignes d'une méthode mal écrite avec des variables réutilisées partout, je suis totalement perdu.
2. Quelques modifications ou refactoring que j'ai fait ont introduit des bugs dans d'autres endroits de l'application.
3. En l'absence de documentation, de tests ou d'architecture observable et combiné à des méthodes mal nommées, je sens que je remplis toute ma mémoire de travail disponible. Il n'y a plus de place pour toutes les autres choses dont je dois me souvenir afin de comprendre le code que je dois modifier.
4. Les interruptions constantes sur le lieu de travail me perturbent et me ralentissent.
5. Je ne me souviens pas de plus de deux ou trois tâches à la fois sans système de suivi des bogues, et je les oublie toutes le week-end.

Mes collègues ne semblent pas avoir des problèmes similaires.

1. Ils parviennent à déboguer des méthodes mal écrites beaucoup plus rapidement que moi.
2. Ils introduisent moins de bugs que moi lors du changement de base de code.
3. Ils semblent se souvenir très bien de tout ce dont ils ont besoin pour changer le code, même quand cela nécessite de lire des milliers de lignes de code dans vingt fichiers différents.
4. Ils ne semblent pas être dérangés par les e-mails, les téléphones qui sonnent, les gens qui parlent tout autour et les autres personnes qui leur posent des questions.
5. Ils ne veulent pas utiliser le système de suivi des bogues que nous avons déjà depuis que nous utilisons TFS. Ils préfèrent se souvenir de chaque tâche qu'ils doivent faire.

Pourquoi cela arrive-t-il? Est-ce une compétence particulière que les développeurs acquièrent en travaillant avec du code mal écrit pendant longtemps? Mon manque relatif d'expérience avec un mauvais code contribue-t-il à ces problèmes / sentiments? Ai-je des problèmes de mémoire?

Oui, il est normal que des personnes structurées soient affectées par du code / des environnements non structurés. Vos collègues filtrent probablement mieux tous les bruits de fond. En tant que migraine, je sais que ma capacité à filtrer mon environnement diminue considérablement lorsqu'une migraine se déclare. Les gens varient.

Il en va de même pour le code, vos collègues ont probablement appris à filtrer le "bruit de code" qui provient de plusieurs niveaux d'abstraction dans une seule méthode et sont devenus aptes à "découper" le code en de plus grandes zones de fonctionnalité.

L'adaptation à une base de code telle que celle que vous décrivez prend simplement du temps. Vos collègues ont probablement eu beaucoup plus de temps pour s'y développer et ont peut-être repris des conventions, des modèles et des constructions qui ne sautent pas aux «novices de la base de code». Il peut y avoir plus de structure dans le chaos que vous ne pouvez l'imaginer. Parlez à vos collègues, demandez-leur de se jumeler avec vous un peu de temps et choisissez leur cerveau sur la façon dont ils abordent la résolution de l'un des bogues qui vous sont attribués. Quand ils vous demandent d'ouvrir l'unité X, Y ou Z, demandez-leur pourquoi celle-ci, qu'en est-il en leur disant que cela peut être pertinent, etc.

Être perdu dans une méthode de mille lignes est normal. Attaquez-le avec un bon éditeur de pliage et ajoutez des commentaires pour découper les différentes parties en fonctions et / ou procédures sans vraiment le faire. L'impression des trucs et l'utilisation d'un surligneur à l'ancienne peuvent également aider.

Refactorer sans le filet de sécurité des tests unitaires, c'est se tirer une balle dans le pied. Non. Mais ne le fais pas.

Personne ne vous demande de tout garder en mémoire. Si vos collègues ne veulent pas ou n'ont pas besoin d'un système de bogues, écrivez simplement la tâche qui vous est assignée dans votre propre liste de tâches et écrivez des notes lorsque / après avoir parlé à quelqu'un des détails de vos tâches.

il y a 3 points principaux que je vois:

les points 1, 2 et 3 découlent du fait que vos collègues sont simplement plus expérimentés avec la base de code, ce qui signifie qu'ils connaissent ses bizarreries. Cela signifie qu'ils utilisent leur mémoire à long terme pour le processus de débogage et peuvent se rappeler que doXYZ fait réellement UVW mais n'a jamais été renommé pour des raisons historiques. Cependant, si jamais ils prennent quelques mois à coder dessus, ils commenceront à ressentir votre douleur.

pour le point 4, résistez aux interruptions, ne laissez pas les affaires non urgentes vous faire sortir de la zone , il faut beaucoup de temps pour y revenir après une interruption; réglez la messagerie instantanée de l'entreprise sur occupé, essayez de planifier en longs blocs (après-midi complets) de codage

pour le point 5, créez une feuille Excel avec les bogues sur lesquels vous travaillez actuellement en tant que liste de tâches personnelle (ou utilisez les capacités de gestion des tâches dans votre IDE), je suis prêt à parier que certains de vos collègues font de même

Cela ne me semble pas être un problème de mémoire. Il semble que vos habitudes / tendances de travail ne correspondent pas à ce que vous rencontrez et que vous pensez trop à vos collègues et non à vous-même.

1. Méthode des mille lignes - tout le monde sera perdu à ce sujet à moins qu'ils n'y travaillent. Ils peuvent être plus rapides à ramasser ou à récupérer. Vous ne pouvez changer cela que par l'expérience, et peut-être même pas à ce moment-là.

2. Refactoriser l'introduction de bogues, eh bien, c'est toujours un risque. Vous pouvez essayer de développer un test unitaire pour couvrir ce que vous changez avant de le faire, mais cela peut ne pas être autorisé par la direction (probablement pas, ou ce serait déjà fait). Et les tests unitaires ne sont pas magiques, ils peuvent toujours manquer des choses, vous pouvez toujours introduire des bugs. Il y a de fortes chances qu'ils ne refactorisent pas. Cela remonte à (1), ils essaient probablement de se concentrer sur ce qui doit être corrigé, ce qui signifie qu'ils arrivent au point plus rapidement, mais manquent de vue d'ensemble, et prendront plus de temps pour résoudre la prochaine chose dans ce gâchis de mille lignes.

3. Créez ce dont vous avez besoin pour faire le travail. Si cela signifie créer un organigramme ou une autre documentation, faites-le. Qu'ils en aient besoin ou non, et qu'ils l'utilisent ou non après que vous l'avez créé, n'a pas d'importance.

4. Les interruptions ralentissent tout le monde. Se concentrer sur cela ne fera que vous ralentir davantage. Acceptez-le et essayez de vous remettre dans le rythme aussi vite que possible.

5. Garder à l'esprit deux ou trois bogues n'est pas mauvais, trois ou quatre serait mieux, mais au lieu d'essayer d'améliorer cela, abandonnez et notez-le. Morceau de papier, tableau blanc, tfs, excel, word ou bloc-notes - il suffit de l'écrire. Je parie que c'est ce que font vos collègues. Soit ça, soit réparer les choses au hasard.

La programmation ne concerne pas une mémoire parfaite, et il ne s'agit pas de pouvoir ignorer les distractions - se concentrer uniquement sur ces distractions que vous créez.

AVERTISSEMENT / MISE À JOUR: Après avoir lu la réponse ci-dessous, j'ai senti que cela pourrait être un peu trop dur. Ce n'est pas mon intention, l'environnement que vous décrivez est terrible et il affecterait la plupart des gens (probablement même les meilleurs programmeurs en souffrent, mais ils sont "meilleurs" par comparaison avec d'autres dans le même environnement). Ma réponse n'est qu'une réflexion point par point dans vos questions, en supposant que l'environnement ne changera pas (même s'il le devrait).

Réponse totalement opaque:

1) Cela dépend de l'expérience dans la technologie, dans le maintien de l'application (plus si elle est mal conçue) et même dans des parties spécifiques de l'application. Dépend également de vos problèmes de concentration (numéro 4)

2) C'est le même que le numéro 1, mais en utilisant une métrique différente. Même réponse.

3) bloc-notes et stylo. Ou un document Word / Excel. Pas si difficile à résoudre.

4) c'est une question personnelle de concentration. Je ne sais pas s'il est viable de l'améliorer par vous-même, cependant.

5) l'utilisation ou non d'un système de ticket ne doit pas être décidée par les programmeurs mais par le chef de projet. Demandez son avis / présentez vos points. S'il est contre, bloc-notes et stylo à nouveau.

J'ai déjà vécu une telle situation et sur la base de cette expérience, je peux dire que votre problème n'est pas lié à la mémoire et qu'il y a quelque chose dans votre esprit (certainement pas lié au travail) qui vous rend stressant et vous empêche de vous concentrer 100 % sur la tâche à accomplir.

La première étape consiste donc à vous débarrasser de votre esprit lorsque vous êtes sur votre bureau.

Ce stress peut également être augmenté parce que vous avez l'impression de prendre du retard en termes de productivité, alors essayez de parler avec vos collègues et demandez-leur des conseils sur leurs approches de la refactorisation.

Enfin, ne vous sentez pas gêné si vous devez écrire les problèmes que vous avez résolus et / ou si vous travaillez en ce moment (ce ne doit pas être un système de suivi des bogues sophistiqué), il vaut mieux être certain de quelque chose parce que vous le lisez à partir de vos notes que de les énoncer du haut de votre tête sans en être certain à 100%