Suite à une discussion sur IRC, j'ai pensé qu'écrire un condensé de "bonnes pratiques" à adopter en informatique, surtout en développement logiciel serait une excellente idée.
Toute ressemblance avec des faits existants ou ayant existé ne serait pas vraiment fortuite. Dans le doute, consulter The Daily WTF, http://thedailywtf.com.
Petit guide des "bonnes pratiques" à adopter en développement logiciel
aussi appelé "How to write shitty code".
Mots clés : génie logiciel, développement, analyste programmeur, chef de projet, maitre d'œuvre, tout ça…
Attention : ces règles sont écrites "en vrac" et ne sont pas ordonnées.
Règle numéro un : ne pas documenter son code.
Règle numéro deux : ne pas tester son code.
Règle numéro trois : faire un commit sur master toutes les demi-heures (dans le cas où l'équipe utilise un gestionnaire de version, ce qui est une mauvaise pratique. Le bon codeur connaît son code et n'a pas besoin de le versionner, car il ne fait jamais d'erreurs).
Règle numéro quatre : écrire dans le message de commit : "à remplir ; lol". Le bon codeur lit le diff, c'est plus rapide que d'essayer de comprendre la description des modifications.
Règle numéro cinq : s'arranger pour faire péter la compilation, de préférence avant une livraison. Pour reprendre un slogan célèbre : "travaillez plus pour gagner plus". Cette règle permet effectivement de travailler plus.
Règle numéro six : écrire des requêtes SQL illisibles, de préférence utilisant énormément les vues, si possible, utilisation des curseurs et de procédures stockées exécutant du code sql dynamique. Les CPU ont tendance à trop dormir et les faire travailler n'est pas superflu. Effet de bord intéressant : cela permet de faire des économies de chauffage en hiver.
Règle numéro sept : laisser plein de code commenté, ça peut toujours servir plus tard et cela évite de réinventer la roue. De toute façon, les commentaires sont ignorés à la compilation. À noter tout de même que Flex Builder a tout de même tendance à laisser quand même les commentaires lors de la génération des swf, donc raison de plus de ne pas commenter. Cf règle numéro un.
Règle numéro huit : si utilisation d'un tracker (trac, redmine, …) ne jamais le remplir car cela remplirait la base de données. La BDD devrait plutôt être consacrée à l'application à livrer et non à des futilités.
Règle numéro neuf : ne pas indenter son code, ou alors, mélanger différentes longueur, confondre espace et tabulation. Cela permet d'aller plus vite pour coder, "Le temps, c'est de l'argent". De plus, seuls les langages "mal conçus" se basent sur les espaces et tabulations.
Règle numéro dix : ne pas aligner les accolades. On a tendance à les confondre avec les parenthèses après avoir passé huit heures à coder.
Règle numéro onze : utiliser des noms de variables les plus courts possible, utiliser au maximum une ou deux lettres. Si nécessaire, griffoner sur un post-it™ à quoi correspondent les variables b1, c2 et aa. Cela permet d'économiser des caractères dans le code et de taper moins de code (donc, le code va plus vite, cf. un célèbre outil de développement logiciel).
Règle numéro douze : parfois, il peut être utile que le code s'auto-documente (la simple lecture permet de comprendre ce qu'il fait). Utiliser par exemple, lors de l'évaluation d'un booléen
if(test == true)
au lieu de
if(test)
Faire de même pour false.
Règle numéro treize : ne pas utiliser les "inline if", préférer l'écriture d'une fonction à la place. Par exemple, n'écrivez pas
(test)?"ok":"erreur"
Écrivez à la place :
{if(test == true) {return "ok";} if(test == false) {return "erreur";}}
Règle numéro quatorze : concernant les rapports de bugs, écrire en sujet : "ça ne marche pas", dans le corps du texte : "regarder les captures d'écran que j'ai attaché", et attacher un fichier MS Word[1] ou MS Powerpoint[1].
Règle numéro quinze : concernant les captures d'écran : les prendre au format gif (de préférence) ou jpeg (compression 30 ou 40%), les insérer dans un fichier .doc ou .ppt, et envoyer par email. Au pire, les attacher sur un ticket de rapport de bug (mauvaise pratique, cf. règle numéro huit).
Règle numéro seize : lors de l'échange de documents, privilégier les formats word 97 ou word 2013.
Règle numéro dix-sept : s'il faut exporter dans un format conservant la mise en page, privilégier le format .xps.
Règle numéro dix-huit : si des commentaires doivent être écrits, privilégier le Klingon, le Quenya ou le Sindarin. Cela permettra à ces langues de survivre et de ne pas tomber dans l'oubli. Pour les plus lettrés, il est possible d'utiliser le latin.
Règle numéro dix-neuf : afin de ne pas réinventer la roue, il faut recopier bêtement les exemples trouvable sur le net pour répondre à des problématiques.
Règle numéro vingt : lors de développement web, privilégier le développement pour IE6, car, qui peut le plus, peut le moins. Accessoirement, IE est installé sur la majeure partie des ordinateurs de la planète.
Règle numéro vingt-et-un : (toujours dans le webdev) ne pas tester les requêtes sql qui proviennent du navigateur. Tout prétraitement sur la requête ralentira son exécution. Il ne faut surtout pas échapper/doubler les quotes.
Règle numéro vingt-deux : les injections SQL sont toujours sur les autres sites, et donc, "cela n'arrive qu'aux autres".
Règle numéro vingt-trois : autoriser les scripts php à écrire dans un répertoire accessible depuis un navigateur web. Pas d'inquiétude, les écritures de fichiers dans ces reps n'arrivent que dans wordpress.
Règle numéro vingt-quatre : si le choix est possible entre http et https, privilégier le http. On a bien vu l'an dernier les problèmes posés dans certains pays sur le https (facebook, gmail, etc).
Règle numéro vingt-cinq : lors du déploiement d'un site web, privilégier les images au format .bmp, afin de garder la meilleure qualité d'image. La taille ne posera pas de problèmes, grâce aux connexion haut-débit.
Règle numéro vingt-six : si vous utilisez un hébergeur gratuit, profitez-en pour ajouter le maximum de publicités.
Règle numéro vingt-sept : usez et abusez du js, faites en sorte que votre site soit illisible sans le js actif.
Règle numéro vingt-huit : vous ne voulez pas apprendre le html/css/js ? L'informatique vous dépasse ? Vous maitrisez Paint ? Alors, créez votre site avec PowerPoint [2].
Règle numéro vingt-neuf : pour de la programmation de "clients lourds", privilégier le java ou le C# / .net. Cela simplifie le développement, et respecte la règle du : "programmez une fois, déployez partout".
Règle numéro trente : si ce que vous codez vous semble bizarre ou semble mener dans une impasse, ne demandez pas au client ou au chef de projet, ils savent parfaitement ce qu'il faut faire et ça a été défini correctement, donc continuez de coder sans soucis.
Règle numéro trente-et-une : toutes les règles précédentes sont à caractère humoristique et ne sont, bien entendu, à ne pas appliquer.
Remerciements à Bacardi55 pour son aide à la préparation de cet article.
Si vous avez d'autres idées de règles, ne pas hésiter à les ajouter en commentaires :D
[1] Logiciels de Microsoft donnés à titre d'exemple. Noms et marques déposées et reconnues par Microsoft partout dans le monde ou quasiment. /mention légale.
[2] J'avoue, ça m'arrive de faire des maquettes (mockup) avec Keynote ou Powerpoint.