5 pires pratiques de codage pour ruiner votre relation avec vos collègues

Oui, vous ne vous trompez pas. Internet regorge déjà d'articles avec de bonnes recommandations et des tutoriels pour les développeurs. Vous pouvez en trouver un certain nombre sur mon blog . Cet article, excusez-moi, sera radicalement différent d'eux, mais en mieux ! Je vais parler de cinq péchés capitaux qui peuvent être commis dans le code. Grâce à ces pratiques dégoûtantes, quiconque doit travailler avec votre code vous détestera. Si vous êtes prêt à accepter cette connaissance secrète, alors allons-y.

Mauvaise pratique n°1 : faire des énigmes avec des noms

Prenons quelque chose de simple pour nous réchauffer. Un bon point de départ est d'ajouter plus d'abréviations aux noms de variables et de fonctions. Je sais, je sais, tout le monde dit que les bons noms doivent décrire le but aussi clairement que possible. Eh bien, il y a handleFormSubmit , getUserConfiguration ou parseCustomerInformation . Mais nous ne poursuivons pas les bonnes choses.



Pour le pire des résultats, essayez de raccourcir les mots et d'utiliser des acronymes aussi souvent que possible. Ensuite, le prochain développeur devra réfléchir pour comprendre ce que vous voulez dire. Voici quelques bons exemples : handleBtnClick , getConfig , parseInfo... Ils ne donnent pas trop d'informations, mais ils peuvent être facilement guidés à travers l'inspection du code. De plus, des abréviations inutiles comme btn , func , config , cb contribueront à compliquer la perception .



Et avec les noms des variables en général, vous pouvez faire demi-tour. Avez-vous une liste d'utilisateurs non vérifiés ? Ne l'appelez pas uncofirmedUsers , juste des utilisateurs . Ensuite, le prochain développeur sera obligé de lire tout le code qui renvoie la variable afin de comprendre à quoi cela sert. Aucun produit à prix réduitpour ce pauvre garçon, un simple produit au nom lui suffira.



Si vous voulez ajouter un peu de piquant aux noms, vous pouvez jouer avec le registre. Des collègues seront prêts à vous tuer, je vous le garantis. Au lieu de créer quelque chose dans l'esprit de readXmlDocument (c'est-à-dire en commençant les abréviations par une majuscule, comme des mots simples, selon les préceptes des bonnes pratiques), vous pouvez toujours construire une méthode readXMLDocument que vous ne pouvez pas saisir immédiatement et que vous devez lire il soigneusement.



Bien sûr, les inspections de code peuvent essayer d'arrêter toute cette folie, mais votre tâche est de vous battre. Peu importe pour quoi - à cause du fait que vous êtes trop paresseux pour régner, ou par désir de préserver votre réputation de bagarreur. Dans tous les cas, l'essentiel ici est de ne pas oublier : vous pouvez toujours promettre de tout changer pour la prochaine pull request et espérer qu'à ce moment-là, tout le monde sera pardonné et oublié (très probablement, cela arrivera).

Mauvaise pratique n°2 : Ecrire un code extrêmement complexe

C'est ici que se trouve l'opportunité de prouver que vous êtes le vrai Rick Sanchez de la programmation. Vous avez juste besoin de rendre le code un peu plus intelligent que nécessaire. Vous pourrez peut-être généraliser pour pouvoir utiliser trois lignes de code deux fois en créant une méthode qui prend cinq paramètres. Vous voudrez peut-être réduire trois lignes de code à une avec un opérateur d'imbrication ternaire intelligent. Laissez courir votre imagination!



Il deviendra bien sûr plus difficile de lire et de maintenir le code après cela. Mais ce sera sûrement un casse-tête pour vos collègues, et pas pour les vôtres ? Alors c'est super.



Alors allez, montrez que vous êtes un vrai hacker. Je vous conseille d'utiliser le chaînage de méthodes, les conditionnels imbriqués, les modèles de conception gonflés et les lignes simples qui tirent le meilleur parti possible des fonctionnalités de niche du langage hipster. Après tout, pourquoi écrire Date.now () si vous pouvez obtenir le même résultat avec le + new Date () un peu plus mystérieux ? Je suis sûr que les autres participants au projet s'attarderont sur le code avec un grand sentiment de gratitude, essayant de comprendre ce qui se passe en général.



Et n'oubliez pas : plus vous êtes sage et sur-optimisez dans le code, plus ce sera difficile pour vos collègues plus tard. Vous obtenez dix points pour chaque fonction de réduction et cent pour chaque appel récursif. À la fin du projet, à un tel rythme, vous deviendrez de vrais professionnels, ce dont je vous félicite.

Mauvaise pratique trois : importer autant que possible

J'admets : des problèmes avec la technique précédente peuvent survenir lors de l'étape d'inspection du code. Mais d'un autre côté, si vous écrivez en JS ou PHP, vous aurez tout un tas d'instructions import/use au début de presque chaque fichier. De nombreux développeurs ne les regardent même pas lors de l'inspection, ils passent immédiatement à ce qu'ils considèrent comme la pulpe elle-même. C'est pourquoi les dépendances sont l'occasion idéale de créer de l'horreur dans votre code. Imaginez



que vous ayez une vue UserSubscriptions dans une application React. Vous créez un fichier avec la fonction d'assistance calculateTimeToSubscriptionEnd... À la perfection. Mais où le placer ? Dans un répertoire séparé, où tout est stocké, à partir duquel se construit la logique de domaine des abonnements et des paiements ? Bien sûr que non. Mettez-le mieux à côté de la vue que vous venez de créer.



