À quel point est-il important de nettoyer le code de quelqu'un d'autre face à un délai serré? [fermé]

(Je parle de code HTML / CSS (pas de langages de programmation) mais je pense que nous sommes également confrontés au même problème que les programmeurs.)

Je suis le designer senior front-end d'une équipe et je dois souvent retravailler la production de mes juniors dans des délais serrés.

Je suis confronté à 2 problèmes:

1. Leur style de codage est un peu en désordre.
2. L'esthétique n'est pas bonne.

Je trouve que leur style de codage est un sac mélangé sans convention / norme appropriée. Je suis tiraillé entre nettoyer le code ou simplement traiter avec leur code (même pour copier comment ils font les choses).

Je trouve cela frustrant de suivre leur style de codage car je sens que je pourrais apprendre de mauvaises habitudes. Mais c’est le moyen le plus rapide de respecter le délai.

Pour ceux qui ont beaucoup plus d'expérience, lequel est le plus efficace? Devrais-je sauvegarder le nettoyage pour plus tard? Ou nettoyer en cours de route au fur et à mesure que je fais les changements?

(Je ne veux pas paraître arrogant, mais telle est la réalité. Il leur faudra plus d'années pour écrire un meilleur code. Je sais, j'ai écrit un code désordonné quand je débutais.)

Je crois que vous considérez le problème de la mauvaise façon - vous manquez une excellente occasion d’enseigner aux juniors comment écrire un meilleur code.

Si vous réécrivez habituellement leur code, vous pourriez donner à vos juniors l’impression que leur travail n’est pas valorisé, ce qui abaissera leur moral et ne les aidera pas à mieux coder la prochaine fois.

Je crois qu'une meilleure approche consiste à ajouter au processus de développement de votre équipe une tâche de révision de code. Cela ne doit pas nécessairement concerner chaque élément de code engagé, et cela ne doit pas (je dirais même que cela ne devrait pas être le cas) être effectué uniquement par vous - chaque fois qu'un membre de votre équipe termine une tâche suffisamment importante, il devrait associez-le à un (ou plusieurs) de ses coéquipiers, expliquez-leur le code et recevez des avis et des critiques constructives sur son design, son style, les problèmes de sécurité, etc.

Lorsque votre coéquipier chargé de la révision du code vous apprendra beaucoup plus que lorsque vous réécrivez simplement leur code (ils auront l'occasion d'entendre la raison pour laquelle le code devrait être modifié), ils pourraient apprendre beaucoup plus de votre expertise et pourraient être moins offensants.

En leur donnant la possibilité de procéder également à la révision du code, leurs capacités seront encore améliorées - en voyant comment les autres écrivent du code et pourquoi - et en plus d’améliorer leur estime de soi.

Ils apprendront également beaucoup si vous leur donnez une chance de revoir votre code. Vous pourriez aussi apprendre quelque chose - alors ne le faites pas juste pour le spectacle!

Je l'ai déjà dit et je le répète "le code de travail a plus de valeur que le joli code".

Si vous changez de code, il y a de fortes chances que vous changiez son comportement. S'il s'agit d'un code testé, vous venez d'invalider tous les efforts de test et vous devrez répéter les tests.

Encouragez certainement vos juniors à écrire du code clair et compréhensible, mais si vous allez réécrire tout ce qu'ils écrivent, vous gaspillez plusieurs fois l'argent de votre employeur. Ils doivent payer pour vos juniors, pour que vous fassiez ce qu'ils ont déjà payé pour que vos juniors fassent, puis pour vous payer une fois de plus pour faire le travail pour lequel ils vous ont réellement embauché.

• La réponse courte est non. Lorsque les temps sont durs, il suffit parfois de baisser la tête et de prendre la balle esthétique. ;)

• Une réponse plus pragmatique consiste à la chronométrer. Prévoyez une heure pour parcourir et nettoyer un aspect spécifique du code. Puis vérifiez-le et faites du vrai travail. Mais soyez honnête avec vous-même pour que cela reste limité.

