Comment rester productif face à un code extrêmement mal écrit?

Je n'ai pas beaucoup d'expérience dans l'industrie du logiciel, je suis autodidacte et j'ai participé à l'open source avant de décider de travailler. Maintenant que je travaille pour de l'argent, je dois aussi faire face à des problèmes désagréables, ce qui est normal bien sûr.

Récemment, on m'a demandé d'ajouter la journalisation à un grand projet SharePoint écrit par un programmeur qui visiblement était en train d'apprendre à coder sur le tas. Après 2 ans de collaboration, le client a changé pour notre société, mais le mal était fait et maintenant, il me faut maintenant maintenir ce code.

Non pas que le code était trop difficile à lire. Malgré les problèmes - chaque projet a une classe avec plusieurs méthodes de copier-coller, d'énormes ifimbrications, des systèmes hongrois, des connexions non exposées - il est toujours lisible.

Cependant, je me suis trouvé absolument improductif malgré le fait de travailler sur quelque chose d'aussi simple que d'ajouter la journalisation. Fondamentalement, je dois simplement parcourir le code étape par étape et ajouter des appels de trace. Cependant, l'idiotie du code est tellement ennuyeuse que je suis fatigué dans les 10 minutes qui suivent . Au début, j’avais l'habitude d'ajouter des usingconstructions, de réduire l'imbrication en inversant ifles noms, de renommer les variables en noms lisibles - mais le projet est volumineux et j'ai fini par abandonner. Je sais que ce n'est pas la tâche que je devrais faire, mais au moins réduire les dégâts m'a donné une sorte de récompense psychologique pour que je puisse continuer. Maintenant, le truc a cessé de fonctionner et il me reste 60% de mon travail à faire.

J'ai commencé à avoir des maux de tête après le travail et je n'éprouvais plus le sentiment de satisfaction que je ressentais auparavant, ce qui me permettait généralement de coder pendant 10 heures d'affilée tout en me sentant fraîche.

Il ne s’agit pas simplement d’un coup de gueule, car j’ai vraiment une question à poser:

Y a-t-il un moyen de rester productif et de ne pas lutter contre les moulins à vent?

Existe-t-il une astuce psychologique pour rester concentré sur la tâche, au lieu de penser «Comment est- ce stupide ?» À chaque fois que je vois un autre astuce intelligente du programmeur précédent? Le problème avec l'ajout de la journalisation est que je dois réellement comprendre ce que le code fait, et cela me fait mal au cerveau d'une manière désagréable.

Je suis désolé de vous le dire, mais tous les emplois ne sont pas ensoleillés et glamour. La majorité des tâches de développement impliquent des travaux pénibles comme celui-ci. Triste mais vrai.

Vous êtes chargé d'un travail important, même si c'est ennuyeux au point de regarder sécher la peinture. Il est important pour deux raisons: 1. Il ajoute une journalisation très nécessaire à un système de grande taille afin que, en cas de problème, vous disposiez d'un outil pour vous aider à le trouver. et 2. Il vous familiarise avec la base de code, vous permettant ainsi, en cas de problème, d’intervenir et de le réparer.

Vous créez essentiellement votre propre filet de sécurité ici. Glamours, non, mais important oui!

Alors, cela étant dit, comment devriez-vous vous motiver? Quand j'ai une tâche abrutissante au travail, je me fixe des objectifs. Terminez la tâche x à la fin de la semaine. Si je fais mon objectif, je me récompense. Nouveau restaurant que je veux essayer? Allez vendredi soir si je finis. Un nouveau film vient de sortir? Voir le week-end si je finis.

Je trouve que parler avec mon superviseur et lui faire savoir où je suis et comment je vais me tient responsable. Si je leur dis que j'aurai terminé vendredi, je me sentirai plus enclin à le faire vendredi, car je leur ai dit que je l'aurais fait.

N'oubliez pas qu'une fois que vous aurez terminé cette tâche et que vous l'avez bien exécutée, dans les temps et dans les limites du budget, les utilisateurs s'en rendront compte et, lorsque ce nouveau projet éclatant se présentera, votre nom pourra être simplement suggéré comme celui qui l'obtiendra. :)

Conservez un fichier d'extraits de code de candidat à soumettre à thedailywtf.com. Même si vous n'avez pas vraiment l'intention de les soumettre, cela vous donne un bon côté pour trouver du code pire que la moyenne.

J'étais dans une situation similaire, chargée de nettoyer un grand nombre de codes mal écrits, copiés et collés en masse.

Pour maintenir ma motivation et ma santé mentale, j'ai écrit un script appelé current_scorequi comptait le LOC dans le projet (qui diminuait progressivement, car j'éliminais la duplication et passais à de meilleurs algorithmes) et le comparait au LOC lorsque je débutais. Chaque fois que je me sentais découragé ou frustré par la montagne de code auquel je faisais face, courir current_scoreme donnait une idée de progrès tangible et me rappelait tout ce que j'avais déjà accompli. Et c'était amusant de voir à quel point je pouvais obtenir un score élevé lorsque je m'attaquais à une section de code particulièrement mauvaise.

