En programmation, la Technique Duck est une technique par laquelle vous placez un oubli évident et facile dans votre code dans l'espoir qu'il attirera l'attention lors de la révision et atténuera les changements de conception importants et chronophages.
Il y avait cette équipe dans mon entreprise bien connue pour être très pointilleuse au moment de la révision; Si nous utilisions Lib A, ils voudraient la Lib B. Mais si nous avions utilisé Lib B, ils voudraient Lib A. Ils ne sont pas satisfaits de ce modèle de conception et veulent en voir un autre. Mais je jure que si nous avions utilisé à l'origine le modèle, ils ont suggéré qu'ils auraient voulu l'autre. C'était comme s'ils devaient ajouter quelques commentaires pour démontrer leur valeur. Ces grands changements étaient problématiques car ils pouvaient transformer une tâche d'une heure en plusieurs heures, s'éternisant au fil des jours, bloquant la progression. Et je sais ce que vous pensez: pourquoi ne pas discuter du changement avec cette équipe au préalable? Nous faisions. Nous avions des réunions pour présenter le changement, expliquer comment la conception maintient la compatibilité ascendante et nous assurer qu'ils se sentaient entendus, avaient des commentaires et étaient à bord. Cela n'avait pas d'importance. Une fois que la révision du code est arrivée, c'était comme si tout ce qui était convenu avait été oublié.
À un moment donné, un collègue et moi avons dû modifier une bibliothèque que nous utilisions et qu'ils possédaient afin que nous puissions utiliser le modification de notre programme. C'était un petit changement, mais nous avons soupiré, nous nous sommes accroupis et nous y sommes arrivés, nous préparant à la révision du code. Nous étions en train de programmer le changement en binôme et de lui donner un bref aperçu avant de le soumettre à la révision du code. Connaissant la tendance à la perspicacité de cette autre équipe, j'avais une idée:
Coéquipier: Devrions-nous remplacer cela ici par la syntaxe abrégée de la dernière version du langage introduite?
Moi: Bonne idée ... en fait, laissez-la pour le moment.
Il y a eu quelques autres cas. Rien de critique comme laisser un bogue mais des choses comme laisser la syntaxe que nous savions que l'autre équipe n'aimait pas, laissant de la place pour les méthodes à extraire ou les variables à renommer. Cela a fonctionné à merveille. Ils ont commenté chaque canard, nous avons répondu "Merci! Réparer maintenant!" et c'était ça. La révision du code s'est terminée en 10 minutes environ et nous avons pu continuer sans être bloqués.
Mais cela m'a fait réfléchir, y a-t-il des problèmes d'éthique à ce sujet? Je n'aime pas particulièrement le faire et je ne le fais pour aucune autre équipe. Mais dans ce cas, nous avons pu transformer une révision de code potentielle de 2 heures dans les deux sens en 10 minutes. Une victoire dans mon livre. Je suis curieux de savoir ce que les autres pensent ou s'ils ont des solutions alternatives pour faire face à des équipes difficiles.
Modifier pour plus de clarté: cette question ne cesse de se poser, donc je voulais y répondre ici.
Si l'équipe perd le temps de tout le monde, pourquoi ne pas les affronter, les repousser ou parler à la direction?
Nous avons d'abord suivi tous les canaux habituels / officiels . Ils n'ont pas eu le dernier mot sur la révision du code (bien que ne pas obtenir leur adhésion aurait été une perte politique pour moi) et tout ce qui était carrément stupide ou dangereux, nous ne nous accommoderions pas, mais parfois l'acquiescement à la demande permettrait d'économiser davantage temps sur le long terme. Je changerais volontiers de petits trucs comme "espaces vs tabulation" ou "placement d'accolades". Des choses plus importantes sur lesquelles je repousserais et demanderais une raison pour laquelle il valait la peine de passer du temps à faire le changement. Parfois cela fonctionnait parfois non. Moi-même et d'autres les avaient approchés individuellement soit au travail, soit au déjeuner ou autour de bières en disant que ces changements de conception de code étaient préjudiciables au progrès et difficiles à travailler. J'ai signalé leur comportement comme problématique à la direction et d'autres peuvent l'être également.
Dans l'idéal, on leur dirait que leur comportement est inacceptable, on verrait leurs erreurs et on changerait. Mais les humains ne sont pas des ordinateurs et n'ont pas vraiment à faire quoi que ce soit de la manière que moi-même ou n'importe qui d'autre voudrait voir faire, indépendamment du temps et de l'argent gaspillés par l'entreprise. Toute critique pourrait être contrée par "Nous ne perdons pas de temps, nous nous assurons que le code est fait de la bonne façon. Cela vaut certainement un peu plus de temps à l'avance, n'est-ce pas?" Ce n'est malheureusement pas vraiment noir et blanc et à la fin, comme je l'ai mentionné quelque part ci-dessous, j'ai décidé que ce n'était pas une colline sur laquelle je voulais mourir. Surtout parce que mes interactions directes avec cette équipe étaient peu fréquentes.
Il est difficile d'expliquer en plus de le décrire comme "difficile pour des raisons de pointillosité". Par exemple, nous avons essayé d'automatiser les éléments stylistiques puisque c'est une tâche de l'éditeur, mais ils proposeraient des règles alambiquées que l'éditeur ne pouvait tout simplement pas gérer de manière cohérente. Je ne pense pas qu'ils étaient malveillants. Des trucs comme, peut-être qu'une semaine ils aimeraient vraiment le Pattern A. Sachant cela, je m'assurerais d'utiliser le Pattern A sur leur code le cas échéant. Mais à un moment donné, ils ont lu quelque part que le modèle A est mauvais et que tout le monde devrait utiliser le modèle B. viendrait au moment de l'examen. Ils avaient un petit fief étrange et ils le dirigeaient d'une main de fer, mais ils étaient dans l'entreprise depuis longtemps et la direction les aimait. Ils formaient finalement un joli groupe de personnes, juste un peu bizarre. C'est juste une de ces choses étranges sur le lieu de travail qui semblent probablement folles à moins que vous n'ayez rencontré quelque chose de similaire.