Quand le code propre devient nuisible

Je travaille dans l’industrie du logiciel depuis plus de 15 ans maintenant, et au fil du temps, j’ai l’impression de devenir de plus en plus délirant. En tant que développeur, j’ai subi un lavage de cerveau par la rhétorique de notre industrie pour croire que tout tourne autour de l’écriture de « code propre ». Vous savez de quoi je parle : parler est bon marché ; montre moi le code !

Nous ne sommes pas au courant, mais le problème start lorsque nous sommes des développeurs juniors. Nous sommes avides d’apprendre et demandons souvent conseil à nos pairs seniors. Nous demandons des choses comme : Quels livres recommandez-vous ? Deux des livres les plus recommandés sont Nettoyer le code et Le Pragmatique Programmeur. Ce sont deux excellents livres, et je pense que tout le monde devrait les lire. Les deux livres partagent certains des mêmes conseils et essaient de nous apprendre à écrire un meilleur code et à devenir de meilleurs professionnels. Cependant, ils ont des domaines d’intervention très différents.

Parmi de nombreux autres conseils, Nettoyer le code se concentre sur la prévention des doublons, la dénomination descriptive des variables, la cohérence du formatage du code, la réduction des fonctions et la garantie qu’elles ne font qu’une seule selected.

D’autre half, Le programmeur pragmatique se concentre sur des choses comme la structure d’équipes pragmatiques, nous apprenant que notre objectif en tant que développeurs devrait être de ravir les utilisateurs et qu’il n’est pas attainable d’écrire un logiciel parfait.

Après avoir lu les deux livres, nous retournons au travail désireux d’appliquer nos nouvelles connaissances. Le problème est que les conseils partagés par Nettoyer le code est beaucoup moins débattue et plus accessible à mettre en pratique que celle partagée par Le programmeur pragmatique. A mon humble avis, les conseils partagés par Le programmeur pragmatique est beaucoup plus profond et significatif.

Nous (développeurs juniors ou seniors) pouvons tous identifier et signaler quand l’un des membres de notre équipe essaie de fusionner une « classe divine » (une classe beaucoup trop grande et qui fait trop de choses). Cependant, essayer de décider si un logiciel est assez bon ou non peut s’avérer être le débat du siècle.

J’ai essayé de savoir si je suis le seul à ressentir cela en lisant des recommandations en ligne sur les deux livres. j’ai trouvé un Message Reddit dans lequel quelqu’un demande quel livre est le meilleur. Voici deux des commentaires que je voudrais décomposer :

Je recommande le programmeur pragmatique (premier). Il est plus facile à lire et contient plus d’informations sur une carrière de développement logiciel en général plutôt que sur le code.

La première recommandation semble renforcer l’idée de Le programmeur pragmatiquele contenu de étant beaucoup plus profond (« carrière de développement de logiciels en général ») que Nettoyer le code (« juste être sur le code »).

J’ai préféré le code propre automobile il s’agit davantage des principes de ce qui fait un bon ingénieur. J’ai lu le programmeur pragmatique mais je n’ai pas eu l’impression qu’il ait vraiment ajouté quoi que ce soit à mes compétences.
Je pense que le programmeur pragmatique vous montrera des modèles à utiliser et diverses options, tandis que le code propre sera une query de professionnalisme.
Donc, si vous voulez vous améliorer et faire de l’exercice, obtenez un code propre. Si vous avez besoin d’aide avec des modèles et des options, alors pragmatique.

La deuxième recommandation fait écho à mon sentiment que le Le programmeur pragmatique est moins exploitable. Le lecteur souligne à quel level « les principes de ce qui fait un bon ingénieur » se sont sentis inutiles (« cela a vraiment ajouté quelque selected à mes compétences »). D’autre half, le lecteur pourrait « s’améliorer » et « s’exercer » en utilisant les conseils de « professionnalisme » contenus dans Nettoyer le code.

Nous ne nous en rendons pas compte, mais avons un penchant inconscient pour donner la priorité aux conseils qui semblent plus exploitables et plus faciles à appliquer. Le problème avec ce biais, c’est qu’au fil du temps, on se focalise de plus en plus sur les conseils prodigués par Nettoyer le code et de moins en moins sur les conseils prodigués par Le programmeur pragmatique. Au fil du temps, les développeurs se concentrent davantage sur les problèmes liés au code et moins sur d’autres sorts de problèmes. Lorsque les choses ne vont pas bien, nous avons tendance à rechercher les causes dans le code plutôt qu’ailleurs.

