Comment écrire le code qui vivra éternellement en entreprise
Et qui sera regardé avec crainte et respect ?

Le , par Stéphane le calme, Chroniqueur Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de transgohan transgohan - Expert éminent https://www.developpez.com
le 18/09/2015 à 15:48
On est plus dans les années 80.
Avatar de dfiad77pro dfiad77pro - Membre éprouvé https://www.developpez.com
le 18/09/2015 à 15:55
ça va ça ??

Code C# : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public static TypeQuery TrouverUnTrucV26321(){ 
var t = "SE_L_E_CT  *****  FR_O_M_  MAT_AB_LE WHERE DDE=33 AND CCCOL='A'  "; 
  
t= t.Replace ("_",""); 
t= t.Replace ("*****","*"); 
  
var cc = (ICustomDataProvider)Environnement.GetInstance().GetSqlHelper().GetOracleSqlQueryHelper().ExecuteOracleQueryWithALotOfResult(t); 
  
//On fait une pause 
For (long iii=0 ;iii< 99999999999999999 ;iii++){ 
Console.WriteLine("On fait chauffer la machine pour faire le café"); 
} 
return cc; 
}
Avatar de eldran64 eldran64 - Membre averti https://www.developpez.com
le 18/09/2015 à 16:06
C'est une news pour apprendre à se faire virer?
Avatar de dfiad77pro dfiad77pro - Membre éprouvé https://www.developpez.com
le 18/09/2015 à 16:07
Citation Envoyé par eldran64  Voir le message
C'est une news pour apprendre à se faire virer?

le soucis est justement que dans beaucoup de structure , tu te fais pas virer pour ça
Avatar de vampirella vampirella - Membre éclairé https://www.developpez.com
le 18/09/2015 à 16:18
C'est une news pour apprendre à se faire virer?

Il suffit d'avoir suffisamment de bons contacts / des collègues débordés ou qui s'en foutent / pas doués techniquement.
La rentabilité est un facteur aussi. "Tant que ça marche, on n'y touche pas" : qui n'a jamais entendu ce paradigme ? Cette expression n'est pas dénué de bon sens capitaliste à court-terme. Pourquoi améliorer quelque chose que le client ne demande pas et qu'il ne remarquera jamais ?
Et puis : pas de bug, pas de ticket. Pas de ticket, pas d'argent. Et pas d'argent ... pas d'argent.

Ceci dit, le dernier paragraphe du blog n'a pas été traduit et c'est bien dommage
On dit souvent qu'il faut écrire le code comme si la personne reprenant le projet sera un psychopathe violent connaissant votre adresse. Mais cela est hautement improbable : elle sera bien trop occupée à batailler votre horde de zombies.

Rappelez-vous juste de ne jamais mettre votre nom.

Avatar de eulbobo eulbobo - Membre chevronné https://www.developpez.com
le 18/09/2015 à 16:20
Avatar de 10_GOTO_10 10_GOTO_10 - Membre éprouvé https://www.developpez.com
le 18/09/2015 à 16:27
Citation Envoyé par dfiad77pro  Voir le message
le soucis est justement que dans beaucoup de structure , tu te fais pas virer pour ça

Bien au contraire : « Les gens les moins compétents sont systématiquement affectés aux postes où ils risquent de causer le moins de dégâts : ceux de managers. »

En appliquant scrupuleusement ça, tu as une chance de devenir chef de projet. De toutes façons tu deviens indispensable, donc tu ne sera jamais viré.
Avatar de Sodium Sodium - Membre éprouvé https://www.developpez.com
le 18/09/2015 à 16:45
Un conseil important a été oublié : répétez-vous.

Je reprends pour le moment pas mal de code d'un ancien collègue. Sur un site, pour un formulaire d'envoi de candidature soit spontanée, soit en réponse à une annonce (la seule différence étant que l'annonce est référencée dans le mail généré dans le deuxième cas) il me fait deux templates de formulaires et deux traitements complets. Un bonheur pour la maintenance.
Avatar de Pierre Louis Chevalier Pierre Louis Chevalier - Expert éminent https://www.developpez.com
le 18/09/2015 à 17:25
Très beau troll pour le week end, bravo Stéphane, la tu t'es surpassé

Le pire c'est que ce qui est décrit est très courant
Avatar de - https://www.developpez.com
le 18/09/2015 à 17:32
Citation Envoyé par transgohan  Voir le message
On est plus dans les années 80.



Code : Sélectionner tout
1
2
3
4
5
void main() 
{ 
  string thecode = "{themachinehexacode}"; 
  Run(thecode); 
}
Contacter le responsable de la rubrique Accueil