Comment équilibrer la qualité du code et les fortes personnalités des développeurs

Sur les revues de code au travail, j'ai vu du code et des modèles que je considère "intelligents" mais qui n'ajoutent pas nécessairement à la qualité globale ou à la maintenabilité de la base de code. Je le signale dans mes commentaires et je ne suis pas convaincu par les contre-arguments. Je suis un peu inquiet lorsque ce code se transforme en repo et plus tard en production.

Je veux maintenir une équipe soudée, donc je ne veux pas créer de tension en exprimant trop mes réserves. Je veux aussi créer un excellent produit pour nos clients sans être trop indulgent.

Traditionnellement, qui a le droit de veto sur ce qui est enregistré et comment?

Comment le code qui fonctionne, mais son trop impliqué / intelligent peut être supprimé sans marcher sur les orteils?

J'adore cette citation:

"Le débogage est deux fois plus difficile que d'écrire le code en premier lieu. Par conséquent, si vous écrivez le code aussi intelligemment que possible, vous n'êtes, par définition, pas assez intelligent pour le déboguer." - Brian W. Kernighan

D'un côté, cela vous fatigue du code trop intelligent, car il sera difficile de déboguer et d'étendre plus tard.

D'un autre côté, un code intelligent qui fonctionne est un excellent moyen d'apprendre. Probablement pour toute l'équipe. Qu'en est-il d'encourager l'auteur à donner une petite discussion informelle sur le code à ses collègues? Assurez-vous simplement que cela fonctionne vraiment comme prévu et que cela a du sens dans le projet dans son ensemble. Vous ne voulez pas en faire une compétition inutile!

Si vous ne pensez pas que cela ajoute de la valeur, placez le contre-défi en demandant: "Comment pouvez-vous refactoriser cette partie (vous avez des tests en place, non?) Pour qu'elle soit plus lisible?" N'oubliez pas qu'il est plus difficile de créer un code intelligent et lisible que de créer des pépites impénétrables.

Mon conseil est de jouer l'idiot, quand il est temps de passer en revue le code, n'hésitez pas à dire que vous n'avez pas la moindre idée de comment cela fonctionne (si votre ego a besoin d'un massage, vous pouvez dire que vous n'avez pas eu le temps de le comprendre) ) et demandez au développeur de l'expliquer. Quand il a fini, vous pouvez suggérer qu'il note tout cela comme un commentaire pour une maintenance future, avec l'indication implicite que c'est trop compliqué pour être considéré comme un «bon» code.

Si son bon code est juste un peu trop compliqué, la plupart des gens auront une idée, sans que rien n'ait été dit sur la qualité du code ou l'expertise des développeurs.

PS. De toute évidence, la plupart de ce code sera de toute façon subjectif, donc le code incroyablement intelligent d'une personne pourrait être un algorithme raisonnable et peut-être même standard pour un autre développeur, de sorte que vous ne pouvez pas accuser directement quelqu'un d'écrire du mauvais code (sauf lorsqu'il est évident) comme l'entrepreneur qui a copié un tableau d'octets dans une liste stl, l'a passé dans une routine de chiffrement, puis l'a reconverti en tableau d'octets!)

Ma règle d'or est de plier les directives de qualité du code en faveur de fortes personnalités de développeur. Je l'utilise toujours quand je n'ai pas le temps de creuser assez profondément - une telle creuser au passage demande généralement beaucoup d'efforts (plus de détails ci-dessous).

Cette règle est basée sur l'expérience personnelle. J'ai commencé (probablement comme tout néophyte) en suivant fanatiquement les directives et en combattant minutieusement chaque déviation. Avec le temps, j'ai acquis suffisamment de compétences et appris suffisamment de tours pour gagner de tels combats avec une relative facilité - ce qui a permis de se concentrer davantage sur l'apprentissage de l'impact global de mes "victoires". Et pour autant que je sache, l'impact a été plutôt négatif - les gars qui "ont perdu le combat" souffraient et sont devenus moins productifs - et, vous savez, le fait que leur code était conforme à 200% aux directives de qualité n'a pas compensé cela.

Cette découverte m'a fait abandonner la plupart des combats, ce qui à son tour m'a permis d'avoir plus de temps pour analyser les cas problématiques. Et j'ai trouvé que lorsque je creuse assez profondément, il y a généralement un problème de conception intéressant quelque part derrière, un problème subtil (ou pas trop subtil) qui se cachait juste derrière les combats de personnalités.

