Est-ce une bonne idée de prévoir du temps pour nettoyer le code? [fermé]

42

Je gère une petite équipe de développeurs. De temps en temps, nous décidons de passer un jour ou deux à nettoyer notre code.

Serait-ce une bonne idée de prévoir du temps régulier, par exemple une semaine tous les deux mois, pour nettoyer notre base de code?

utilisateur84667
la source
9
Je préférerais d'abord commencer à enregistrer tout ce qui nécessite un nettoyage dans un outil de suivi des problèmes . Analyser les problèmes enregistrés dans le suivi pourrait donner une meilleure idée de l'approche la plus appropriée pour un projet donné
gnat
4
Ce serait une meilleure idée de planifier une heure de révision du code
l46kok Le
1
Que voulez-vous dire quand vous dites «nettoyer»? Est-ce que cela prettifie le code ou gère toutes les balises FIXME et TODO ou améliore-t-il les performances du code écrit rapidement? Ou autre chose? N'importe lequel de ces objectifs pourrait être qualifié de nettoyage, mais j'attacherais des priorités différentes à chacun d'eux.
Paul
Un autre "fermé comme trop populaire", hein, les gars?
MGOwen

Réponses:

100

Non.

Corrigez-le pendant que vous y travaillez:

  • Si vous attendez de refactoriser le travail sur lequel vous travaillez, vous en oublierez beaucoup et vous devrez passer du temps à vous en familiariser à nouveau.
  • Vous ne vous retrouverez pas dans un code "plaqué or" qui ne sera jamais utilisé car les exigences ont changé
MGOwen
la source
2
Mon argent sur cette réponse ..
Soner Gönül
2
+1 pour une excellente réponse. Vous ne vous retrouverez pas dans un code "dorure" qui ne sera jamais utilisé car les exigences ont changé
Md Mahbubur Rahman
8
Sur un projet parfait avec une gestion parfaite et une équipe de développeurs uniformément géniaux, cette réponse serait valable. Malheureusement, je n'ai jamais vu ni entendu parler d'un tel projet depuis dix ans que je suis dans l'industrie.
Ben
3
Essayez de faire cela, mais lorsque vous ne pouvez pas (et cela se produira en raison de contraintes de temps ou simplement parce que vous ne savez pas comment le faire correctement), créez un ticket dans votre système de ticket. De cette façon, vous pouvez, espérons-le, y revenir tant que le problème est encore présent dans votre esprit et pas seulement lorsqu'il commence à poser des problèmes.
Sarien
1
Je pense que c'est un bon conseil, mais ne répond pas à la question posée. Haivng a dirigé une équipe avec une base de code épouvantable (c'était épouvantable avant mon arrivée). Nous avons passé beaucoup de temps à aborder le refactoring et le nettoyage de fonctions spécifiques. Nous les avons appelés projets d'infrastructure et les avons menés à chaque sprint possible. Souvent, ces éléments ne faisaient pas partie d'un autre changement, mais étaient des éléments identifiés par l'équipe comme des problèmes. Nous avons fait des rétrospectives trimestrielles et mettions régulièrement cette liste à jour.
Bill Leeper
21

Mon opinion personnelle: C'est absolument nécessaire pour 90% des projets.

Particulièrement pour les projets fortement basés sur les ventes, il y a généralement une forte pression pour inclure de nouvelles fonctionnalités dans chaque version, et vous finissez inévitablement par compromettre votre meilleur instinct et introduire quelques kludges / hacks ici et là.

En fin de compte, grâce à ces petits compromis, vous avez accumulé suffisamment de «dette technique», ce qui vous a obligé à passer assez de temps à corriger les failles du code et à exploiter tout son potentiel.

