Dans un processus de développement, plusieurs règles doivent être respectées afin que le code puisse être facilement compréhensible par un autre et donc que la maintenance ne soit pas une épreuve digne d’un des travaux d’Hercule. Au vu de certains manquements qu’il a observés dans les habitudes, Steven A. Lowe, développeur consultant, a rédigé un billet satirique qui exalte la culture de l’obscurantisme.Vous vous inquiétez parce qu’un développeur pourrait venir gâcher la beauté immaculée de votre solution si soigneusement élaborée ? Ne serait-il pas préférable d’écrire un code que personne à part vous ne serait capable de comprendre, un code qui serait regardé avec crainte et respect et qui vivra éternellement dans l’entreprise parce que personne n’aura osé le toucher ? Ce n’est pas facile, mais avec un peu d’effort, vous pourrez développer les habitudes et la discipline pour écrire ce code qui va durer éternellement. Comment ?
Ne rien tester :
Les tests sont juste une perte de temps. Ils vous donnent une illusion de confiance et pourraient révéler à une tierce personne comment les choses fonctionnent. Si vous devez écrire des tests, faites-le en dernier et affirmez juste qu’ils sont concluants. Ne les écrivez surtout pas de prime abord et ne vous en servez pas pour guider la conception ; un code développé de cette façon est trop facile à comprendre et à changer.
Ne rien modifier :
Tout d’abord s’il n’y a pas de bug, n’essayez pas de colmater de failles. Ensuite, personne n’a le temps d’évoluer en élégance et simplicité. Les développements pilotés par des tests, s’ils sont requis, peuvent être transformés en une liste d’éléments affublés de la mention vérifié / pas vérifié.
Écrire du code indéchiffrable :
Donnez des noms à vos classes et vos méthodes pour reformuler ce qu’elles font, pas leur responsabilité. Des noms comme ObtenirLesAchatsPrealablesDuMemeProduit sont trop longs et trop informatifs. RechercherSemblables serait beaucoup mieux. Ou encore Rechercher tout simplement. C’est simple : les noms génériques ça déchire ! Aussi, il faut les utiliser autant que possible.
Il faut utiliser les abréviations et les acronymes pour nommer les interfaces. Il faut utiliser les structures génériques, pas seulement pour économiser en temps et en effort, mais également pour masquer les informations de type. Gardez les structures fortement typées pour des ensembles non typés. Faites des tableaux de tout.
De façon occasionnelle (pas trop souvent quand même), donnez aux variables des noms qui impliquent les mauvais types comme nommer une valeur numérique à virgule flottante MessageTexte. Passez des valeurs en utilisant Object ou String et n’encapsulez pas les types de valeur. Si vous devez utiliser des constantes, donnez-leur le même nom que leurs valeurs ou alors utilisez des noms avec des lettres grecques.
Les commentaires sont une opportunité pour mal orienter. Aussi, les meilleurs commentaires vont simplement répéter ce que le code fait et restent les mêmes après que le code soit changé. Gardez à l’esprit que la personne qui lit votre code ne doit voir que le reflet de ce qu’il fait au niveau de l’implémentation : l’ouverture de connexions, la recherche des résultats, le traitement, le retour des résultats, etc.
Écrire du code illisible :
La lecture du code d’autres personnes est une perte de temps et pourrait corrompre votre style créatif. Insistez sur vos propres normes et conventions, mais ne les documentez jamais.
Les espaces sont des gaspillages. Le code sera compilé bien plus vite sans tous ces caractères supplémentaires et la séparation pourrait rendre le code plus lisible. Mettez donc tout sur une seule ligne aussi longtemps que vous le désirez.
La modularité est pour les simples d’esprit. Vous pouvez garder toute la solution dans votre tête, alors pourquoi la déverser dans de multiples classes et méthodes ?
La complexité est belle et la complexité qui n’est pas nécessaire l’est encore plus. C’est tellement mieux d’utiliser les dernières fonctionnalités du langage qui vous permettent d’écrire deux lignes obscures de code au lieu d’en écrire cinq avec des effets évidents. Si jamais quelqu’un venait à vous interroger sur votre choix, rétorquez que c’est plus efficace ou que c’est ridicule de ne pas connaître les fonctionnalités ésotériques du langage dont vous vous êtes servies.
Ne pas partager les informations :
N’expliquez jamais pourquoi votre code fait quelque chose. En fait, évitez les collègues ou au moins évitez de parler des projets sur lesquels vous travaillez ; vos collègues pourraient avoir des suggestions à vous faire, et les suggestions sont tellement ennuyeuses. En plus, vous pourrez accidentellement en dire tellement sur ce que vous faites que vos collègues pourraient le comprendre. Rien de tout ceci n’est souhaitable.
Ne faites pas de programmation par paires, jamais, et évitez les codes review. Tout ça va juste contribuer à perdre votre temps en questions auxquelles vous avez déjà répondu dans le code. Si vous êtes acculés, contentez-vous de décrire ce que le code fait.
S’il est impératif que vous interagissiez avec quelqu’un d’autre, ne le faites que via des courriels et prenez la peine d’espacer vos réponses d’un ou deux jours.
Contournez ou transgressez les soi-disant « politiques » ou « normes » qui pourraient interférer avec vos plans infâmes. De toutes les façons, toutes les raisons qu’ils ont évoquées comme « l’amélioration de la qualité » ou « un gain de temps » sont des mensonges. D’autre part, s’il vous arrive également d’être en charge d’autres développeurs, vous pourrez émettre des politiques, directives et modifications de processus aussi souvent que vous le souhaitez sans jamais expliquer pourquoi.
S’il y a de nouveaux développeurs dans l’équipe, spécialement de nouveaux diplômés, laissez-les sans orientation, ne les soutenez pas. Assurez-vous de tourner en ridicule leurs questions ou alors ignorez-les tous en continuant de faire pression sur eux pour qu’ils terminent les projets sur lesquels ils travaillent.
DevOps ? Ah ça non !
Les pratiques et les praticiens DevOps doivent être évités. Mettez tout manuellement en place, selon votre convenance et aussi souvent que vous le souhaiterez. Méfiez-vous des systèmes de contrôles de code source.
Vive la mauvaise documentation :
Si vous êtes contraint de rédiger une documentation externe, rédigez-la afin que vous seul soyez capable de la comprendre. Ne définissez jamais les acronymes et laissez de côté quelques étapes critiques, après tout vous avez dû travailler dur pour parvenir à les implémenter, alors pourquoi pas les autres ?
Ne cherchez rien :
C’est un signe de faiblesse. Découvrez tout de vous-même en vous basant sur vos principes. Les bibliothèques des autres sont suspectes, alors écrivez vos propres frameworks.
Si vous appliquez religieusement ces préceptes, vos programmes deviendront comme les zombies de The Walking Dead, toujours en décomposition, mais jamais tout à fait mort. Vos efforts vont hanter le code base longtemps après votre départ.
Source : TechBeacon
Et vous ?
Que pensez-vous de ces préceptes ? Pouvez-vous en proposer d'autres pour écrire un code qui vous survivra ?
Voir aussi :
[Tutoriel] L'art de programmer salement Forum Humour 
Envoyé par eldran64
