Je voudrais vous poser quelques questions sur le code sale. Il y a des débutants qui ont codé sur un projet moyen. Le code est une énorme boule de boue. Ce ne sont pas des programmeurs avancés. Ils savent juste comment utiliser le clavier un peu sur java. Ils viennent d'écrire du code avec 12 000 lignes dans leur classe principale, cependant, 6 000 lignes appartiennent à NetBeans lui-même.

Mon travail consiste à analyser le code et à suggérer un bon moyen de maintenir le code. Mon idée est d'abandonner le projet et d'en démarrer un nouveau avec la méthodologie OOP. Récemment, j'ai recueilli quelques notes et idées sur le problème, à partir de ce site et de quelques autres.

Maintenant, j'ai les questions suivantes:

1. Faut-il réparer le code et le changer en POO? Nous le déboguons maintenant.
2. Le code n'a aucun commentaire, aucune documentation, aucun style de programmation particulier, etc. Le changer coûte vraiment cher et prend du temps. Que pouvons-nous faire à ce sujet?
3. Comment puis-je leur apprendre à suivre toutes les règles (commentaires, POO, bonne qualité de code, etc.)?
4. Le code est erroné et sujet aux erreurs. Que pouvons-nous faire? Essai? Nous écrivons presque deux ou trois papiers A4 pour correction, mais cela semble sans fin.

Je dois dire que je suis nouveau avec eux. Je pense que j'ai également enfreint les règles concernant l'ajout de personnes trop tard dans le projet. Pensez-vous que je dois les laisser?

Étape 0: sauvegarde sur SCM

Parce que, comme l'indique JBRWilkinson dans les commentaires, le contrôle de version est votre première ligne de défense contre les catastrophes (irréversibles).

Faites également une sauvegarde des détails de configuration du logiciel, des procédures pour créer des livrables, etc ...

Étape 1: Testez d'abord

Commencez ensuite par écrire des tests :

• pour ce qui fonctionne,
• et pour ce qui échoue.

Peu importe ce que vous décidez de faire, vous êtes couvert. Vous pouvez désormais:

• recommencer à zéro et réécrire ,
• ou le réparer .

Mon conseil serait de recommencer l'architecture générale à partir de zéro , mais d' extraire du désordre les parties qui valident les points de contrôle et de les refaçonner comme bon vous semble.

Étape 2: vérifier et surveiller