• Parfois, cependant, un peu de nettoyage accélère le travail. Même certains changements rapides de type recherche-remplacement permettent de rendre tout beaucoup plus accessible.

• Méfiez-vous des guerres de style. Surtout dans une situation de délai serré, si vous voulez annuler certaines préférences stylistiques que l’autre programmeur va réitérer, il vaut mieux attendre que vous ayez le temps de vraiment déterminer comment vous voulez régler ces problèmes. questions stylistiques en coopération. (Ce qui signifie que certains donnent et prennent.)

Mais il y a une valeur de jugement dans la réponse. Je dirais "modérément" important. Un code propre peut vraiment rendre le travail plus rapide et la qualité du code fait, après tout, partie intégrante du produit livrable. Je ne pense pas pouvoir toucher au code (même le mien) sans passer un peu de temps à nettoyer. Cependant, veillez à ce que le style et la guerre des styles ne deviennent pas plus importants que la production du code.

Lors de la fixation du code et de l’échéance, j’utilise normalement deux règles:

Le code est affreux mais il est possible de trouver un problème dans un délai raisonnable et de le résoudre.

Je répare un problème et laisse le reste intact .

Le code est tellement compliqué qu'il est vraiment difficile de trouver un problème là-bas. Réparer quelque chose provoque immédiatement des ruptures. Il serait probablement plus rapide d'écrire ce code à partir de zéro que de le réparer.

Ensuite, je n'ai pas d'autre choix que de réécrire / refactoriser jusqu'à ce que le code soit suffisamment propre pour localiser et corriger le bogue.

Le cas limite est:

Le code est en désordre et vraiment mauvais. Il est encore possible de corriger un bogue dans un délai raisonnable, mais la structure du code rendra la maintenance très difficile. Toute nouvelle fonctionnalité est très susceptible d’introduire de nouveaux bogues ou d’entraîner une baisse importante des performances.

Dans ce cas, le code doit être corrigé, mais uniquement lorsque de nouvelles fonctionnalités doivent être implémentées, pendant la période d'inactivité, jamais dans le délai imparti pour la résolution des bugs!

Je serais intéressé de savoir à quel point de votre processus vous trouvez ce problème?

Strictement parlant, dans ce monde idéal et magique qu'aucun de nous n'habite, tout code promu ou déployé doit être parfait. Ce n'est pas si parfois vous devez être pragmatique.

Cependant, si vous avez un processus de révision de code, il devrait être mis en évidence avant les tests. Si les délais sont constamment respectés, les estimations des livraisons sont-elles problématiques, ce qui signifie qu'un élément clé de tout processus de développement - c'est-à-dire - la révision du code - est étranglé?

Vos juniors n'apprendront jamais à rester assis et à assimiler de meilleures façons de faire les choses si vous ne prenez pas le temps d'en faire partie intégrante de leur processus de développement. Il me semble que vous ne le faites pas.

Dépend de la culture globale. Si les délais sont sporadiques, acceptez, vous devrez nettoyer plus tard. S'ils sont constants, vous construisez structurellement une dette technique et vous devez vous attaquer au problème de la gestion. S'ils ne répondent pas à vos préoccupations, il vaut mieux commencer à chercher d'autres emplois, car la culture de l'entreprise respecterait probablement les principes darwiniens dans un proche avenir.

Afin de contribuer à réduire le problème à l'avenir, développez un document interne sur les normes et pratiques de codage que tous les employés doivent suivre.

Pour le lot en cours, nettoyez le code conformément au document S & P lors de la refactorisation du code, mais uniquement lorsque vous la refactorisez.

Je suis assez peu expérimenté en programmation. En tant qu'étudiant, cependant, je m'engage souvent dans des revues par des pairs et des partenariats sur des projets. S'il reste suffisamment de temps pour terminer un projet, je vais nettoyer le code d'un membre de l'équipe pour en améliorer la clarté et la lisibilité. Plus souvent qu'autrement, il me sera difficile de même parcourir les 100 premières lignes. Dans ces cas, je suis plus que disposé à tendre la main pour aider à enseigner à un collègue programmeur de meilleures habitudes et un meilleur code. S'il n'y a tout simplement pas assez de temps, je ne fais que copier / coller et intégrer mes projets à une vue d'ensemble de leurs interfaces médiocres. Ensuite, je suis sûr de donner beaucoup de conseils sur la technique de codage. En ce qui concerne l'examen par les pairs, les critiques constructives (quelle que soit leur importance) ne profitent qu'à la fois à lui-même et à moi-même à long terme.