Généralement, deux types de problèmes sont générés de cette manière:

  • Les plus petits qui peuvent être facilement corrigés mais peuvent être systémiques, par exemple des paramètres mal nommés, une gestion des erreurs incomplète, etc. Ils auront généralement peu d'impact en dehors du bloc de code où ils apparaissent. La meilleure façon de traiter ces problèmes est de passer en revue les codes et de vérifier le code au fur et à mesure de son écriture / modification. Comme d'autres l'ont dit, il n'est pas nécessaire de mettre de côté un cycle spécial de refactorisation pour corriger ces erreurs.
  • Les plus gros problèmes peuvent être dus à des spécifications incomplètes ou à de mauvaises décisions de conception, ou à deux développeurs / équipes créant deux solutions différentes pour le même problème. Celles-ci sont généralement beaucoup plus difficiles à résoudre et nécessitent un effort concerté. En conséquence, ils sont généralement différés jusqu'à ce qu'ils deviennent une nuisance perpétuelle. Ce type de problème nécessite une période de temps dédiée à la résolution.

J'essaie généralement de réserver du temps pour un cycle pur de refactorring / correction de bugs tous les 3 à 4 cycles. Je demande toujours à mes développeurs de me dire quand ils se sentent également frustrés par la base de code. Tous les développeurs ne doivent pas nécessairement travailler sur l'effort de nettoyage - vous pouvez généralement (mais pas toujours) décaler les équipes un peu, de sorte qu'une seule équipe travaille sur le nettoyage à un moment donné.

pswg
la source
1
Je ne comprends pas que le nombre croissant de grosses poussées soit un problème agile.
JeffO
2
@ JeffO Non, ce n'est pas un problème agile. C'est un problème de gestion. D'après ce que j'ai vu, les entreprises fortement influencées par les ventes ont tendance à s'intéresser aux cycles de publication agressifs et aux grands ensembles de fonctionnalités. Les stratégies agiles ont tendance à séduire ces entreprises (qu'elles suivent réellement les stratégies ou non). Bien que j'aime le développement agile, mon expérience a montré que lorsqu'une entreprise se dit "agile", cela signifie généralement que je peux m'attendre à voir une importante dette technique dans la base de code.
pswg
Je suppose que s’ils n’ont aucune méthodologie, ils peuvent s’appeler comme ils veulent. Depuis agile, est le mot à la mode actuel, c'est le plus attrayant. Cela fait longtemps que je n'étais pas sur un projet de cascade; c'était un tel désastre à bien d'autres égards, que je ne l'ai jamais utilisé comme argument contre la méthodologie.
JeffO
Quel que soit votre projet, qu'il soit agile ou non, refactoriser et nettoyer le code est une chose que vous faites au fur et à mesure, afin de maintenir constamment la dette technique au minimum. Si vous n'en tenez pas compte dans vos estimations, vous devrez commencer à le faire. Vous ne pouvez pas laisser la dette technique s’accumuler tant que vous n’avez pas besoin de tout arrêter pour le réparer. Suivez plutôt la règle de scout: "Laissez toujours le code plus propre que vous ne l'avez trouvé."
Christoffer Hammarström
D'après mon expérience, des équipes inexpérimentées commençant par scrum, sans observer de bons principes de codage (comme XP), peuvent parfois être trop focalisées sur la fonctionnalité (histoires). Au lieu de cela, ils devraient dire qu'une histoire n'est pas terminée tant que le code n'est pas suffisamment bon, mais tout le monde ne dispose pas d'assez de ressources pour le faire dans un délai imminent. Et avec Agile, vous avez tendance à avoir plus de délais dans un délai plus court, donc je l’associe également aux méthodes Agiles, alors que je suis parfaitement conscient que ce n’est pas la cause.
markijbema
11

Je demande à mes développeurs de ranger leur code avant l'enregistrement (Subversion) ou la fusion avec la branche de développement principale (Git).

Je leur ai faire ce qui suit:

  • Supprimer les commentaires non pertinents
  • Assurez-vous que leurs méthodes, arguments et variables sont nommés correctement
  • Assurez-vous que leurs classes sont structurées et que les éléments sont encapsulés comme il se doit
  • Refactoriser pour améliorer la lisibilité et réduire les odeurs de code

Pour les projets plus importants, le code est examiné formellement avant la fusion de la branche de développement vers la branche principale.

