Comment gérez-vous le code intentionnellement mauvais?

21

Il y a beaucoup d'histoires sur le code intentionnellement mauvais, non seulement sur TheDailyWTF mais aussi sur SO. Les cas typiques incluent:

Avoir une construction inutile (par exemple une boucle vide comptant pour une valeur énorme) afin que les programmeurs puissent facilement "accélérer" l'application en la supprimant lorsqu'ils sont chargés de le faire.
Fournir une documentation intentionnellement trompeuse, erronée ou inexistante pour générer des demandes d'assistance coûteuses.
Générant facilement des erreurs, ou pire, générant même si tout fonctionnait bien, verrouillant l'application, un appel de support coûteux est nécessaire pour déverrouiller.

Ces points affichent une attitude plus ou moins malveillante (même si parfois par accident), surtout le premier point se produit assez souvent.

Comment traiter ces constructions? Ignorer le problème ou simplement supprimer le code incriminé? Aviser leur responsable ou parler à la personne qui a introduit la "fonctionnalité"?

bad-code

— mafu
source

10

Est-ce «parfois par accident» ou est-ce «intentionnellement mauvais»? Je ne vois pas comment ça peut être les deux.

7

La plupart des mauvais codes sont dus à un manque de compréhension et la solution est l'éducation.

Un code intentionnellement mauvais est entièrement différent, en raison de quelque chose de complètement indépendant de l'expérience du codeur ou du reste du projet. En tant que tel, vous devez découvrir pourquoi ils sabotent le code exprès et résoudre ce problème. Cela signifie, plus souvent qu'autrement, une politique de bureau, et c'est rarement une situation agréable pour quiconque.

La façon dont je gérerais le côté politique dépend de nombreuses circonstances (non précisées ci-dessus). Comment je gérerais le code, c'est d'abord de m'assurer que je ne suis pas le seul malentendu - qu'il s'agit vraiment d'un mauvais code - puis de corriger les lacunes évidentes. Si cela est raisonnablement possible, écrivez des tests indiquant que le mauvais code échouera. Revérifier que j'ai bien compris signifierait parler à la personne qui a écrit le code. Cela devrait être fait d'une manière très agréable et polie, sans assumer l'intention, et pourrait aider à trouver la raison (politique) sous-jacente nécessaire plus tard.

L'expédition est plus importante que la perfection de la tour d'ivoire, mais il y a deux points qui méritent d'être abordés. La correction des lacunes évidentes vous permet d'obtenir 80% des résultats avec 20% de l'effort, et ce type de fruit à faible pendaison mérite rarement d'être ignoré. Mais plus important encore, si vous ne répondez pas à la raison (politique) sous-jacente, il est probable que du code intentionnellement incorrect sera écrit et causera de nouveaux problèmes, voire empêchera l'expédition.

28

Je n'ai jamais (au cours des 20 dernières années) rencontré de code intentionnellement mauvais, mais les exemples que vous citez semblent (du moins pour moi, mais IANAL) être des tentatives de frauder un employeur ou un client, vous avez donc probablement un obligation de le signaler à votre responsable.

— gkrogers
source

2

D'accord. Personne n'écrit de mauvais code intentionnellement. Ils résolvent un problème, et ils le résolvent de la meilleure façon possible. Ils peuvent être mal orientés, sous-éduqués, ignorants, etc. Mais je ne peux pas vraiment imaginer un développeur qui écrit intentionnellement quelque chose qu'il sait être mauvais.

— Dan Ray

8

Même si ce n'est pas légal, au moins il y a une obligation éthique.

— Chris Farmer

@ChrisFarmer Vous ne pouvez pas séparer l'obligation éthique du contexte plus large - il existe des contextes où un code délibérément mauvais représente une résistance collective légitime, économique ou politique. (Et un contrat de travail ne mérite d'être honoré de bonne foi que lorsque la relation qu'il formalise n'est pas exploitable individuellement ou structurellement.)

— user234461

11

Dépend de la culture de l'entreprise. Plus souvent qu'autrement, ce n'est tout simplement pas votre travail de réparer et de nettoyer tout mauvais code.

De Coders at Work , la réflexion de Jamie Zawinski sur la suringénierie, qui peut également être appliquée dans cette situation:

À la fin de la journée, expédiez cette putain de chose! C'est génial de réécrire votre code et de le rendre plus propre et la troisième fois, ce sera vraiment joli. Mais ce n'est pas le sujet - vous n'êtes pas ici pour écrire du code; vous êtes ici pour expédier des produits.