C'est ainsi que vous envisagez l'avenir, car lorsque vous avez enfin le panneau d'administration (et dans celui-ci - afficher les abonnements ), rien ne peut vous empêcher d'importer la fonction d'assistance à partir de vues personnalisées. Et personne ne le remarquera probablement, car personne ne se soucie de l'importation. Cela reliera deux modules complètement étrangers et créera un enfer sur terre pour quiconque essaie de refactoriser ou d'apporter des modifications. Croyez-moi, rien ne rendra fou un développeur plus vite qu'un projet avec une structure terrible.



Vous pourriez dire : « Eh bien, ce n'est pas grave non plus ». Les développeurs inexpérimentés n'essaieront pas de réparer quelque chose pendant longtemps. Ils souffriront de cette confusion par conviction que, probablement, il ne faut rien toucher ici. Chaque nouvelle tentative pour comprendre la structure de l'application causera des souffrances. Et si quelque chose lié à la fonction est mis à jour ou supprimé, cela deviendra encore pire. La confusion n'est pas grande, mais tout le monde en souffrira jusqu'à ce qu'il y ait un héros qui arrangera tout. C'est peut-être même vous.

Quatrième mauvaise pratique : écrire des comportements différents pour les mêmes fonctions

Vous considérez-vous comme une personne créative et artistiquement douée ? Alors voici une idée de torture que vous adorerez.



Le monde est un endroit imprévisible, et personne n'a jamais dit que tout fonctionnerait selon le même principe. Et que la cohérence et la prévisibilité sont la clé du travail productif du développeur et de la réussite du projet, personne ne l'a dit non plus... Je veux dire, beaucoup l'ont dit, mais aujourd'hui on ne les écoute pas. Nous avons l'intention de gâcher la journée de quelqu'un en lançant des fonctions similaires dans leur base de code qui se comportent légèrement différemment.



Par exemple, supposons que vous ayez une fonction de validation qui renvoie true si les données sont valides et un message d'erreur si quelque chose ne va pas. Que faire si le prochain validateur renvoie falseou indéfini pour les données valides ? Tout projet visant à préciser clairement la validation des données du formulaire s'effondrera. C'est bon.



Ou, disons, vous pouvez accepter des arguments dans chaque fonction dans un nouveau format. Supposons que l'un accepte les ID utilisateur et que l'autre n'accepte que l'objet entier dans son ensemble (même si en fait seul l'ID est nécessaire). Ou peut-être pouvez-vous demander l'adresse e-mail de l'utilisateur ? Cela gâchera le sang du développeur qui se verra remettre votre code.



Je suis sûr que vous trouverez des moyens encore plus ingénieux de surprendre vos collègues - vous pouvez tout rendre imprévisible. A bas la cohérence, vive l'arbitraire ! Et encore une chose : ne pensez jamais au niveau de la base de code dans son ensemble, essayez d'ajouter quelque chose d'intéressant à chaque fichier séparément. En d'autres termes, soyez un artiste, pas un ingénieur. Les autres développeurs de l'équipe vous détesteront de tout leur cœur - parce que, bien sûr, vous étiez en avance sur votre temps.

Mauvaise pratique n°5 : tout copier

Si vous donnez vie à cela, votre code ne sera certainement touché par personne. Ne divisez pas la logique commune entre différentes fonctions, classes ou composants. Copiez et collez simplement les lignes souhaitées d'un fichier à l'autre. Après tout, votre code est très précieux et sans faille, laissez les gens l'admirer tout au long du projet. Qu'il brille !



Cependant, ce n'est pas la seule raison de la duplication. En cas de mises à jour, les développeurs devront apporter des modifications à plusieurs fichiers à la fois. De plus, si quelqu'un rate un ou plusieurs cas de logique de copie (et si les tests du projet sont serrés, quelqu'un le ratera certainement), alors il devra re-punch le code une deuxième voire une troisième fois. Quoi de plus amusant que de rechercher des morceaux en double dans des centaines de fichiers de votre base de code ? Je suis sûr que vos collègues l'apprécieront.



N'oubliez pas que l'abstraction est difficile et prend du temps à bien faire, alors ne vous en souciez pas - copiez simplement le code selon vos besoins. Lors des inspections de code, cela sera traité avec compréhension. Sinon, vous pouvez passer le temps gagné à expliquer pourquoi votre code inestimable doit être reproduit. Tout s'arrangera, je crois en toi.



Bon, d'accord, Satan m'appelle ici, complétez.



Bien sûr, c'est un article de blague. Ne faites pas ce que j'ai écrit ici (sérieusement, non, je ne dilue pas faiblement). Faites l'inverse :

• assurez-vous que les titres sont clairs et informatifs ;
• écrire un code simple et compréhensible pour tout le monde ;
• créer une structure de projet claire ;
• n'oubliez pas la cohérence et la prévisibilité des interfaces ;
• partager une logique commune dans la mesure du possible sans compromettre la clarté.

Oui, et ne mettez jamais vos collègues en colère. Il y a un dicton dans la communauté des développeurs : écrivez du code comme si un tueur en série continuerait à travailler avec. Personne ne veut ruiner une relation avec un tueur en série, n'est-ce pas ? C'est la meme chose. Mais je n'aime pas cette logique. Il me semble qu'il vaut mieux écrire le code comme si vous continuerez vous-même à travailler avec. Demandez-vous simplement : « J'aimerais trouver ce fragment après avoir oublié pourquoi je l'ai écrit ? »