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

38

(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.)

chat et souris
la source
1
Si vous en avez la possibilité, examinez les produits JetBrains (Re-Sharper pour C #, IntelliJ pour Java et même certains langages «dynamiques») qui peuvent effectuer des modifications idiomatiques à l’échelle du projet à l’échelle de la solution, avec très peu d’investissement en temps. (Il peut également être utilisé pour enseigner de manière interactive au junior ce qui est idomatic. Mais assurez-vous que les deux paramètres sont identiques pour le projet. (Et assurez-vous de faire tout cela dans un commit séparé, pour ne pas mélanger changements substantifs et esthétiques dans le même commit),
David Bullock
2
Mettre en place un guide de style / minimanuel? Je veux dire, cela ne leur permettra pas d'écrire un meilleur code, mais tout le monde est capable de suivre les directives qui exigent d'écrire des choses triviales d'une seule manière.
Peteris
10
Je vois déjà que vous avez un problème de manque de travail d’équipe ici. Vous devriez éduquer et nourrir les jeunes; pas simplement réécrire son code et se plaindre.
James
3
@Ramhound depuis que Turing a conçu la machine de Turing, je suppose. Mais revenons au fait, si vous êtes l'aîné, cela devrait amener les juniors à vous écouter. Apprenez-leur à faire de la bonne façon (ou de façon convolutionnelle). Mais il est important de leur demander leur avis et peut-être qu’ils ont quelques idées pour améliorer leur utilisation. De même, si vous utilisez du CSS brut pour un projet non trivial que vous faites mal, essayez de faire en sorte que votre projet adopte LESS ou SASS.
Hoffmann

Réponses:

79

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!

Uri Agassi
la source
Je suis à 100% d’accord avec vous, mais je me demande comment l’appliquer en présence de délais serrés. Suggérez-vous de procéder à des révisions de code même s’ils risquent d’allonger plus de notre précieux temps (tant dans le processus de révision que dans les corrections apportées après la révision)?
Phil
3
Je ne pense pas qu'un membre de l'équipe devrait modifier le travail d'un autre membre de l'équipe sans sa coopération / son consentement. La personne qui a écrit le code devrait en être responsable et, à moins que le code ne contienne un bogue critique et que le rédacteur d'origine ne soit pas disponible, son calendrier serré ne constitue pas une raison pour changer le code de quelqu'un d'autre. Si le code vous semble trop compliqué, communiquez-le au développeur et dites-lui de le nettoyer pour la prochaine version.
Uri Agassi
23
@Phil Lors du calcul d'une échéance, le temps alloué aux sessions de révision du code doit être pris en compte. Ce n’est pas une étape supplémentaire au-dessus du processus de développement, c’est une partie intégrante du processus de développement.
dj18
2
De plus, l'entraînement des juniors via la révision du code peut avoir un certain coût en temps maintenant (ce qui, comme le dit déjà Dj18 devrait être pris en compte dans vos échéances et vos estimations), mais il sera remboursé à plusieurs reprises car il vous libère. travail plus original. Si vos délais sont si serrés que vous n'avez jamais la chance de le faire, cela sent plutôt la spirale de la mort ...
Julia Hayward
2
@JustinPaulson ne vous méprenez pas: le fait que quelqu'un ait écrit du code ne le rend pas "sien". Une semaine plus tard, un autre membre de l’équipe aura une tâche qui l’obligera à modifier ce code, et elle devrait certainement le modifier pour répondre à ses besoins. Cependant, je ne vois pas de cas d'utilisation où quelqu'un devrait «nettoyer» le code de quelqu'un d'autre pour le nettoyer, surtout pas à la dernière minute dans un délai serré.
Uri Agassi
29

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é.

James Anderson
la source
11
"si ce code est testé, alors vous venez d'invalider tous les efforts de test et vous devrez répéter les tests." Non, vous n'avez invalidé aucun effort de test. Vous devrez simplement relancer les tests, ce que vous devriez faire pour chaque commit de toute façon. Si cela prend tellement de temps que c'est considéré comme infaisable, les tests sont de la merde et devraient être corrigés.
l0b0
7
Il convient de noter que l'écriture continuelle de code bâclé afin de "le faire fonctionner" conduira à une grosse boule de boue . C'est bien s'il s'agit d'une exception et non de la règle. Si cela devient la règle, vous devriez informer votre patron que les délais ne sont pas la seule chose à prendre en compte.
Neil
20
Le problème est que le code laid se transforme rapidement en code cassé.
Telastyn
1
@ramhound - bien sûr, mais l'OP (et presque tout le monde) ne parle pas de code qui utilise simplement d'anciennes normes, mais d'un code maladroit, incohérent et de mauvaise qualité.
Telastyn
1
@ JamesAnderson C'est une perspective extrêmement myope. Le code est écrit une fois mais il est maintenu pendant toute la durée de vie du produit. La plupart du code est refactoring. Pendant combien de temps écrivez-vous le code sur un écran vierge avant de le modifier et de voir s'il fonctionne comme prévu? Par conséquent, vous effectuez une refactorisation, même dans la première heure après le début d'un nouveau cours. Le coût de la refactorisation du code moche dans les corrections de bogues et les améliorations ultérieures dépassera le coût d'un peu de temps passé à la révision du code et à la progression de l'équipe vers une norme claire.
Scott Shipp
16
  • 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.

Rob
la source
9

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!

Marin danubien
la source
Le problème avec le "cas limite" est que d’autres modules ont tendance à apparaître qui utilisent ce code. Il devient alors très risqué de changer car d'autres modules peuvent maintenant s'appuyer sur un comportement "incorrect / indésirable". Vous vous retrouvez donc avec un code vraiment difficile à maintenir qui vous fait grincer des dents chaque fois que vous le voyez et vous donne envie d'aller ailleurs pour trouver un emploi. Au minimum, un mauvais code doit être bloqué par quelqu'un qui sait ce qu'il fait. De cette façon, il peut être corrigé ultérieurement sans encourir autant de risques que de le laisser jusqu'à ce que quelqu'un ait le temps de s'y résoudre.
Dunk
6

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.

Temptar
la source
4

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.

utilisateur1703394
la source
3

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.

Casey
la source
J'ai travaillé pour de grandes entreprises très axées sur les processus qui étaient disposées à dépenser une centaine de dollars pour s'assurer que les normes et les pratiques de codage étaient respectées. Ils n'étaient jamais jusqu'à ce que des outils automatisés commencent à les appliquer.
Dunk
@Dunk L'armée américaine compte-t-elle comme "grande et orientée processus"? Ils utilisent S & Ps tout le temps: stroustrup.com/JSF-AV-rules.pdf
Casey
Ils comptent certainement comme la référence en matière de normes et de pratiques de codage. Chaque contrat les requiert. Cependant, aussi difficile que les entreprises essaient d’adhérer à leurs normes et pratiques, cela n’a pas lieu de manière fiable et uniforme. Il y a trop de choses à faire. C'est pourquoi des outils automatisés sont nécessaires si vous souhaitez inclure le mot "doit" dans votre suggestion, comme vous l'avez fait. Le DOD a reconnu l'impossibilité de respecter les normes manuellement. C'est pourquoi le congrès a adopté une loi en 2011 obligeant les entrepreneurs de la défense à commencer à utiliser des outils automatisés pour effectuer ces contrôles.
Dunk
BTW, je ne dis pas qu'il n'y a pas besoin de normes et de pratiques de codage. Il y a absolument un besoin. Je viens juste de me disputer avec la partie "Tous les employés doivent suivre", à moins que vous ne mentionniez aussi quelque chose à propos de l'application de cette règle via des outils automatisés.
Dunk
@Dunk L'équipe JSF-AV doit l'avoir reconnue, le document mentionne spécifiquement l'utilisation d'outils automatisés en tant que moyen de faire respecter le S & Ps (retour en 2005)
Casey
2

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.

Harrison McCullough
la source
2

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.
l0b0
la source
2

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
Aaron Hall
la source
1
Le problème avec les guides de style de codage est qu’ils ont tendance à se transformer en livres. La plupart des gens sont disposés à apprendre et à suivre un ensemble assez modeste de règles. Malheureusement, à un moment donné, ces guides dépassent toujours la capacité des personnes à apprendre et à mémoriser toutes les règles. Vous avez besoin d'un outil qui vérifie automatiquement le style, point final. Les révisions de code ne doivent pas servir à effectuer des vérifications grammaticales, mais à rechercher des erreurs et des incompréhensions.
Dunk
En tant que programmeur Python et responsable de la révision de code, j'ai imprimé au moins une douzaine de fois PEP 8 et le guide de style Python de Google. Tout ce que les programmeurs n'apprendront pas d'eux se retrouvera à la traîne de ceux qui le font. Cela dit, je conviens qu'un vérificateur de style est également une bonne pratique si vous pouvez le mettre en œuvre.
Aaron Hall
Je n'utilise pas Python, donc je ne connais pas les outils disponibles, mais si vous vous fiez à des revues de code pour appliquer vos règles de style, vous perdez des centaines (voire des milliers) d'heures par an pour quelque chose que vous pourrait être fait pour vous pour l'essentiel sans coût en temps. Je ne voudrais certainement pas aller de l'avant et mettre en œuvre une version maison. Je dépenserais de l'argent pour acheter une version commerciale qui sera bien meilleure que tout ce qui peut être construit à la maison en dehors des heures. Même les outils coûteux vont se payer plusieurs fois.
Dunk
Python, en tant que corne d'abondance open-source, dispose de toutes sortes d'outils gratuits (pylint, pep8, pyflakes), dont certains ont été combinés et améliorés et qui, depuis que nous avons des milliers de développeurs, évoluent très bien.
Aaron Hall
1
: Je faisais référence à votre extrait "si vous pouvez l'implémenter". Si vous pouviez acheter un vérificateur de style, alors c'est la voie à suivre. Si vous pouviez demander à votre équipe de mettre en œuvre quelque chose d'aussi utile dans un délai raisonnable, une entreprise / source ouverte devrait déjà l'avoir fait. Donc, il serait beaucoup plus rentable de simplement l'acheter. Je suis sûr que ce serait mieux et plus moderne qu'une version maison "non-productisée". Si vous avez des milliers de développeurs, j'ai largement sous-estimé le montant des économies qu'un outil de vérification de style / sécurité automatisé fournirait.
Dunk
2

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.

Leo
la source
0

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.

Steve Jessop
la source
0

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.

Drunken Code Monkey
la source
0

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 .

Kasper Ziemianek
la source