• C'est comme, vous savez, comme disons que je trouve un fichier source de 31 Ko dépassant la limite de taille recommandée, c'est-à-dire 30 Ko. Mes options sont soit de passer quelques minutes / heures à lutter pour forcer le propriétaire du fichier à extraire ce kilo-octet supplémentaire soit à passer une journée ou deux à réfléchir et à creuser pour découvrir, disons, qu'il existe une API de bibliothèque qui peut être utilisée à la place de tout. le code dans ce fichier (afin qu'il puisse être simplement supprimé).

Une telle découverte peut parfois ne pas être très utile du point de vue de l'utilisateur final (bien qu'elle puisse parfois avoir un impact profond en effet), mais je dois admettre que le plaisir que j'obtiens quand casser un tel écrou en vaut la peine de toute façon ... et en tant que cerise sur l'écart des lignes directrices du gâteau disparaît également sans combat. :)

Votre organisation doit disposer d'un document de directives / normes de codage qui est périodiquement mis à jour avec la contribution de l'équipe de développement. Ce document peut énoncer des détails, comme: comment nommer des variables, comment formater du code, etc. Le document doit également expliquer les valeurs que l'organisation s'attend à ce que les programmeurs adoptent par écrit du code, y compris l'importance relative de choses comme la lisibilité, la maintenabilité, l'exactitude, l'efficacité et le respect des normes.

Les révisions de code devraient être effectuées en utilisant ce document de normes de codage. Si les normes de codage indiquent que les programmeurs devraient préférer la lisibilité à la brièveté lorsque les deux sont en conflit, alors vous aurez un certain soutien pour argumenter contre le code "intelligent". Si les normes ne le disent pas et que vous pensez qu'elles le devraient, vous pouvez en discuter dans l'abstrait lors de la réunion des normes de codage plutôt que d'essayer de comprendre quand l'ego de quelqu'un est en jeu.

En fin de compte, cela revient parfois à un jugement, et dans ces cas, le dernier mot devrait revenir à la personne qui est ultimement responsable du code et / ou du produit. C'est généralement quelqu'un comme un développeur senior, un responsable technique, un chef de projet ou un directeur de l'ingénierie. Si vous êtes le responsable et que vous estimez que certains codes ne sont pas suffisamment maintenables, vous ne devriez pas avoir peur de le dire. Vous pouvez être diplomate à ce sujet:

Sam, je suis impressionné par votre ingéniosité ici, mais je crains que ce soit un peu trop intelligent. J'aurai besoin que vous travailliez sur un nouveau développement dans un an plutôt que de le maintenir, et je crains que quiconque doit le maintenir ne comprenne pas pleinement son caractère génial. Je sais que vous détestez le faire, mais je vous serais reconnaissant de revenir à la mise en œuvre simple dont nous avons discuté.

D'un autre côté, si vous n'êtes pas le responsable, le mieux que vous puissiez faire est d'expliquer clairement votre position et d'essayer de convaincre le reste de l'équipe. Si vous n'obtenez pas de soutien du gestionnaire, acceptez que ce n'est pas votre appel et passez à autre chose.

Chez vous (et je fais parfois partie de ces smartasses), je ne le retirerais pas, mais je demande personnellement à l'auteur plein d'esprit de le documenter très bien dans les commentaires et, si possible, d'inclure une discussion sur les alternatives et des écrits plus simples qu'il aurait pu utiliser, avec des exemples.

Je soulignerais que c'est pour le mieux, car même lui ne se souviendra probablement pas de tous les bits et bobs qu'il y a, dans ces lignes, dans deux mois.

Il abandonnera probablement le code intelligent en faveur du plus simple, dès qu'il sera forcé de l'écrire, par exemple.

Pourquoi cela fonctionnerait-il?

• Vous avez reconnu que vous vous souciez de ce qu'il écrit ,
• vous lui avez montré du respect en lui demandant :
• en citant des problèmes de mémoire / de concentration, vous imaginez et décomposez-lui un scénario dans lequel ce code doit être changé et ne peut pas pendant qu'il travaille encore pour l'entreprise ou l'équipe

(sans cette dernière allusion, ce type de demande peut être reçu comme un essai, du côté de la société, pour banaliser le programmeur , le rendant interchangeable avec tout autre singe de code à tout moment)

D'après mon expérience, il est généralement très difficile d'obtenir du code qui satisfait toutes les exigences de la base de code.

Cependant, la prochaine fois que le code doit être maintenu, vous pouvez facilement plaider pour son remplacement en tant que mesure d'économie future car l'ancien code était plus difficile à maintenir.

En ce qui concerne le droit de veto, la direction l'a évidemment.
Parfois, ce sont des équipes ou des comités qui sont chargés de la qualité du code, auquel cas ils auraient également ce pouvoir.