Observe: Dans le code lui-même, nous sommes plus susceptibles d’identifier et de signaler des problèmes plus évidents et exploitables, tels que des problèmes de formatage, plutôt que des problèmes sémantiques d’API. Notre cerveau est biaisé pour inverser le Pyramide de revue de code. Par exemple, nous sommes très susceptibles de remarquer que le code se répète et d’essayer d’appliquer le Ne te répète pas (DRY) principe, alors que nous sommes beaucoup moins susceptibles de remarquer une mauvaise abstraction. Ce fait nous rend susceptibles d’introduire l’introduction et la mauvaise abstraction comme answer à un problème DRY sans être conscients de nos actions. Le problème est que la mauvaise abstraction coûte beaucoup plus cher que « la duplication est moins chère que la mauvaise abstraction ».

Pendant le reste de cet article, je ferai référence à ce kind de biais (dans le contexte de notre industrie) comme « l’phantasm du code ».

Observe: Ce biais vers des conseils actionnables est perceptible au-delà de notre code et affect nos processus et nos outils. Par exemple, de nombreuses organisations essaient de devenir plus agiles et adoptent des pratiques agiles telles que Scrum. Ils deviennent vite obsédés par les rituels Scrum (Standup, Dash planning…). Cette obsession est compréhensible automobile les rituels sont très actionnables. Le problème est que l’exécution de rituels n’est pas ce qui rend une organisation agile. Le manifeste Agile ne mentionne presque rien sur les rituels.

Vous pensez peut-être que ce n’est pas votre problème parce que vous n’avez peut-être pas lu ces livres, mais je vous garantis que vous êtes quotidiennement impacté par ce biais. Peu importe automobile ce biais est universel. J’utilise simplement les livres comme exemple; peut-être avez-vous acquis vos connaissances auprès d’un collègue plus expérimenté ou d’un cours en ligne. L’phantasm du code s’applique toujours à vous.

Quels sont les dommages causés par l’phantasm de code ? #

Lors du développement d’un produit logiciel, de nombreux facteurs déterminent si notre produit (et finalement notre organisation) échouera ou réussira. La façon dont je le vois; ces facteurs peuvent être regroupés comme go well with :

• Produit = UX + Ensemble de fonctionnalités + Préposition de valeur + Code
• Marché = Besoins non mérités + Consumer cible
• Tradition = Mission + Imaginative and prescient + Processus + Outils

Depuis le premier jour, mon industrie m’a lavé le cerveau pour croire que la qualité du code distingue les grands développeurs, mais au fur et à mesure que j’ai acquis de l’expérience, j’ai de plus en plus réalisé à quel level cette idée est délirante. Au fil du temps, je suis devenu plus conscient que les problèmes liés au code devraient être le cadet de mes soucis. La façon dont je le vois aujourd’hui, presque tout dans la liste ci-dessus l’emporte sur le code. Par exemple, je crois que l’UX est plus essential que le code ou que les processus et les outils sont plus critiques que le code.

Le mot « délire » a le sens suivant :

phantasm
/dɪˈluːʒ(ə)n/
nom
une croyance ou une impression idiosyncrasique maintenue malgré la contradiction avec la réalité ou un argument rationnel

Alors, quelle est la signification de l’phantasm de code ? Décomposons cette définition. Une « phantasm » est un mode de comportement ou une façon de penser. Dans le contexte du délire de code, ce mode de comportement est le parti pris du développeur envers le « code propre ». Nous pensons que lorsque les choses vont bien ou mal, la trigger doit être liée au code. À mon avis, cette croyance est contredite par la réalité. La qualité du code n’est qu’un tout petit facteur dans le destin d’une organisation.

Il y a quelques années, Google a publié une étude intitulée Les cinq clés d’une équipe Google performante. L’étude a mis en évidence ce qui go well with :

Il existe cinq dynamiques clés qui distinguent les équipes performantes des autres équipes de Google :

1. Sécurité psychologique : Peut-on prendre des risques dans cette équipe sans se sentir en insécurité ou gêné ?
2. Fiabilité: Pouvons-nous compter les uns sur les autres pour faire un travail de qualité dans les délais?
3. Construction & clarté : Les objectifs, les rôles et les plans d’exécution de notre équipe sont-ils clairs ?
4. Sens du travail : Travaillons-nous sur quelque selected qui est personnellement essential pour chacun de nous ?
5. Affect du travail : Croyons-nous fondamentalement que le travail que nous faisons est essential?