Je rechercherais des métriques similaires que vous pourriez facilement écrire pour vous donner une idée du progrès et en faire un jeu de toutes sortes. Lignes de code (il suffit de lancer wc -l), complexité cyclomatique (qui devrait disparaître au fur et à mesure que vous nettoyez ces "ifs" imbriqués), lignes de code qui ont été touchées par vous à la place de votre prédécesseur (je pense que FishEye peut vous le dire plus tôt. 10 $), etc. Vous pouvez même écrire un script Perl sans trop vous soucier de compter le nombre de blocs de code qui n’ont pas encore d’instructions de journalisation.

J'ai vu ce livre recommandé: Travailler efficacement avec Legacy Code , mais heureusement, je n'ai pas eu besoin de le lire.

Comme vous le faites, reformulez ce dont vous avez besoin pour comprendre le code et vous rappeler que vous réanimez un système, ce qui sera rentable si vous le maintenez.
Cela devrait, espérons-le, mettre un ressort dans votre démarche sur le chemin du retour.

Essayez de diviser le projet en morceaux. Chaque jour, apprenez comment fonctionne un morceau spécifique. Essayer de tout comprendre en même temps est probablement ce qui vous stresse.

Être fier d’améliorer le projet. Y a-t-il d'autres codeurs auxquels vous pouvez parler? Il est utile de rester autour de la fontaine d’eau pour discuter / rire de la dernière logique trouvée. J'essaie de faire cela pour garder une atmosphère joviale au travail.

Prenez des notes détaillées pour organiser vos questions, vos réflexions et votre compréhension du système. Cela a fonctionné à merveille pour moi lorsqu'il s'agit de systèmes hérités volumineux. Cela aide à cristalliser votre compréhension, à formuler les questions ouvertes en mots et, comme vos pensées sont déjà rassemblées, il est plus facile de communiquer spontanément avec d’autres personnes à propos de problèmes / questions / idées / etc.

Par exemple, pendant que je parcoure une partie du code, je prends des notes pour moi tout le temps. Ceci est ma conversation avec moi-même. Le simple fait d'écrire aide plus de pensées à sortir et m'aide à mieux comprendre les choses. Après un certain temps, j’aurai peut-être un Eureka et devrai dessiner un petit diagramme avec la "plus grande image" sur papier pour illustrer ce que je viens de penser ou les morceaux que je viens d’assembler. Je le fais toujours sur papier uniquement, en éliminant toutes les distractions de l'ordinateur. Cela me permet d’être plus méthodique et réfléchi à propos de ce que je fais.

Ceci est fondamentalement un moyen pratique d'avoir une conversation perpétuelle avec un expert du domaine :)

Je sais que vous vous sentez peut-être improductif parce que vous envisagez le problème comme suit: «J'ajoute seulement de la journalisation», alors qu'en réalité, vous ajoutez la journalisation et effectuez beaucoup de refactorisation. Votre superviseur est probablement au courant de la situation du code. Tout le monde ne l'appréciera peut-être pas maintenant, mais lorsque vous recevrez une demande pour ajouter une fonctionnalité vraiment intéressante et stimulante, vous serez ravi d'avoir nettoyé le code.

Dans ces cas, j'ai tendance à réécrire une section de code. Pour faire en sorte qu'une région soit moins bonne, puis j'ajoute simplement la journalisation. Puis nettoyez un peu plus de code. Un code incorrect n’est mauvais que si vous le laissez là.

Gamify votre travail. Par exemple, accordez-vous 5 points à chaque fois que vous posez une bonne question sur le code et 10 points à chaque fois que vous y répondez. Donnez-vous un badge chaque fois que vous refactorisez une méthode ou ajoutez une nouvelle fonctionnalité. Une fois que vous avez accumulé suffisamment de points, vous obtenez des privilèges tels que des pauses-café ou des biscuits. Une fois que vous avez terminé l'ensemble du projet, vous avez le privilège de vous offrir quelque chose que vous souhaitez vraiment.

Le truc pour ne pas s'ennuyer ou être en colère afin de rester productif est d'accepter le fait que le code est mal conçu. Accepter votre position de devoir comprendre et mettre à jour le code vous permettra de ne pas continuer à commenter "à quel point c'est stupide", mais plutôt de l'accepter tranquillement et de passer à autre chose.

Une autre astuce consiste à avoir une bonne famille d'accueil à espérer à la fin de la journée. Petite amie, amis, tout ce qui peut marcher va vous permettre de passer la journée à bon escient et de faire en sorte que la trudging soit un mauvais code qui en vaut la peine.

"Travailler efficacement avec Legacy Code" de Michael Feathers peut aider.

Si vous craignez de casser des choses lorsque vous les modifiez, écrivez d'abord quelques tests, assurez-vous qu'ils passent avant et après les modifications. L'écriture du test devrait vous aider à résumer et à comprendre ce qu'un code donné fait et vous permettra d'éditer en toute confiance.