"ça marche, n'y touche pas" et continue l'ingénierie.

Question

Parfois, je travaille avec du code qui sent mauvais. Oui, il y a du mauvais code :) Je ne parle pas de problème de conception mais de choses beaucoup plus simples comme :

• indentation désordonnée
• utilisation non cohérente des lignes vides
• de grandes bannières présentant les fonctions, qui ne font que répéter les noms des fonctions/méthodes
• conversion des noms non cohérente, même dans la même ligne
• une logique de fonctionnement mal structurée (par exemple, des contrôles redondants, des répétitions, etc.)
• couplage étroit des données et de la logique
• et bien plus encore

Un exemple juste pour visualiser ce dont je parle (C++)

class MyClass 
{
   public:
   /*******************************************************
      | constructor                                             |
   ********************************************************/
   MyClass()
  {
  }

   /*******************************************************
   | destructor                       |
   ********************************************************/
   ~MyClass() {}    

   void Foo(char *Name, const char* Type, char* sub_type);
  };

Personnellement, je n'aime pas travailler avec un tel code, cela me décourage d'écrire du bon code, de penser à des obstacles de plus haut niveau.

Ce qui me rend le plus fou, c'est que les développeurs de mes collègues ne comprennent pas quand on leur dit que quelque chose ne va pas dans le code - ils continuent joyeusement à soutenir ce gâchis.

Malheureusement, les managers ne sont pas intéressés par la "beauté" du code, ils ne voient pas l'impact d'un mauvais code à long terme. Quand il y a un créneau libre, rien n'est fait pour nettoyer/améliorer le code - ce n'est jamais planifié comme une tâche/un projet. Parfois, à mes plaintes, j'entends une réponse bien connue : "ça marche - n'y touchez pas" .

Je pense que c'est une mauvaise pratique. Ne pas gérer les problèmes, c'est comme une graisse, cela vous rend maladroit, pas compétitif.

Que faire ? Se plaindre constamment pour livrer le problème ? Cela ne fera que vous donner une mauvaise réputation et les managers ne comprendront pas pourquoi vous êtes si mécontent. Modifier le code pendant votre temps libre ? Ce n'est pas bon non plus - vous ne pouvez pas prendre le risque d'introduire un bogue ?

L'écriture d'un bon code doit faire partie intégrante du processus de développement.

Vous avez le même dilemme ? Qu'avez-vous fait pour améliorer la situation ?

Mise à jour :

Le langage utilisé est le C++.

Un nouveau morceau de code est écrit sous une forme non contrôlée, en mettant l'accent sur la fonctionnalité. Aucune revue de code ou norme de codage ne l'affecte actuellement (si jamais elle l'a fait). Je veux changer cette situation, mais je ne sais pas comment.

Mise à jour 01

Disons que nous voulons effectuer uniquement un remaniement "syntaxique" sur une grande base de code. Par exemple, corriger l'indentation, renommer une variable (en utilisant les outils de refactoring bien sûr - pas à la main :))). Cela vaut-il la peine de le faire et d'introduire probablement quelques bogues ?

Answer 1

Qu'on le veuille ou non, le remaniement du code sent mauvais. puede introduire des failles dans votre code. Je ne plaide pas du tout en faveur d'un code médiocre, mais je dis qu'en tant que développeurs, nous devons reconnaître que, parfois, il est nécessaire d'améliorer le code. es plus rentable (et donc meilleur pour nos emplois), pour laissez ce code désordonné tranquille .

Answer 2

ça marche, n'y touchez pas

Je le remanie si et quand je dois y toucher. Le codage est typiquement comme ça :

1. Refactoriser le code existant (sans changer sa fonctionnalité) pour le préparer à accepter le nouveau code.
2. Ajouter un nouveau code (qui met en œuvre une fonctionnalité supplémentaire).

S'il y a une section de code que je dois simplement lire (sans même que je doive prouver qu'elle est correcte), je ne la modifierai pas (sauf peut-être, avec la permission, en la reformatant simplement).