Il serait également utile de donner un exemple de schéma «intelligent». Peut-être que vous réagissez simplement de manière excessive ...

«intelligent» n'est presque jamais une mauvaise chose dans mon livre, mais je peux convenir qu'il peut y avoir une pente glissante entre intelligent et alambiqué.

Comme beaucoup d'autres pratiques, je pense que la réponse est que cela dépend .

• S'il s'agit d'un défaut, il doit définitivement être corrigé.
• Si le code fonctionne, vous devez équilibrer la valeur d'insister pour que le code soit modifié par rapport au coût futur du code intelligent. Bien qu'il existe des règles générales concernant le rapport entre les travaux de développement et les travaux de maintenance, ils varient beaucoup d'un projet à l'autre. Être raisonnable.
• Demandez-vous pourquoi vous ne parvenez pas à convaincre votre coéquipier que le code doit être simplifié?
• Il n'est pas toujours nécessaire que tout soit parfait. Cela signifierait des révisions de code dans une boucle infinie et rien de vérifié car rien (sauf mon code, haha) n'est parfait.
• Ma préférence personnelle est que l'auteur du code ait le dernier mot. Évidemment, s'ils font continuellement un très mauvais travail, une autre action doit être prise, mais comme vous le dites, la valeur négative de forcer le développeur à changer le code peut être supérieure au gain réalisé en le corrigeant si c'est une situation très rare .

Je peux certainement comprendre cette question. Je suis actuellement responsable technique de 2 équipes et c'est mon travail de m'assurer que le code que nous produisons est aussi lisible et maintenable que possible. En même temps, je suis connu pour produire du code "intelligent" et je sais que la plupart de mes coéquipiers auront du mal à le suivre.

Quelques observations que je peux offrir:

1. Votre équipe a besoin d'un responsable qui prendra la décision ultime en cas de désaccord. Dans la dernière version, j'étais dans une équipe sans leadership et c'était atroce. Tout est devenu un argument, et si vous avez peu de gens avec de fortes personnalités, aucun d'eux ne bougera. Si vous avez un lead, quelle que soit la décision choisie, tout le monde dans l'équipe DOIT comprendre que ce que dit le lead va. C'est pourquoi la direction l'a fait diriger.