Dans l’ensemble, si vous avez le temps, prenez le temps d’enseigner à vos nouveaux arrivants comment effectuer leur travail de manière à ce que tout le monde en profite. Prenez une minute et enseignez-leur ce qui a fonctionné pour vous et ce qui ne l’a pas été. Si vous n'avez pas le temps, expliquez-leur leur travail pour le moment et assurez-vous de le contacter dès que vous en aurez l'occasion. Dites-leur qu'il existe de meilleures façons de faire les choses, surtout si vous travaillerez avec elles à l'avenir.

L'amélioration de la qualité globale est nettement supérieure à l'utilisation d'une seule personne comme "filtre" pour un groupe plus important. Sur cette note:

• La programmation en binôme fonctionne comme une version optimisée de la révision de code pour comprendre comment se développer - c'est comme faire la différence entre lire et faire, dire et montrer. Voir le code évoluer et discuter rapidement des modifications est extrêmement utile pour comprendre non seulement le comment mais aussi le pourquoi du refactoring et du bon code. D'après mon expérience, cela est plus rapide que de développer seul, car les idées sont constamment échangées, pour aboutir à un résultat de qualité supérieure et à une meilleure compréhension du code et de la pensée de l'autre personne.
• Les outils de linting peuvent vérifier que le style de codage est respecté. Cela montre à tout le monde comment formater le code et les erreurs doivent disparaître rapidement une fois que les développeurs se sont souvenus de la norme.
  • Intégrez-les au processus de construction pour vous assurer qu’ils sont corrigés avant de s’engager.
  • Utilisez des modèles de langue pour vous assurer que votre code CSS, HTML, JavaScript et votre code côté serveur peuvent être vérifiés séparément.
• Les outils de validation peuvent vérifier que la sortie générée est saine. Ceux-ci devraient également faire partie du processus de construction.

La meilleure pratique serait de disposer d'un guide de style de codage et de procéder à des révisions régulières afin que, lorsque vous approchez d'une échéance, vous ne soyez pas confronté à ce problème.

Ma recommandation est que vous fassiez preuve de leadership et que vous dirigiez l'examen de code régulier. Les gestionnaires ne sont pas poussés d'en haut à veiller à ce que les révisions de code régulières aient lieu, mais je sais par expérience qu'ils seront impressionnés lorsqu'un programmeur intervient pour programmer et organiser des révisions de code régulières.

Les avantages pour votre peuple sont nombreux:

• apprendre mieux le style
• suivre de meilleures pratiques
• apprendre à rechercher ce qu'ils font

Et quelques avantages pour vous-même, vous serez:

• plus efficace lors des débogages de dernière minute (ce qui arrivera toujours)
• reconnu à la fois comme un expert et un leader par votre équipe et par la direction

Je peux voir la raison dans les réponses «ne corrige pas ce qui fonctionne» et «ne perds pas ton temps sur ce qui n’est pas important pour le client». Les PM s'inquiètent des risques et c'est très bien.

De plus, je comprends que la plupart des gens ne prennent pas bien ce genre de solution. Je comprends cela aussi.

Cela dit, je pense que la plupart des délais sont artificiels. Les systèmes réels vivent toujours plus que les délais et le mauvais design que vous faites aujourd'hui vont vous combattre à tout jamais. Les gens courent pour livrer quelque chose dans quelques mois et passent des années après à réparer certaines mauvaises décisions dans un code exécuté en production.

La dette technique est le mot. Il reviendra un jour et quelqu'un le paiera.

