Dans quelle mesure est-il important de nettoyer le code de quelqu'un d'autre face à un délai serré?
(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 qu'avec les programmeurs.)
Je suis le designer front-end senior dans une équipe et je dois souvent retravailler la production de mes juniors dans des délais serrés.
Je suis confronté à 2 problèmes:
- Leur style de codage est un peu désordonné.
- L'esthétique n'est pas bonne.
Je trouve que leur style de codage est un sac mixte sans convention/norme appropriée. Je suis déchiré entre le nettoyage du code ou simplement le traitement de leur code (même la copie de la façon dont ils font les choses).
Je trouve frustrant de suivre leur style de codage car je sens que je pourrais apprendre de mauvaises habitudes. Mais alors, c'est le moyen le plus rapide de respecter le délai.
Pour ceux qui ont beaucoup plus d'expérience, quelle est la plus efficace? Dois-je conserver le nettoyage pour plus tard? Ou nettoyer en cours de route pendant que j'apporte les modifications?
(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 du code désordonné quand je commençais.)
Je crois que vous regardez le problème dans le mauvais sens - 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 vous n'appréciez pas leur travail, ce qui réduira leur moral et ne les aidera pas à mieux coder la prochaine fois.
Une meilleure approche, je crois, consiste à ajouter au processus de développement de votre équipe une tâche de révision du code. Cela ne doit pas nécessairement concerner chaque morceau de code engagé, et il ne doit pas (je dirais que cela ne devrait pas) être effectué uniquement par vous - chaque fois qu'un membre de votre équipe termine une tâche suffisamment importante, il devrait jumeler avec un (ou plusieurs) de ses coéquipiers, leur expliquer le code et recevoir une opinion constructive et des critiques sur sa conception, son style de codage, les éventuels bugs et problèmes de sécurité, etc.
Lorsque le coéquipier réviseur de code est vous, il apprendra beaucoup plus de votre expertise que lorsque vous réécrivez simplement son code (il a la chance d'entendre le raison le code doit être changé), et pourrait prendre moins d'offense.
Leur donner la possibilité d'effectuer également des revues de code améliorera encore leurs capacités - en voyant comment les autres personnes écrivent du code et pourquoi - et augmentera leur estime de soi.
Ils apprendront également beaucoup si vous leur donnez la possibilité de réviser votre code. Vous pourriez aussi apprendre quelque chose - alors ne le faites pas uniquement pour le spectacle!
Je l'ai déjà dit et je le redis "le code de travail est plus précieux que le joli code".
Si vous changez de code, il y a de fortes chances que vous changiez son comportement, s'il s'agit de code testé, vous venez d'invalider tous les efforts de test et devrez répéter les tests.
Par tous les moyens, encouragez vos juniors à écrire du code propre et compréhensible, mais si vous allez réécrire tout ce qu'ils écrivent, vous gaspillez l'argent de votre employeur plusieurs fois. Ils doivent payer pour vos juniors, puis payer pour que vous fassiez ce qu'ils ont déjà payé pour vos juniors, puis payer pour vous une fois de plus pour faire le travail pour lequel ils vous ont effectivement embauché.
La réponse courte est non. Quand 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 à le fixer dans le temps. Budget d'une heure pour parcourir et nettoyer un spécifique aspect du code. Ensuite, enregistrez-le et faites un vrai travail. Mais soyez honnête avec vous-même au sujet de le garder contraint.
Parfois, cependant, un peu de nettoyage accélère le travail. Même certains changements de type de recherche et remplacement rapides rendent tout beaucoup plus accessible.
Méfiez-vous des guerres de style. Surtout dans une situation de délai serré, si vous allez annuler certaines préférences stylistiques que l'autre programmeur va simplement refaire, alors encore une fois, vous feriez mieux d'attendre jusqu'à ce que vous ayez le temps de vraiment déterminer comment vous voulez y répondre 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 accélérer le travail, et la qualité du code fait, après tout, partie du livrable. Je ne pense pas que je puisse toucher du code (même le mien) sans passer un peu de temps sur le nettoyage. Mais assurez-vous que les problèmes de style et de format et les guerres de style ne deviennent pas plus importants que la mise en production du code.
Lors de la fixation du code et de la date limite, j'utilise normalement deux règles:
Le code est horrible mais il est possible de trouver un problème dans un délai raisonnable et de le corriger
Je corrige un problème et laissez 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 la rupture de quelque chose d'autre. Il serait probablement plus rapide d'écrire ce code à partir de zéro que de le corriger.
Ensuite, j'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 borderline est:
Le code est désordonné et vraiment mauvais. Il est toujours possible de corriger un bogue dans un délai raisonnable, mais la structure du code le rendra très difficile à maintenir. Toute nouvelle fonctionnalité est très susceptible d'introduire de nouveaux bogues ou d'entraîner une baisse significative des performances.
Dans ce cas, le code doit être corrigé, mais uniquement lorsque de nouvelles fonctionnalités doivent être implémentées, pendant le temps d'inactivité, jamais en temps de correction de bogues face à l'échéance!
J'aimerais savoir à quel moment de votre processus vous rencontrez ce problème?
À strictement parler, dans ce monde idéal magique où aucun de nous n'habite, tout le code promu ou déployé devrait être parfait. Ce n'est pas si parfois qu'il faut être pragmatique.
Cependant, si vous avez un processus de révision de code, il doit le mettre en évidence avant le test. Si vous respectez constamment les délais, les problèmes d'estimation de livraison signifient-ils 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 à s'asseoir et à absorber de meilleures façons de faire si vous ne prenez pas le temps d'en faire une partie de leur processus de développement. Il me semble que vous ne faites pas cela.
Dépend de la culture globale. Si les délais serrés sont sporadiques, acceptez que vous devrez faire le nettoyage plus tard. S'ils sont constants, vous accumulez structurellement de la dette technique et vous devriez aborder le problème avec la direction. S'ils ne répondent pas à vos préoccupations, mieux vaut commencer à chercher d'autres opportunités d'emploi car la culture de l'entreprise rencontrera très probablement les principes darwiniens bientôt.
Afin de limiter 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 lorsque vous refactorisez le code, mais uniquement lorsque vous refactorisez.
La meilleure pratique serait d'avoir un guide de style de codage et d'avoir des révisions régulières, de sorte que lorsque vous approchez d'une date limite, vous n'êtes pas confronté à ce problème.
Ma recommandation est pour vous de faire preuve de leadership et de diriger la révision régulière du code. La direction n'est pas poussée du haut pour s'assurer que les révisions de code régulières ont lieu, mais mon expérience est qu'elles seront impressionnées lorsqu'un programmeur s'apprête à planifier et à tenir des révisions de code régulières.
Les avantages pour votre peuple sont nombreux:
- apprendre un meilleur style
- suivre de meilleures pratiques
- apprendre à rechercher ce qu'ils font
Et certains avantages pour vous-même, vous serez:
- plus efficace lors des débogages de dernière minute (ce qui se produira toujours)
- reconnu à la fois comme un expert et un leader par votre équipe et la direction
Je peux voir la raison dans les réponses "ne pas réparer ce qui fonctionne" et "ne perdez pas votre temps sur ce qui n'est pas important pour le client". Les PM s'inquiètent des risques et c'est très bien.
Je comprends aussi que la plupart des gens ne prennent pas bien ce type de solution. Je le comprends aussi.
Cela dit, je pense que la plupart des délais sont artificiels. Les vrais systèmes vivent toujours plus que les délais et la mauvaise conception que vous faites aujourd'hui vous repoussera pour toujours et à jamais. Les gens courent pour livrer quelque chose en quelques mois et passent des années après cela à corriger de mauvaises décisions dans un code qui est exécuté en production.
La dette technologique est le mot. Il reviendra un jour et quelqu'un le paiera.
Donc, OMI, je pense que vous êtes en train de réparer le design cassé, et être professionnel (spécialement pour les juniors) signifie également que vous devez savoir comment prendre la critique et comment en tirer des leçons, même si ce n'est pas poli. En fait, la plupart de la vie n'est pas polie de toute façon.
Je suis assez inexpérimenté en programmation. En tant qu'étudiant, cependant, je m'engage souvent à l'examen par les 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 plus de clarté et de lisibilité. Plus souvent qu'autrement, je trouverai difficile de passer au crible les 100 premières lignes environ. Dans ces cas, je suis plus que disposé à tendre la main pour aider à enseigner à un collègue programmeur de meilleures habitudes et un meilleur codage. S'il n'y a tout simplement pas assez de temps, je copie/colle simplement et j'intègre mes projets dans leur ensemble avec leurs mauvaises interfaces. Par la suite, je suis sûr d'offrir de nombreux conseils sur la technique de codage. En ce qui concerne l'examen par les pairs, la critique constructive (quelle que soit la façon dont elle est importune) ne profite qu'à la fois à lui et à moi à long terme. Si je collabore avec les mêmes personnes à l'avenir, je peux être assuré de savoir qu'elles avaient des lignes directrices informatives dans leur esprit, et j'espère seulement que le prochain tour se déroulera beaucoup plus facilement.
Dans l'ensemble, si vous avez du temps à perdre, prenez-le pour enseigner à vos nouveaux arrivants comment mener leur travail afin que tout le monde soit bénéfique. Prenez une minute et enseignez-leur ce qui a fonctionné pour vous et ce qui n'a pas fonctionné. Si vous n'avez pas le temps, dépouillez-vous de leur travail pour l'instant et assurez-vous de leur revenir quand vous en aurez l'occasion. Faites-leur savoir qu'il existe de meilleures façons de faire les choses, surtout si vous travaillerez avec eux à l'avenir.
L'amélioration de la qualité globale est largement supérieure à l'utilisation d'une seule personne comme "filtre" pour un groupe plus important. Sur cette note:
- Programmation en binôme fonctionne comme une version optimisée de l'examen du code pour comprendre comment développer - c'est comme la différence entre lire et faire, raconter et montrer. Regarder le code évoluer et discuter rapidement des changements est extrêmement utile pour comprendre non seulement le comment mais le pourquoi du refactoring et du bon code. D'après mon expérience, c'est plus rapide que de se développer seul, car les idées se mélangent continuellement, se terminant par un résultat global de meilleure qualité et une meilleure compréhension du code et du la pensée d'une autre personne.
- Linting tools peut vérifier que le style de codage est suivi. Cela apprend à tout le monde comment formater le code, et les erreurs devraient disparaître rapidement une fois que les développeurs se souviendront de la norme.
- Faites-en partie dans le processus de génération pour vous assurer qu'il est corrigé avant de valider.
- Utilisez des modèles de langage pour vous assurer que votre code CSS, HTML, JavaScript et côté serveur peuvent être vérifiés séparément.
- Outils de validation peut vérifier que la sortie générée est saine. Ceux-ci devraient également faire partie du processus de construction.
Toute réponse directe va être extrême. De toute évidence, il y a des cas où le délai est si serré que vous devez utiliser du code laid, et il y a des cas où 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 dans lequel vous vous trouvez, et peut-être des méthodes pour définir des délais réalistes qui permettent d'écrire un meilleur code.
N'enregistrez pas le nettoyage pour plus tard. Sauf si vous avez habituellement des règles qui n'ont rien d'autre à faire que de refactoriser, il n'y a pas de "plus tard" dans lequel il deviendra en quelque sorte plus prioritaire de ranger le code qu'il ne l'est actuellement. La routine est "rouge, vert, refactor", pas "rouge, vert, faire 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 revisiterez pour une autre raison, et vous aurez probablement également une date limite. Vos vraies options sont de le réparer maintenant ou de le laisser.
Bien sûr, un code bien stylisé est préférable à un code mal stylisé, en supposant que vous prévoyez de le relire. Si vous prévoyez de ne jamais le relire, alors ne le rangez pas. Expédiez la première chose qui réussit les tests. Mais c'est un scénario assez rare, pour la plupart des programmeurs, cela n'arrive presque jamais. En ignorant ce cas, vous seul avez les détails de votre cas réel pour juger combien il en coûte de réparer par rapport à combien il en coûte (dans une maintenance future accrue) de ne pas le réparer.
Il y a certaines choses qui ne sont pas plus difficiles à corriger au point où le code nécessite une maintenance, qu'elles ne le sont maintenant. Ceux-ci ne vous apportent en fait pas grand-chose à corriger maintenant. Les plus évidents sont triviaux à corriger (erreurs d'espaces blancs et autres) et il est donc difficile d'imaginer que vous avez le temps de poser cette question mais pas de les résoudre ;-) Pour ceux qui ne sont pas triviaux et sont de ce type 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.
Il y a certaines choses qui sont beaucoup plus faciles à corriger maintenant qu'elles ne le seront plus tard quand (a) elles ne sont pas si fraîches dans l'esprit de tout le monde; (b) d'autres choses ont été écrites qui s'appuient sur elles ou les imitent. Ceux-ci sont beaucoup plus précieux à corriger maintenant, alors donnez-leur la priorité. Si vous n'avez pas le temps de fixer ces délais, vous devez pousser aussi fort que possible pour des délais plus longs, car vous accumulez des dettes dans votre base de code que vous devrez probablement payer lors de votre prochaine visite le code.
La méthode préférée de correction du code consiste à passer par un processus de révision. Commentez les problèmes que vous avez avec lui, et renvoyez-le au junior pour le changer. Vous pouvez donner des exemples de ce que vous voulez dire et laisser le junior trouver tous les cas dans le code auquel ils s'appliquent, mais ne vous contentez pas de terminer leur 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 faites pas cela, faites-le à la place" et expliquez pourquoi. En fin de compte, la raison peut être "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 probablement ne devriez pas les appliquer Soit. Laissez simplement chaque programmeur libre de choisir.
Enfin, méfiez-vous de la tendance à Tweak indéfiniment. Les rendements diminuent et vous devez apprendre par l'expérience où ils sont toujours 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 sont pas assez bonnes.
Comme beaucoup l'ont déjà dit, tout ce que vous jetez en l'air reviendra toujours. Je crois en une forte uniformité à travers une base de code. Bien sûr, certaines choses n'ont pas vraiment d'importance. Les conventions de nommage sur les variables locales dans une procédure par exemple. Cependant, pour tout élément structurel, il doit être réparé immédiatement, avant la fusion finale dans le tronc principal. Il n'est peut-être que légèrement de mauvaise qualité lorsque vous regardez la procédure ou la classe individuelle, mais si tout le monde commet du code "légèrement laid", il devient très rapidement très laid dans son ensemble.
Un code laid qui fonctionne fonctionne bien dans 90% des cas, mais s'effondre 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, il devrait être obligatoire pour chaque programmeur de définir et de documenter les contraintes exactes pour chaque procédure ou bloc fonctionnel qu'il produit.
Deuxièmement, pour chaque procédure, il devrait y avoir un test contre ces contraintes. Il doit s'agir d'un simple test unitaire que le programmeur peut (et doit) exécuter localement par rapport à sa procédure avant de valider. De toute évidence, cela est plus facile à gérer avec une suite de tests appropriée, mais même sans test, il doit être écrit et éventuellement validé dans une classe partielle qui peut être exclue de la génération.
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) exactes, les mêmes configurations et les mêmes mises à jour. Installez un outil de refactoring comme CodeRush ou Resharper, préconfiguré selon vos normes, et indiquez aux programmeurs que vous rejetterez toutes les validations qui comportent toujours des avertissements. Maintenant, vous pouvez utiliser le temps de révision du code de votre équipe pour améliorer réellement votre ensemble de règles à partir de leurs commentaires, et votre équipe se corrige avec plaisir sans que vous ayez à nettoyer constamment par la suite. Il est également beaucoup plus facile pour un programmeur de prendre la critique du code d'un outil correctement configuré que d'un collègue ou d'un patron, où les normes peuvent sembler définies arbitrairement ou ne sont pas bien comprises. Si le IDE vous indique que votre code est de mauvaise qualité, personne ne le contestera et il sera corrigé. Vous constaterez que la qualité du code augmentera considérablement et que l'équipe dans son ensemble dépensera BEAUCOUP moins de temps de refactorisation et de nettoyage après quelques semaines.Les programmeurs s'habitueront également aux règles et arrêteront d'écrire du code de merde.
Enfin, la solution simple ici 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 agréable 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 score hebdomadaire pondéré pour tout le monde, en enlevant des points pour les validations rejetées et les délais brisés par exemple. Montrez le top N lors de la réunion hebdomadaire de l'équipe, peut-être même payez-vous le déjeuner à celui qui est le premier dans les moyennes du mois.
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 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 engagements attendront votre acceptation. Si vous voyez des lignes qui doivent être réécrites, vous pouvez écrire des commentaires et vos coéquipiers peuvent corriger eux-mêmes le code en fonction de vos besoins. C'est vraiment un bon moyen d'apprendre les membres de l'équipe normes de codage .