Je pense que "consacrer du temps" signifiera que c'est quelque chose qui peut être différé, ou différé en raison de la quantité de travail nécessaire. Si les développeurs le font à chaque enregistrement (ce qui équivaut à une demande / modification de changement dans JIRA), il est beaucoup plus facile à gérer.

Sam
la source
Par simple curiosité, pourquoi utilisez-vous deux VCS différents?
Eekhoorn
2
Il y a eu / est une phase migratoire. Nous avons migré la plupart des référentiels SVN maintenant, j'ai mentionné les deux pour certains contextes.
Sam
C'est ce que je fais. Nettoyez le code avant l’archivage et refactorisez-le si je reviens au code pour améliorer les fonctionnalités.
Barfieldmv
1
Cela ne résoudra pas les problèmes épineux qui se cachent dans des domaines qui ne font peut-être pas partie des demandes de fonctionnalités de la part de l'équipe produit.
Bill Leeper
9

Pas à mon avis. Si vous laissez trop de temps entre le moment où vous rencontrez une dette technologique et le moment où vous le résolvez, vous perdez le contexte du problème. Cela prend plus de temps à réparer et le problème a tendance à s'aggraver. Plus important encore, les gens laissent les fenêtres cassées parce que ce n'est pas une "semaine de nettoyage".

Personnellement, je négocie pour le nettoyage technique de la dette à chaque sprint si je sais que nous en avons créé auparavant. Il garde la dette fraîche dans l'esprit des gens. Il limite la quantité de code à l'aide du code du problème afin de faciliter la refactorisation. Cela évite que la dette technique ne s'accumule. Et cela aide à dissuader les développeurs de simplement coller quelque chose ensemble, parce que je vais simplement leur faire faire ça dès le prochain sprint (donc autant le faire correctement dès le départ).

Telastyn
la source
Votre deuxième phrase contredit la première. Vous avez dit non, mais ensuite vous avez dit que vous intégriez ce genre de choses à chaque sprint. D'une manière qui prend du temps pour le faire.
Bill Leeper
2
@ BillLeeper - enh. Quand j'entends parler de "temps normal", cela signifie qu'il y a un intervalle régulier pour effectuer le travail de nettoyage. OMI, c'est incorrect - tout le temps est le bon moment pour faire le travail de nettoyage.
Telastyn
1
Bon point, je conviens que le temps réglementaire ne fonctionne pas bien. Trop souvent, les priorités sont annulées, etc.
Bill Leeper
4

Je dirais que oui, avec une réserve: cela devrait être fait souvent, de préférence chaque semaine. Je crois qu’une révision de code régulière et planifiée, combinée à une action effective sur les éléments issus de la révision de code, porte ses fruits très rapidement. Voir la réponse de pswg

1 semaine tous les 2 mois n'est certainement pas assez souvent. Cela concerne la plupart des autres réponses qui ont répondu «Non» à votre question. L'essentiel de la plupart de ces réponses est que, si vous attendez trop longtemps, vous ne serez plus en contact avec le code et qu'il faudra généralement beaucoup plus de temps pour le réparer / le nettoyer / le refactoriser.

Mauritz Hansen
la source
Nous faisons un "mardi de la dette technique" pour cela. Sa moitié de chemin a jeté une semaine de travail israélienne et nous permet de faire un pas en arrière pour régler les problèmes
Zachary K
1

Il n'est pas clair si vous vouliez dire un exercice supplémentaire de nettoyage du code de temps en temps. En ce sens, oui. Quelles que soient les pratiques que nous suivons, certaines dégradations se produisent toujours.

Vous ne devez pas utiliser cette excuse pour ne pas faire ce qui est juste [appliquer les principes SOLID, les tests unitaires, les inspections, etc.].

Jayan
la source
1

