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

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?

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é

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

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.

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

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.

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

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

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.

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.

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.