Donc, IMO, je pense que vous corrigez correctement le design cassé, et être professionnel (spécialement pour les juniors) signifie également que vous devez savoir comment prendre les critiques et comment en tirer des leçons, même si ce n’est pas poli. En fait, la majeure partie de la vie n’est pas polie de toute façon.

Toute réponse directe va être extrême. Il est clair que dans certains cas, le délai est si serré que vous devez utiliser un code laid, et dans certains cas, le code est si laid qu'il vaut la peine de manquer le délai pour l'améliorer. Ce dont vous avez besoin, ce sont des méthodes pour juger de qui vous êtes, et peut-être des méthodes pour fixer des délais réalistes qui permettent de rédiger du code de meilleure qualité.

Ne sauvegardez pas le nettoyage pour plus tard. Sauf si vous avez habituellement des périodes sans autre tâche que le refactor, il n'y a pas de "plus tard" dans lequel il deviendra plus ou moins prioritaire de ranger le code qu'il ne l'est actuellement. La routine est "rouge, vert, refactor", pas "rouge, vert, faites quelque chose de complètement différent pendant deux semaines, refactor". De manière réaliste, vous ne modifierez pas le code avant la prochaine fois que vous le revisitez pour une autre raison et vous serez probablement soumis à une date limite également. Vos vraies options sont de le réparer maintenant ou de le laisser.

Bien sûr, un code bien stylé est préférable à un code mal stylé, en supposant que vous envisagiez de le lire à nouveau. Si vous envisagez de ne plus jamais le relire, ne le rangez pas . Expédiez la première chose qui passe les tests. Mais c'est un scénario assez rare, pour la plupart des programmeurs, cela n'arrive jamais plus ou moins. En ignorant ce cas, vous seul avez les détails de votre cas réel pour juger du coût de la réparation par rapport au coût (en cas de maintenance accrue) pour ne pas résoudre le problème.

Certaines choses ne sont pas plus difficiles à corriger au moment où le code nécessite une maintenance que ce qu’elles sont à réparer maintenant. Ceux-ci ne vous aident pas vraiment beaucoup à réparer maintenant. Les plus évidentes sont faciles à corriger (erreurs d’espace, etc.) et il est donc difficile d’imaginer que vous avez le temps de poser cette question, mais pas de la résoudre ;-) Pour celles qui ne sont pas anodines et de ce genre, alors OK , vous avez du code qui n’est pas idéal mais vous devez être pragmatique. Cela fonctionne et vous êtes sur une date limite. Utilise le.

Certaines choses sont beaucoup plus faciles à régler maintenant qu’elles ne le seront plus tard quand (a) elles ne sont pas si fraîches dans l’esprit de tous; (b) d'autres choses ont été écrites qui les utilisent ou les imitent. Celles-ci sont beaucoup plus précieuses à corriger maintenant, donc hiérarchisez-les. Si vous n'avez pas le temps, dans vos délais, de les corriger, vous devez alors faire de votre mieux pour respecter des délais plus longs, car vous accumulez des dettes dans votre code que vous devrez probablement payer lors de votre prochaine visite. le code.

La méthode privilégiée de correction du code est un processus de révision. Donnez votre avis sur les problèmes que vous rencontrez et renvoyez-le au junior pour qu’il change . Vous pouvez donner des exemples de ce que vous voulez dire et laisser l’administrateur junior rechercher tous les cas dans le code auquel ils s’appliquent, mais ne vous contentez pas de terminer son code pour eux. Si vous le faites, vous ne leur donnez aucun moyen de s'améliorer.

Vous devriez écrire les problèmes courants dans un guide de style qui dit "ne le faites pas, faites-le plutôt", et explique pourquoi. En fin de compte, on permet que la raison soit "afin de rendre notre code esthétiquement cohérent", mais si vous n'êtes pas prêt à écrire vos règles avec une justification, vous ne devriez probablement pas les appliquer non plus. Laissez juste chaque programmeur libre de choisir.

Enfin, méfiez-vous de la tendance à peaufiner les choses indéfiniment. Les rendements diminuent et vous devez apprendre par l'expérience où ils sont encore bons. Il est absolument essentiel de vous faire une idée réaliste de ce qui est assez bon, sinon vous ne pouvez pas avoir cette négociation dans laquelle vous vous assurez que vos délais vous donnent le temps de créer du code "assez bon". Passez votre temps sur des choses qui ne vous suffisent pas.

