IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

44PARTAGES

17  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de CodeurPlusPlus
En attente de confirmation mail https://www.developpez.com
Le 18/09/2015 à 22:11
Le vrai problème est que chacun(e) d'entre nous est persuadé(e) qu'il/elle écrit du code lisible, maintenable, réutilisable, factorisé et bien documenté... et que ce sont les autres qui font le contraire. Le nul, c'est toujours l'autre.
9  0 
Avatar de dfiad77pro
Membre expérimenté 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
8  0 
Avatar de 10_GOTO_10
Membre expérimenté 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é.
7  0 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 19/09/2015 à 11:54
Pas tout à fait d'accord avec le "ne pas tester". Il faut tout de même s'assurer que le bout de code en question marche. Si ça bogue de partout les mainteneurs auront moins de scrupules à faire sauter le bout de code problématique. Si ces bouts de codes s'installent sur le long terme dans les projets, c'est aussi parce que ça marche et que les mainteneurs ne vont pas aller toucher à la boîte noire de peur d'aller créer des bugs.
6  0 
Avatar de Pierre Louis Chevalier
Expert éminent sénior 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
5  0 
Avatar de 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.
3  0 
Avatar de eldran64
Membre extrêmement actif https://www.developpez.com
Le 18/09/2015 à 16:06
C'est une news pour apprendre à se faire virer?
2  0 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 18/09/2015 à 20:40
Tout ça ressemble étrangement aux pratiques de mes prédécesseurs sur le produit que je maintiens. Sauf que pour eux, j'ai la certitude que ça a été fait involontairement par manque de connaissances et compétences.
2  0 
Avatar de ustensile
Membre régulier https://www.developpez.com
Le 21/09/2015 à 10:37
J'adore ce genre de discussion. Je sais que c'est pas bien mais je pense qu'il faut encourager les mauvaises pratiques:
-on aurait pas de boulot
-rien à raconter à ses collègues sur les trucs immondes qu'on a vu
-personne dont on pourrait dire du mal (stagiaire, manager, collègue ou autre victime)
-pas de discussions sur l'art du développement
-pas d'auto-satisfaction quand on dit "quel abruti a pondu ce code?" et qu'on se rend compte que c'est nous(on ne met pas de commentaires,les commentaires c'est mal)
-plus d'aura mystérieuse du mec qui comprend mais pas nous
-plus de prises de têtes donc plus de réflexion donc baisse de niveau donc on devient bête et paresseux
2  0 
Avatar de eulbobo
Membre chevronné https://www.developpez.com
Le 22/09/2015 à 17:06
Citation Envoyé par Saverok Voir le message

Non seulement la voiture neuve coûte cher mais en plus, y a tellement d’électronique dedans que tu ne peux plus faire l'entretient toi-même et en plus, cette même électronique est source de panne qui coûte ultra cher à réparer (avec une durée de garantie ultra courte).
La décote est rapide.
Le moteur qui consomme très peu est super fragile et nécessite plein de filtres qu'il faut changer régulièrement et bien évidemment, coûtent un bras à chaque fois.
Bref, quand tu poses le tout sur une feuille de compta, tu remarques que ta lubie de nouvelle voiture sera amortie dans 10 ans par rapport à ta vieille bouse qui roule tjrs.
Et en plus, elle te ment en disant qu'elle ne pollue pas alors que si ça se trouve elle pollue toujours autant que ta vieille bagnole !
2  0