La sécurité psychologique était de loin la plus importante des cinq dynamiques que nous avons trouvées – c’est le fondement des quatre autres.

Mon expérience personnelle est que la sécurité psychologique est davantage compromise dans les équipes avec une tradition où la qualité du code est plus valorisée que tout le reste. Par exemple, les organisations qui tolèrent les « Sensible jerks ». Les brillants imbéciles sont des individus très performants capables de produire du code de haute qualité en un rien de temps. Cependant, ces individus ont des capacités d’intelligence émotionnelle très faibles. Des secousses brillantes donnent aux autres membres de l’équipe l’impression qu’ils sont de la merde à chaque fois qu’ils font une erreur de codage. Même lorsque la réalité est que l’erreur pourrait n’avoir aucun affect sur la efficiency globale de l’entreprise.

Il est temps de nous réévaluer ? #

Notre industrie croit que le code l’emporte sur tout le reste « bien qu’il soit contredit par la réalité ou un argument rationnel ». Cette façon de penser est si puissante qu’elle va au-delà de l’équipe de développement. Par exemple, une organisation peut décider qu’investir dans l’équipe de développement est une priorité plus élevée que d’investir dans l’équipe UX ou qu’elle devrait concevoir des entretiens pour se concentrer sur l’évaluation des compétences methods plutôt que sur l’intelligence émotionnelle.

J’en ai marre de me retrouver dans des équipes profondément frustrées pour des raisons telles que :

• Notre pile technologique est trop ancienne.
• Nos réunions debout prennent trop de temps.
• Notre couverture de check est trop faible.
• Quelqu’un essaie d’utiliser des espaces au lieu de tabulations.

Au lieu de raisons telles que :

• Nous n’investissons pas assez dans l’équipe UX.
• Il y a trop de tickets WIP.
• Nous ne faisons pas de check A/B.
• Nous ne parlons pas assez à nos utilisateurs.

J’ai vu de nombreuses équipes de développeurs expérimentés avec un price range pratiquement infini échouer. D’un autre côté, certaines des réussites les plus remarquables dont j’ai été témoin sont le résultat du travail d’un groupe de diplômés n’ayant presque aucune expérience préalable dans une startup avec pratiquement aucune ressource. Les causes de ce phénomène sont évidentes dans mon esprit. Dans les grandes entreprises, les développeurs n’ont pas à se soucier du prochain chèque de paie, ils passent donc beaucoup de temps à discuter des problèmes de code (par exemple, une refactorisation de 6 mois). Alors que dans les startups, la mentalité est « expédier ou mourir ».

Je suis développeur et je produis du code quotidiennement ; accepter qu’un bon code d’écriture n’est pas aussi essentiel que j’ai subi un lavage de cerveau pour le croire est une pilule difficile à avaler, mais je dois accepter la réalité. Viser la perfection du code dans les logiciels est non seulement irréaliste mais contre-productif. Cela entraîne toutes sortes de problèmes : optimisations prématurées, surcharge de fonctionnalités et ingénierie extreme..

L’écriture de code propre n’est pas ce qui fait d’un développeur un glorious développeur. Un bon développeur devrait :

• Soyez obsédé par la création de valeur shopper.
• Avoir un bon jugement pour parvenir à des compromis entre la qualité du code et la valeur shopper.
• Essaie d’écrire du code propre mais sait quand arrêter de le poursuivre.
• Sait que toutes les events d’une answer ne sont pas également critiques et ne poursuivra un code propre que lorsque cela en vaut la peine. Par exemple, les interfaces sont beaucoup plus importantes que les implémentations. Si vous obtenez les bonnes interfaces, le remplacement des implémentations au fil du temps ne devrait pas poser de problème.

L’phantasm du code nous fait souvent nous concentrer sur des choses qui n’ont souvent aucun sens et une perte de temps totale. Je ne préconise pas d’écrire du code spaghetti, mais j’ai le sentiment que l’utilisation de notre énergie pour nous concentrer sur l’excellence en ingénierie plutôt que sur la satisfaction des utilisateurs contribue à rendre une grande partie de notre industrie malheureuse. Nous devrions viser à écrire des logiciels suffisamment bons tout en nous rappelant que les développeurs ne décident pas quand un logiciel est suffisamment bon : les utilisateurs.

Remarque : Le titre de cet article est une lettre de référence de 1968 d’Edsger Dijkstra publiée sous le titre « Aller à la déclaration considérée comme nuisible ».