Sur un ton satirique, le développeur Roedy Green s’est proposé de transmettre son savoir dans l’écriture d’un code qui donnerait des sueurs froides au développeur qui viendra faire la maintenance. Son illustration est axée sur la programmation Java.« Je vous transmets les conseils des maîtres sur la façon d'écrire du code si difficile à gérer, qu’il faudra des années aux personnes qui vont en assurer la maintenance pour effectuer les changements les plus simples », promet-il.
Et de poursuivre en disant « De plus, si vous respectez toutes ces règles religieusement, vous vous garantissez même une vie d’emploi, car personne, sauf vous, ne pourra espérer maintenir le code. D’ailleurs, si vous suiviez toutes ces règles religieusement, vous même ne seriez pas en mesure de maintenir le code ! »
Bien entendu, cela doit rester un art. Votre code ne doit pas sembler impossible à maintenir de prime abord, sinon il risque simplement d’être réécrit.
Principes généraux
Pour mystifier le développeur qui va effectuer la maintenance, vous devez comprendre comment il pense. Face à lui se tient votre programme géant. Il n'a pas le temps de le lire en entier, encore moins de le comprendre. Il veut rapidement trouver l’endroit où effectuer une modification, la faire et s’en aller tout en espérant ne pas avoir d’effets secondaires inattendus.
Il est donc question de l’empêcher d’avoir une vision d’ensemble. Vous voulez donc qu’il soit plus difficile pour lui de trouver le code qu'il recherche. Mais plus important encore, il faut que ce soit tellement difficile qu’il ne puisse pas ignorer quoique ce soit.
Pour réussir cet exercice, il donne quelques conseils : « Les développeurs sont plongés dans la complaisance par les conventions. Mais de temps en temps, en violant subtilement la convention, vous les forcez à lire chaque ligne de votre code avec une loupe ».
Vous pourriez avoir l’idée que toutes les fonctionnalités de langage rendent le code impossible à maintenir, ce qui n’est pas le cas si elles sont mal utilisées.
Les appellations
L'art de nommer des variables et des méthodes est une grande partie de la compétence « rédaction d’un code non maintenable ». Elles ne comptent pas du tout pour le compilateur. Cela vous donne une grande latitude pour les utiliser afin de dérouter le développeur qui va effectuer la maintenance.
Les noms de variable à lettres uniques
Si vous appelez vos variables a, b, c, alors il sera impossible de rechercher des instances de celles-ci en utilisant un simple éditeur de texte. De plus, personne ne pourra deviner à quoi elles servent.
La mauvaise orthographe créative
Si vous devez utiliser des noms de variables et de fonctions descriptives, orthographiez-les mal. En mal orthographiant certains noms de fonctions et de variables et en les orthographiant correctement dans d’autres (tels que SetPintleOpening et SetPintalClosing), nous annulons efficacement l’utilisation des techniques de recherche grep ou IDE. Cela fonctionne étonnamment bien.
Soyez abstrait
En nommant des fonctions et des variables, faites un usage intensif de mots abstraits tels que tout, données, descripteur, élément, tâche, routine, exécution et les chiffres, par ex. routineX48, PerformDataFunction, DoIt, HandleStuff et do_args_method.
Acronymes
Utilisez des acronymes pour garder le code laconique. Les vrais hommes ne définissent jamais les acronymes; ils les comprennent génétiquement.
Camouflage
Une grande partie de l'habileté à écrire un code non maintenable est l'art de se camoufler, de cacher des choses ou de faire en sorte que les choses semblent être ce qu'elles ne sont pas. Beaucoup dépendent du fait que le compilateur est plus capable de faire des distinctions que l'œil humain ou l'éditeur de texte. Voici quelques-unes des meilleures techniques de camouflage.
Code qui se déguise en commentaires et vice versa
Inclure des sections de code qui sont commentées mais qui à première vue ne semblent pas l’être
| Code Java : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | for (j=0; j<array_len; j+=8) { total += array[j+0]; total += array[j+1]; total += array[j+2]; /* Main body of total += array[j+3]; * loop is unrolled total += array[j+4]; * for greater speed. total += array[j+5]; */ total += array[j+6]; total += array[j+7]; } |
Sans la coloration, remarqueriez-vous que trois lignes de code sont commentées ?
Masquer les définitions de macro
Cachez-les dans les commentaires inutiles. Le développeur va s'ennuyer et ne va abandonner sa lecture des commentaires et il ne découvrira donc jamais la macro. Assurez-vous que la macro remplace ce qui ressemble à une assignation parfaitement légitime avec une opération bizarre, un exemple simple:
| Code : | Sélectionner tout |
#define a=b a=0-b
La clé pour écrire du code maintenable est de spécifier chaque fait de l'application dans un seul endroit. Il vous suffit donc d’effectuer le changement à un seul endroit et vous avez la garantie que le programme entier fonctionnera toujours. Par conséquent, pour écrire un code qui ne sera pas maintenable, il faut spécifier un fait à plusieurs reprises, dans autant d'endroits que possible, de toutes les manières possibles.
Heureusement, des langages tels que Java font tout leur possible pour que l’écriture de ce type de code soit plus facile. Par exemple, il est presque impossible de modifier le type d'une variable largement utilisée, car toutes les fonctions de conversion ainsi que les Casts ne vont plus fonctionner et les types de variables temporaires associés ne seront plus appropriés.
Java Casts
Le système de casting de Java est un cadeau des dieux. Vous pouvez l'utiliser sans culpabilité puisque le langage l'exige. Chaque fois que vous récupérez un objet d'une collection, vous devez le replacer dans son type d'origine. Ainsi, le type de la variable peut être spécifié dans des dizaines de lieux. Si le type change ultérieurement, tous les Casts doivent être modifiés pour correspondre. Le compilateur peut ou peut ne pas détecter si le développeur qui effectue la maintenance ne parvient pas à les modifier tous (ou en modifie un de trop).
Exploiter la redondance de Java
Java insiste sur le fait que vous spécifiez deux fois le type de chaque variable. Les développeurs Java sont tellement habitués à cette redondance qu'ils ne vont pas remarquer si les deux types sont légèrement différents, comme dans cet exemple:
| Code : | Sélectionner tout |
Bubblegum b = new Bubblegom();
| Code : | Sélectionner tout |
swimmer = swimner + 1;
Et vous ?
Êtes-vous déjà tombé sur du code dont la maintenance était difficile ? L'entreprise a-t-elle fait appel à la personne/l'équipe qui l'a conçue, avez-vous du réécrire le code ou vous êtes vous contenter de publier des fix pour corriger les problèmes ? Avez-vous déjà volontairement écrit du code pour rendre difficile la maintenance par un autre développeur ? Quelles astuces pouvez-vous rajouter à cette liste ?Voir aussi :
Trolldi : qu'avez-vous pu faire dans le passé pour détruire involontairement votre carrière en informatique ? Quelques pistes à explorer Trolldi : comment prendre sept ans pour livrer une bêta d'un jeu vidéo ? L'art d'allonger les délais en développement logiciel Trolldi : les meilleurs employés ne sont pas ceux qui sont les plus agréables, selon un psychologue qui explique sa réflexion Trolldi : Good Luck With That, enfin une licence pour le code spaghetti ? Les devs peuvent modifier votre code tant qu'ils ne vous mentionnent pas Trolldi : quelles sont les pires excuses que les entreprises pourraient avancer, pour refuser le passage à l'IPv6 ? 
Envoyé par LebonJaime