Mettre en place un système d' intégration continue (pour compléter l' étape 0 et l' étape 1 ) ET un système d' inspection continue (pour préparer l' étape 4 ).

Étape 3: Tenez-vous sur les épaules des géants

(comme vous devriez toujours ...)

• Refactorisation de motifs
• Refactoring: Améliorez la conception du code existant .
• Travailler efficacement avec Legacy Code (comme recommandé par Jason Baker )
• Refactoring

Étape 4: nettoyer

Cela va sans dire, mais au lieu de parcourir le code vous-même, vous pouvez simplement exécuter des linters / analyseurs statiques et d'autres outils sur la base de code cassée pour trouver des erreurs dans la conception et la mise en œuvre.

Ensuite, vous voudrez peut-être également exécuter un formateur de code, qui aidera déjà un peu avec le ménage.

Étape 5: Examen

Il est facile d'introduire de petits bugs en refactorisant ou en nettoyant les choses. Il suffit d'une mauvaise sélection et d'une touche rapide sur une touche, et vous pouvez supprimer quelque chose d'assez important sans vous en rendre compte au début. Et parfois, l'effet n'apparaîtra que quelques mois plus tard. Bien sûr, les étapes ci-dessus vous aident à éviter cela (en particulier en mettant en œuvre un harnais de test solide), mais vous ne savez jamais ce qui peut et va passer. Assurez-vous donc de faire réviser vos refactorisations par au moins une autre paire de globes oculaires dédiés (et de préférence plus que cela).

Étape 6: pérennisez votre processus de développement

Prenez tout ce qui précède et faites-en une partie inhérente de votre processus de développement habituel, si ce n'est déjà fait. Ne laissez pas cela se reproduire sous votre surveillance et collaborez avec votre équipe pour mettre en œuvre des garanties dans votre processus et les appliquer (si cela est même possible) dans vos politiques. Faites de la production de Clean Code une priorité.

Mais vraiment, testez . Beaucoup .

Personnellement, je ne commencerais pas ce projet avant d'avoir une copie de Travailler efficacement avec Legacy Code à portée de main. Sérieusement, il a été écrit pour exactement ce genre de chose. Il regorge de stratégies pour gérer le code délicat et va beaucoup plus en détail que je ne peux vous le donner ici.

J'y suis allé plusieurs fois. Ma règle est la suivante: si le logiciel n'est pas anodin (plus de 1 semaine de travail pour la ressource que vous avez) et qu'il fonctionne, alors conservez-le et procédez à une refactorisation incrémentielle.

Si le logiciel ne fonctionne pas vraiment (nombre très élevé de bogues, exigences peu claires, etc.), il vaut mieux le réécrire à partir de zéro. La même chose si elle est assez petite.

L'intérêt du refactoring (comme dans le livre de Fowler et celui de Kerievsky http://www.industriallogic.com/xp/refactoring/ ) est qu'il maintient le système en marche, peut-être que le refactoring prendra deux fois le temps mais les risques sont nuls.

La réécriture à partir de zéro pourrait introduire de nombreux risques, des exigences de malentendu à une mauvaise mise en œuvre (après tout, la plupart de l'équipe sera la même).

En fait, j'ai vu une procédure complexe être réécrite à partir de zéro deux fois et ne fonctionnait toujours pas comme prévu.

Je le réécrirais complètement. Parfois, il est impossible de réparer un tel code. Une autre option est de le faire fonctionner, sans ajouter de nouvelles fonctionnalités. Pour apprendre à l'équipe à écrire du bon code (bien conçu, documenté, avec des tests), laissez-le réparer le code que vous avez maintenant. Laissez tout le monde corriger les bugs / revoir le code des autres développeurs, pas sa part. Après quelques tentatives, ils comprendront qu'il est presque impossible de revoir / corriger ces codes.

L'ajout de personnes à des projets tardifs est très rare. Habituellement, cela brise les délais. Vous devez faire tout votre possible pour terminer le projet avec succès, puis penser à partir.

Mon conseil sera de ne pas supprimer entièrement le code entier. C'est le problème de la vie quotidienne, auquel chaque équipe de développement est confrontée. Attaquez une partie du code à la fois. Réparez-le, nettoyez-le, documentez-le. Et puis passez à l'autre partie. L'essentiel est toujours de garder un code livrable à portée de main. Réécrire l'intégralité du code à partir de zéro prendra le temps qui a été passé jusqu'à présent et il n'y aura aucune garantie qu'il sera plus agréable que le courant.
Mais alors, les gens devraient également éviter d'écrire le code de cette manière. Passez plus de temps dans les révisions de code. Adaptez-vous à un style de codage uniforme. Discutez d'abord de la conception, puis écrivez le code. Ces choses simples feront de grands changements.

Joli blog expliquant pourquoi Netscape est lâche

Si cela fonctionne, refactorisez-le. Il existe des outils pour vous y aider. Si cela ne fonctionne pas, utilisez la commande d'amélioration du code magique, c'est- deltreeà- dire sous Windows resp. rm -rfsous Linux.

Faut-il réparer le code et le changer en POO? Nous le déboguons maintenant. [... contient des erreurs, pas de documentation ...]

J'y suis allé, vous avez mes sympathies. J'ai même écrit un article à ce sujet qui pourrait vous aider à vous faire une idée. Mais en bref:

Si le code contient beaucoup de duplication, vous devez réécrire. S'il n'y a pas de structure discernable (pas d'interfaces claires, spaghetti), le refactoring échouera et vous devriez probablement réécrire.

Comment puis-je leur apprendre à suivre toutes les règles?

Commencez par expliquer pourquoi ils pourraient vouloir faire cela en leur montrant ce qu'ils peuvent en retirer personnellement. Quand ils sont d'accord avec cela et sont prêts à apprendre, commencez à leur enseigner le shuhari .

Ma suggestion est une combinaison des réponses de @ duros et @Manoj R.

Commencez à zéro, en gardant à l'esprit de créer du bon code / OOP / commenté / etc cette fois, référez / copiez et collez à partir de votre ancien code. Lorsque vous rencontrez les mauvaises parties de votre ancien code, réécrivez / refactorisez-les.

Si vos développeurs ne sont pas bien formés, je pense qu'il est bon de les envoyer pour des cours. Son important pour le recyclage régulier dans l'industrie informatique en évolution rapide