Je pense que les deux réponses "non" et "oui" actuellement populaires sont deux aspects de la même vérité. N'oubliez pas que le PO parle d'un groupe qu'il gère, et pas seulement de lui-même. Nous ne pouvons pas supposer que tous les développeurs du groupe sont suffisamment disciplinés pour écrire du code propre, facilement lisible. et il y a la question de la pression externe et des méthodologies de style agile. En outre, même avec les meilleurs efforts des gens, leurs différences de style signifieront qu'ils pourraient écrire un code qui serait considéré comme propre, mis à part, mais impur lorsqu'il est considéré avec d'autres personnes (sans parler des interfaces craquantes).

D'autre part, le "réparer tout en travaillant dessus" est à mon avis un idéal à aspirer. Vous pouvez rendre votre code encore plus "corrigé" par

  • attentions des pairs
  • écrire des tests unitaires avec le code lui-même
  • adopter des directives de codage
  • en utilisant des formateurs automatiques et des linters (mais YMMV)
  • etc.

Maintenant, si l'équipe du PO adopte ce qui précède, et s'il encourage ses subordonnés - par exemple lors des révisions de code et lors des sessions périodiques de nettoyage du code - à essayer d'anticiper les pièges et à éviter la laideur, avec le temps, ils auront besoin de moins temps de nettoyage. (Ils pourraient ensuite consacrer ce temps à la documentation, à une refactorisation plus approfondie et au partage des connaissances sur ce qu’ils ont écrit et consolidé.)

einpoklum - réintègre Monica
la source
1

Je pense que la planification d’heures normales est très utile, qu’il s’agisse d’une tâche dans un projet classique de style cascade ou d’histoires dans un projet agile. Avoir une heure fixe peut ne pas être aussi utile que de le faire simplement dans votre emploi du temps. Cela vous permet de le faire dans le cadre de la planification par rapport à l'annulation du jour de nettoyage, car votre projet est en retard.

Ayant géré un projet qui avait énormément de dettes de code, il était essentiel de les traiter régulièrement pour que tout fonctionne bien. Certaines de nos affaires étaient grandes, d'autres petites.

Après quelques mois de ce type de travail, notre responsable des opérations m'a expliqué à quel point tout se passait bien.

Chaque élément peut sembler peu, mais, comme toute dette, il augmente.

Bill Leeper
la source
1

La réponse idéale est non, car vous prenez les mesures nécessaires pour éviter que cela devienne une nécessité (nettoyez-vous au fur et à mesure pour plusieurs raisons déjà indiquées).

C’est peut-être l’objectif final, mais vous avez peut-être une équipe qui est loin de le mettre en pratique.

Les gestionnaires doivent assumer certaines responsabilités Ce n'est pas toujours la faute du développeur. Les gestionnaires peuvent dire une chose, mais ils commencent à faire pression pour que les projets soient terminés et à faire des suggestions qui promeuvent les mauvaises pratiques. Ils peuvent littéralement dire: "nous allons le nettoyer plus tard" ou si cela fonctionne, c'est assez bon.

Vous devrez peut-être commencer par dédier un moment particulier pour montrer que c'est important. Une fois que vous savez que votre équipe est capable de nettoyer son code (et non une donnée), vous pouvez essayer de l'incorporer plus fréquemment.

Finalement, vous ne devriez pas avoir à définir une heure.

Personnellement, j'ai du mal à résoudre un nouveau problème et à le faire fonctionner tout en essayant de garder les choses en ordre. Je m'améliore, mais je prends souvent une pause délibérée et je nettoie les choses. C'est un état d'esprit différent pour moi. Finalement, les pratiques solides deviennent une habitude.

JeffO
la source
-1

Non, vous devriez le faire pendant que vous codez. Cela s'appelle refactoring si vous utilisez TDD. Le problème lorsque vous attendez un mois ou deux pour réparer et nettoyer votre code est que vous pouvez modifier le comportement du code car vous ne vous souvenez pas de chaque élément de votre code.

Je suggère de refactoriser, qui consiste à coder d’abord le code nécessaire pour que quelque chose fonctionne, et dès que cela fonctionne, redéfinissez-le, optimisez-le et rendez-le joli.

Ricardo Mogg
la source
Cela s'appelle refactoring si vous utilisez TDD ou non. Cette question n'a rien à voir avec le TDD ...
Ben Lee