Le coût du remaniement est intégré au coût du développement de la nouvelle fonctionnalité (c'est-à-dire que je ne demande pas la permission/le budget pour simplement remanier sans développer de nouvelle fonctionnalité) ; je me sentirai également plus responsable de l'exactitude du code après le remaniement.

Si j'ai besoin de justifier le remaniement, je me dis : "J'ai besoin de savoir que mon code est correct, et si je le trouve difficile à lire/comprendre, alors c'est difficile pour moi de le savoir."

Answer 3

Je pense cet article sur le blog de Philip Dorrell résume très bien une approche.

La version TLDR est que si le code est connu/prouvé pour fonctionner, sa valeur dépasse de loin sa beauté ou sa laideur. Si vous modifiez le code sans le tester vous diminuez effectivement sa valeur, même si, visuellement, elle semble identique.

Je vous recommande vivement cet article de blog si vous avez 5 à 10 minutes pour le lire.

Answer 4

J'ai eu à faire face à ce problème de temps en temps, et je peux compatir à l'ensemble de votre message. Vous devez faire attention à choisir vos batailles, car vous pouvez rapidement créer de la mauvaise volonté chez les personnes qui ne sont pas d'accord. Voici quelques options :

1. S'il s'agit d'un simple commentaire ou d'une modification mineure du code, ne vous en préoccupez pas tant que vous n'avez pas à revenir sur le code pour le modifier.
2. Si vous disposez d'une directive sur le style de code et qu'un code n'est pas conforme, je l'évoquerais lors d'une révision du code. Cependant, revenir en arrière et corriger le code d'autres personnes, juste pour le style, les mettra probablement en colère.
3. Si une seule personne de votre équipe ne fait aucun effort pour respecter le style de codage convenu ou ajoute des commentaires de mauvaise qualité, vous pourrez peut-être convaincre le reste de l'équipe de vous aider à faire le ménage de temps en temps. S'il ne s'agit que d'une seule personne, il est à espérer qu'elle en aura assez que des gens modifient son code et qu'elle essaiera de s'améliorer. Soyez prudent cependant, car même cette personne peut probablement se plaindre suffisamment auprès des responsables pour que quelque chose se retourne contre vous.
4. Ok, alors maintenant au point où il y a plus qu'un mauvais style, mais un code mal implémenté, bâclé, ou autre. Probablement que si c'est fonctionnellement correct, vous devriez juste laisser tel quel et passer à autre chose. Je le noterais simplement dans un journal et je verrais si vous pouvez éventuellement obtenir l'accord du reste de l'équipe pour le corriger plus tard.
5. Si le code présente des défauts, et que vous pouvez voir des erreurs abstraites, qui peuvent être testées, vous pouvez envoyer le cas de test au propriétaire, et peut-être lui faire corriger le problème. Encore une fois, si vous continuez à faire cela, vous risquez de vous attirer les foudres de la personne concernée, alors faites attention à ce que l'erreur soit pertinente dans une certaine mesure.
6. Si le code est tellement défectueux que vous pensez qu'il ne sera pas acceptable à long terme, alors je pense que vous devez avoir un face-à-face avec le développeur. Il est probable qu'il ne sera pas d'accord avec vous, mais s'il l'est, vous pourrez peut-être vous mettre d'accord sur un plan pour le corriger.
7. En supposant que le développeur ne soit pas d'accord avec vous, j'en parlerais à votre chef d'équipe pour voir ce qu'il en pense. S'il vous soutient, vous devriez aller de l'avant et demander au chef d'équipe de vous soutenir lors d'une autre réunion avec le développeur.

8. Si votre chef d'équipe n'est pas d'accord, alors je pense que vous devez laisser tomber et voir comment cela se passe à long terme. A partir de là, je pense que vous avez des choix importants à faire. Si le chef d'équipe et/ou les autres développeurs ne vous soutiennent pas, alors.. :

   • Vous devez soit accepter le fait que vous êtes trop critique envers vos collègues, soit vous détendre, le code ne sera jamais parfait.
   • L'autre cas, c'est que vous êtes dans un magasin qui ne sera jamais en mesure de produire un produit de haute qualité. Vous devez décider si vous voulez continuer à faire un investissement dans le groupe. Si la réponse est "non", commencez à mettre à jour votre CV.

Answer 5

Je voulais juste poser l'argument opposé à celui que tout le monde ici semble prendre. Le manque de rigueur dans votre code est une chose dangereuse et permettre à un code source désordonné et incohérent de ne pas être contrôlé peut conduire à d'énormes problèmes par la suite.

Dans un emploi précédent, il n'y avait pas de guide de style clair sur des choses comme la dénomination des variables ou des fonctions, ce qui signifie que vous deviez continuellement sauter dans la source de vos bibliothèques pour voir si c'était get_id() , getid() , getId() o getID() . Étant donné que ce code est continuellement travaillé et maintenu, il est muy Il est important d'éviter ces situations.

L'élaboration d'un guide de style standard définissant les conventions de dénomination, le style d'indentation, etc. contribuera grandement à améliorer la lisibilité et la maintenabilité de la base de données.

La correction du désordre de ce que vous avez déjà devrait probablement se faire de manière incrémentielle afin que a) la direction ne pense pas que vous ne faites pas de travail, et b) toute erreur introduite puisse être corrigée rapidement.