Il y a beaucoup de mauvais codeurs et de codes là-bas, et essayer simplement de les corriger tous au fur et à mesure que vous les rencontrez, au détriment du projet / de la tâche en cours, ne vaut tout simplement pas la peine si le produit "fonctionne". Trop souvent, nous ne sommes que des programmeurs de ruban adhésif.

Voir aussi le post de Joel Spolsky: The Duct Tape Programmer

— éponge
source

+1 Je suis vraiment fan du concept d'expédition de produits. Je pense que trop de profils techniques manquent à ce concept.

+1 Moi aussi. Il y a beaucoup trop de types de "code propre" de livres, etc. qui approuvent une vision biaisée de ce qui est important. La qualité du code n'est que si importante. Les gagnants ne sont pas ceux qui ont le meilleur produit. Ce sont ceux qui ont un produit assez bon expédié assez rapidement.

— Joonas Pulakka

4

Je pense que vous avez manqué le point de la question - le gars a parlé de code intentionnellement mauvais , pas simplement de code écrit par de mauvais programmeurs.

— Hila

@Hila Je crois que mon argument tient toujours, que le mauvais code soit intentionnel ou non. À moins que ce soit un problème qui figurait sur la liste des projets / tâches assignée, il n'est pas de la responsabilité d'un programmeur de ruban adhésif de réparer et de nettoyer tout le mauvais code . La culture là-bas n'est pas académique et pour écrire du code propre / beau. Il s'agit d'expédier et de soutenir un produit / une entreprise. Personnellement, j'aimerais réparer tous les mauvais codes que je rencontre, mais je ne peux pas y consacrer 100% de mon temps - je ne serais tout simplement jamais en mesure de terminer la tâche / le projet qui m'a été assigné.

— spong

3

@sunpech Mais nettoyer un code intentionnellement mauvais n'est pas la même chose que nettoyer n'importe quel code. Il ne s'agit pas de rendre votre application plus "belle", il s'agit de corriger du code nuisible qui a été mis exprès à cet effet. C'est comme dire qu'un médecin ne devrait pas retirer de ciseaux qu'un collègue a oublié à l'intérieur d'un patient, car une chirurgie cardiothoracique vise à sauver des vies et non à savoir à quel point les points sont jolis.

— Hila

4

Cette attitude est le symptôme de quelque chose de pire.

La direction encourage-t-elle la concurrence des développeurs?
Où est l'esprit d'équipe?
Les tâches sont-elles attribuées par quelqu'un d'autre que l'équipe elle-même?
...

Dans tous les cas, la suppression du code incriminé ne suffit pas. Se plaindre à son manager n'aidera certainement pas à améliorer l'esprit d'équipe.

J'essayerais de parler directement à la personne et essayer de comprendre pourquoi en posant beaucoup de questions sans la juger. Toute l'équipe doit le faire sans agressivité.

Dans la plupart des cas, ce comportement constructif met en lumière le vrai problème (le pire), puis vous pouvez y travailler.

Si ça ne marche vraiment pas. Supprimez ce développeur de l'équipe.

4

Si je pensais que c'était intentionnel, je licencierais probablement le gars! Si c'est le résultat de quelqu'un qui n'est pas assez bon programmeur, je travaillerais sur ses compétences. Si c'était poussé d'en haut, je commencerais probablement à chercher un nouvel emploi.

— Zachary K
source

2

Comment traiter ces constructions? Ignorer le problème ou simplement supprimer le code incriminé? Aviser leur responsable ou parler à la personne qui a introduit la "fonctionnalité"?

Selon le contexte, l'un de ceux-ci pourrait être le plus approprié. Parmi les autres possibilités, citons la demande de transfert vers un autre projet, l'obtention d'un nouvel emploi et divers actes de moralité et / ou de légalité discutables.

Cependant, étant donné que nous ne connaissons pas les faits réels et les vraies personnes impliquées, il n'y a aucun moyen que quelqu'un dans la position que vous décrivez devrait prêter beaucoup d'attention à nos conseils / 2 cents.

S'il s'agit d'une situation réelle dont vous parlez, il peut être utile d'avoir un mot discret avec votre responsable pour lui demander conseil sur ce que vous devez faire. Si possible, essayez de discuter de ce que vous pouvez / devez faire, pas de pointer du doigt. Si possible, ne nommez pas de noms. Il y a de fortes chances que votre manager ait déjà une idée du problème.

Mais le revers de la médaille est que vous pourriez souffler cela hors de proportion. Réfléchissez bien à cela avant de faire quoi que ce soit. Pensez aux conséquences, y compris la possibilité que toutes les mesures que vous prenez puissent se retourner contre vous ... mal.

— Stephen C
source