2. Il est très important de garder les gens heureux. Par conséquent, au lieu de pousser toute l'équipe vers votre point de vue, il vous suffit de la pousser là-bas. Expliquez les principes SOLIDES, expliquez l'importance des classes / méthodes / interfaces petites et cohérentes et répétez ces choses chaque fois que vous les voyez violées (c'est-à-dire dans une revue de code). En même temps, ne leur faites pas réécrire chaque chose que vous n'aimez pas. À la fin de la journée, vous avez besoin d'un équilibre entre l'expression personnelle et les normes de groupe suivantes. Espérons que les deux convergeront à mesure que les préférences personnelles évoluent vers la façon dont le groupe en général fonctionne.

3. Je crois qu'il est beaucoup plus important d'avoir des interfaces de classe propres et faciles à comprendre que de ne jamais avoir de code "intelligent". Par exemple, nous avons une classe qui maintient une liste d'entrées qui sont recherchées de 3 manières différentes. Actuellement, il utilise simplement la recherche linéaire pour toutes les recherches, ce qui fonctionne à petite échelle, mais parce que cette classe est à un niveau très bas, je la vois mal évoluer. Je suis sur le point de le remplacer par une classe différente, qui utilise des conteneurs Boost Intrusive. Chaque élément prendra en charge d'être placé dans chacun des index simultanément et toutes les recherches seront effectuées dans O (sqrt (N)). Oui, ce sera beaucoup plus compliqué à l'intérieur et beaucoup de gens n'aiment pas Boost, mais à l'extérieur, il restera 3 méthodes: Ajouter, Supprimer, Obtenir. En fin de compte, les gens peuvent écrire le code qu'ils veulent (dans des limites raisonnables),

4. Maintenez l'idée de la propriété du code. Bien qu'il soit parfois difficile à réaliser car différentes personnes peuvent avoir besoin d'ajouter / modifier du code. Lorsque le code est écrit, le développeur d'origine est le gardien ultime de ce code. Cela ne signifie pas que personne d'autre ne peut y toucher. Si d'autres modifient leur code, c'est bien, mais à la fin de la journée, le développeur d'origine le vérifie et reste responsable de tout ce qui s'y trouve. Que ce code soit simple ou intelligent, c'est son bébé. Si / quand, comme vous le prédisez, les bogues commencent à s'accumuler à cause des décisions de conception / codage qui ont été prises, au lieu de simplement corriger ces bogues à mesure qu'ils arrivent, asseyez-vous avec ce développeur (qui btw devrait corriger tous ces bogues) et réfléchir à ces décisions pour voir comment elles auraient pu être prises différemment.

J'ai passé de nombreuses années à diriger et gérer des équipes de développement. Par nature, je suis un peu OCD en termes de code et très noir et blanc. J'ai appris par expérience que choisir ses batailles est l'une des compétences les plus difficiles à apprendre en tant que chef d'équipe. Oui, les normes sont importantes. Oui, la lisibilité et la maintenabilité sont extrêmement importantes. Oui, nous devons tous nous efforcer d'écrire du code uniforme et conforme aux normes. Mais les développeurs sont des humains ... pas des outils de génération de code. Nous avons des personnalités, des opinions, nous nous ennuyons et nous voulons apprendre de nouvelles choses.

Sur les revues de code au travail, j'ai vu du code et des modèles que je considère "intelligents" mais qui n'ajoutent pas nécessairement à la qualité globale ou à la maintenabilité de la base de code.

OK ... donc ils n'ajoutent rien, mais nuisent-ils? Parlons-nous simplement d'une question de préférence personnelle dans les styles de codage, ou le code est-il écrit complètement inutile (par exemple, en utilisant des arbres d'expression et de la réflexion simplement parce que c'est amusant d'utiliser des arbres d'expression et de la réflexion)? Si c'est le premier, laissez tomber. Une partie du plaisir d'être développeur consiste à trouver des solutions créatives aux problèmes. Peut-être (et la plupart d'entre nous n'aiment pas l'admettre), nous nous sentons parfois intimidés par des approches que nous ne comprenons pas, et soit nous ne voulons pas demander, soit nous n'avons pas l'énergie supplémentaire pour apprendre la nouvelle approche.

Maintenant, lorsque la créativité conduit à un code inutile et à une complexité complètement injustifiable, alors par tous les moyens, exprimez-vous et défendez votre cause. Être un joueur d'équipe est important, mais il faut aussi (et tenir les autres) responsables. Les révisions de code concernent autant la responsabilité que l'assurance qualité et l'apprentissage. Vous allez marcher sur certains orteils, mais si vous sentez que vous avez un argument fort pour lequel des efforts (de l'argent) devraient être dépensés pour réécrire le code de travail ET un ego devrait être meurtri dans le processus ET vous voulez risquer d'écraser l'enthousiasme de quelqu'un pour son métier , alors vous ne devriez pas hésiter à le mettre sur la table. Si vous êtes le chef d'équipe, c'est votre travail. Soyez conscient de l'impact et faites-le. Si vous n'êtes pas un chef d'équipe et que vous n'en avez pas l'autorité, laissez-le à l'équipe de décider.

La meilleure façon d'inculquer la responsabilité à votre équipe est d'encourager les autres à vous tenir pour responsable. Si vous gardez un esprit ouvert et ne fermez pas les gens lorsqu'ils suggèrent des améliorations à votre code, vous trouverez peut-être qu'ils sont plus réceptifs à vos suggestions.

Par expérience personnelle, lorsque cela se produit, je demanderais la permission d'être un testeur d'unité accusatoire volontaire pour passer des tests afin de torturer la mise en œuvre inconnue.

Je ferai de mon mieux pour vraiment comprendre comment fonctionne le code, et j'essaierai également de l'explorer de différentes manières.

Notez qu'il s'agit d'un engagement de temps. Ce peut être des heures, voire des dizaines d'heures, voire une bonne partie d'une semaine. Le fait qu'il soit justifié dépend de la question de savoir si la complexité du code est proportionnelle à la complexité de l'exigence.

Si je ne l'emportais pas, c'est-à-dire si le code survit aux nombreux tests, je me convaincrais que l'implémentation est peut-être vraiment plus éclairée que moi, et je soutiendrai son inclusion dans le produit principal.

Selon la méthodologie de contrôle des sources, le code peut devoir être provisoirement validé dans le système de contrôle des sources (peut-être dans une branche) avant que cette phase de test puisse commencer.

Ma réponse est colorée par mon expérience d'utilisation d'OpenCV. Il existe des algorithmes beaucoup plus sophistiqués que n'importe quel programmeur ne peut implémenter seul; pas même les docteurs - peut-être les premiers pourcentages de docteurs. Si le code est si bon, vous devez lui faire confiance, en agissant contre vos propres instincts et préjugés, même si vous ne disposez pas de moyens efficaces pour quantifier ce niveau de confiance.