Comme beaucoup l'ont déjà dit, tout ce que vous jetez en l'air redescendra toujours. Je crois en une forte uniformité dans une base de code. Bien sûr, certaines choses importent peu. Conventions de dénomination des variables locales dans une procédure, par exemple. Cependant, pour tout ce qui est structurel, il devrait être corrigé immédiatement, avant la fusion finale dans le coffre principal. Il se peut que ce ne soit que légèrement médiocre lorsque vous regardez la procédure ou le cours individuel, mais si tout le monde commet un code "légèrement laid", il devient très vite vraiment moche.

Un code laid qui fonctionne fonctionne souvent bien dans 90% des cas, mais se désagrège sur les bords. S'assurer que ce n'est pas le cas est généralement assez simple en ne suivant que quelques règles simples. Premièrement, chaque programmeur devrait avoir l'obligation de définir et de documenter les contraintes exactes pour chaque procédure ou bloc fonctionnel produit.

Deuxièmement, pour chaque procédure, il convient de tester ces contraintes. Cela devrait être un simple test unitaire que le programmeur peut (et doit) exécuter localement par rapport à sa procédure avant de valider. Évidemment, cela est plus facile à gérer avec une suite de tests appropriée, mais même sans test, il devrait être écrit et éventuellement commis dans une classe partielle pouvant être exclue de la construction.

Troisièmement, un ensemble d'environnements de développement standardisés avec des outils préconfigurés est inestimable. Un serveur TS est superbe pour cela. Tout le monde a les mêmes outils (et versions), les mêmes configurations et les mêmes mises à jour. Installez un outil de refactoring tel que CodeRush ou Resharper, préconfiguré selon vos normes, et indiquez à vos programmeurs que vous refuserez les validations contenant encore des avertissements. Vous pouvez maintenant utiliser le temps de révision du code de votre équipe pour améliorer votre jeu de règles à partir de leurs commentaires, et votre équipe se corrigera volontiers sans que vous ayez à nettoyer en permanence par la suite. Il est également beaucoup plus facile pour un programmeur de prendre la critique de code d'un outil correctement configuré que d'un collègue ou d'un patron, où les normes peuvent sembler définies de manière arbitraire ou ne sont pas correctement comprises. Si l'EDI vous dit que votre code est de mauvaise qualité, personne ne va discuter avec elle et ce sera corrigé. Vous constaterez que la qualité du code augmentera considérablement et que l'équipe dans son ensemble consacrera BEAUCOUP moins de temps à la refactorisation et au nettoyage après quelques semaines. Les programmeurs s’habitueront également aux règles et arrêteront d’écrire du code merdique.

Enfin, la solution simple consiste simplement à inciter les programmeurs à s’améliorer. Les programmeurs sont par définition compétitifs. Tout le monde veut avoir le code le plus gentil ou le plus rapide. Un bon moyen de motiver tout le monde, d'améliorer la productivité et d'éliminer l'incompétent est de calculer un tableau de bord pondéré hebdomadaire pour chacun, en prenant des points pour les validations rejetées et les délais non respectés, par exemple. Montrez les premiers N lors de la réunion hebdomadaire de l'équipe, peut-être même déjeunez-vous le premier dans la moyenne mensuelle.

Je suggère d'utiliser un outil de révision. Si vous avez un référentiel basé sur Git, vous pouvez utiliser l' outil de révision de Gerrit . Après quelques validations rejetées, l'équipe apprendra les normes que vous souhaitez suivre et les futures validations ne nécessiteront aucun travail supplémentaire de votre part.

Les commits attendront votre acceptation. Si vous voyez des lignes qui doivent être réécrites, vous pouvez écrire des commentaires et vos coéquipiers peuvent corriger le code eux-mêmes en fonction de vos besoins. C'est vraiment un bon moyen d'apprendre les normes de codage des membres de l'équipe .