Avec le temps, je me suis forgé une opinion sur le développement logiciel. Cette opinion s’est basée sur l’expérience que j’ai obtenue en développant et maintenant différentes applications et services.
Il y a certains livres qui ont guidé ces réflexions. Il y en a trois que je retiens particulièrement.
Ces trois livres ont contribué à mettre en place la fondation des principes qui m’accompagnent lorsque j’écris du code. Certes, je ne suis pas chaque principe à la lettre comme s’il s’agit de la bible. Je m’assure de garder en tête que ce que je fais soit en ordre.
En bout de compte, ce qu’il faut c’est de se forger une opinion sur ce qu’est du code de qualité. Avoir une opinion sur la chose signifie qu’au moins je me soucie de ce que je fais. Dans le cas où je suis dans l’erreur, il y aura quelqu’un pour me le montrer.
Mes critères pour du code de qualité
Il y a toujours quelques règles que je garde en tête lorsqu’il est temps de développer. Elles sont des principes que j’essaie d’appliquer dans la majorité des cas.
Résumer ma philosophie sur le sujet en quelques mots serait : Démontrez que vous vous souciez de votre code. Le reste va bien aller.
Diviser les fonctions très complexes
Lorsqu’il est temps de rédiger une fonctionnalité, je tente toujours de diviser la séquence du flux d’actions en plusieurs méthodes de petite taille. Cette approche me procure les avantages suivants :
- Le fonctionnement de la classe ou de l’action est clair et facile à lire.
- Les responsabilités de chacune des fonctions sont clairement définies
Du code qui s’auto-documente
L’une des choses que je déteste le plus est d’avoir à lire un bloc monstrueux de commentaires dans le code m’expliquant le fonctionnement du module que je m’apprête à modifier.
En supplément avec la règle précédente, je m’applique à respecter une discipline dans les mêmes lignes que celles-ci :
- Préférer des noms de variable sans acronyme avec un nom plus long.
- Retourner une valeur aussitôt que possible.
- Éviter les conditions booléennes négatives.
- Éviter le plus possible les valeurs magiques. Les mettre dans des variables.
- Constance dans l’indentation et la nomenclature
Il peut y en avoir des centaines d’autres selon votre volonté. Ces règles se résument à dire : Clarifiez vos intentions.
Règle du « Boyscout »
Uncle Bob l’a dit : Le code tend à se dégrader et pourrir avec le temps.
La règle du boyscout veut que, lorsqu’on quitte un campement, on le laisse dans un meilleur état que lorsqu’on s’y est établi. La même chose doit d’appliquer au code.
Dans tous les cas, laissez votre code dans un meilleur état que lorsque vous l’avez trouvé. Renommez des variables, simplifiez des conditions ou quelque chose d’autre. Agissez!
Une extension à ce principe est la théorie de la vitre brisée. Un module va tendre au délabrement suite à de petites détériorations à travers le temps.
Développer pour le mainteneur
Cette ligne directrice vient directement de Jeff Atwood. Elle va comme suit:
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
Si la peur ne vous motive pas à mieux développer, qu’est-ce qui va vous motiver à le faire?
Good enough software
La traduction libre inspirée par moi-même serait : Beau, bon et pas compliqué. L’idée est qu’il faut savoir quand s’arrêter. Ne pas tenter de trop penser à une solution complexe.
Parfois, aller droit au but sans utiliser d’abstractions n’est pas une mauvaise idée. Il s’agit seulement d’utiliser son jugement.
Maintenabilité vs Facilité du développement
En supplément avec le point précédent, j’ai vu, trop souvent, des solutions bien fonctionnelles mais impossibles à maintenir. Les cas varient d’une fois à l’autre.
Cela peut être une utilisation inappropriée d’abstractions ou simplement la création d’un chaos intentionnel par manque de soucis. Dans tous les cas, le problème reste le même : un calvaire pour celui qui doit reprendre le code.
Programmation défensive
La programmation défensive est à peu près le même concept que la conduite défensive. Il faut se protéger et se défendre des éléments perturbateurs qui pourraient nous faire prendre le fossé.
Le concept est parfois ou même souvent ignoré soit par paresse ou même simplement par excès de confiance. Il n’est pourtant pas compliqué de :
- Valider que les paramètres d’une fonction ne sont pas null ou contiennent l’information que l’on désire.
- Valider que la collection ou le tableau à parcourir contient des éléments.
- Prévoir un cas l’exécution dans le cas où le service externe ne répond pas.
- S’assurer que le répertoire visé existe.
Ce ne sont que des exemples parmi tant d’autre.
Cuire une grenouille
La légende veut que celui qui tente de faire cuire une grenouille vivante ait tenté, initialement, en la jetant dans l’eau bouillante. Le pauvre homme a sauté un repas car la grenouille est sortie de l’eau dans le temps de le dire.
L’homme a tenté, par la suite, de cuire sa grenouille en faisant bouillir graduellement l’eau dans laquelle celle-ci baignait. Ce fût un succès.
La morale de l’histoire est qu’une situation qui va faire que vous allez vous retrouver en danger va prendre quelques temps à se bâtir. La grenouille a su qu’elle était fichue trop tard. Lorsqu’elle était cuite.
Résumé : Ne programmez pas avec une grenouille.
French Coding 
Cette grenouille là ….
ahahah. Excellente finale !