Programmer, oui ; mais programmer propre !

Le code doit être lisible

La première chose à laquelle penser pour livrer un code propre est sa lisibilité. En effet, il vous est sûrement déjà arrivé d’atterrir sur un nouveau projet dans lequel vous ne compreniez pas l’intention du développeur précédent. Eh bien justement, c’est l’intention qui compte. On doit pouvoir lire votre programme comme un roman qui raconterait une histoire. Il doit avoir un début, une vie, et une fin. Pour cela, l’élément principal à respecter, sera le naming de vos classes, propriétés de classe, méthodes, jusqu’aux arguments de vos fonctions !

 

Parlons de nos fonctions

L’un des principes que nous aborderons ensuite nous donne l’instruction suivante : « une fonction ne doit exécuter qu’une seule action, et le faire bien. » Qu’est-ce que cela signifie ? Eh bien, tout simplement qu’il faut être capable de fragmenter les actions au sein de son système.

Attention, pensez bien que la gestion des erreurs est une responsabilité aussi ! Pour y parvenir, plusieurs code smells devraient vous mettre la puce à l’oreille :

• Le nom de la fonction contient un « ET » : il apparait évident qu’elle n’exécute pas qu’une seule action.
• La fonction reçoit bien trop d’arguments : il est d’ailleurs conseillé de n’en compter que trois au maximum.
• Le corps de la fonction est trop long.

 

Des règles de design simple

Et s’il existait des règles simples, faciles à mettre en place, et qui nous garantiraient un niveau minimal satisfaisant de la qualité de notre code ? Elles existent ! Théorisées par Kent Beck, elles sont au nombre de quatre, et s’articulent de la sorte :

1. Votre code passe tous les tests (la réflexion « s’il n’y a pas de tests, alors ils n’échouent pas » n’a pas sa place ici, bande de petits malins)
2. Révèle vos intentions (tiens-tiens, ça me dit quelque chose, pas vous ?)
3. Pas de duplication (le code n’est présent qu’à un seul et même endroit)
4. Le moins d’éléments possibles (ne rien ajouter qui soit superflu)

Voyez qu’ici, j’utilise un listing ordonné. En effet, ces règles sont priorisées, de « 1 » la plus importante à « 4 » la plus anodine. Nous verrons que ces règles seront souvent mises en avant par d’autres principes du développement plus loin dans l’article.

 

Le boy-scout

Vous connaissez certainement les camps de scout, dans lesquels les enfants ou adolescents apprennent divers enseignements au milieu de la nature. Saviez-vous que les scouts suivent une règle ? Ils repartent toujours de leur campement en laissant l’endroit plus propre qu’il ne l’était à leur arrivée.

Soyez un boy-scout !

Cette philosophie appliquée au code revient à apporter de petites modifications au code que vous parcourez, au fur et à mesure que vous le découvrez. Ces modifications sont bien entendu dans le sens d’améliorer la propreté et la qualité du code. Ne tombez pas dans l’excès inverse non plus, ne reprenez pas entièrement le programme !

 

Les principes S.O.L.I.D

Pour un code pérenne et par conséquent dont la qualité est cruciale, il se doit d’être solide. Imaginez- vous construire votre maison, au bout de cinq années de dur labeur, elle est terminée et toute jolie. L’hiver arrive, et avec le vent et la pluie… elle s’écroule. Malgré toute votre bonne volonté, vous aviez oublié que le but était qu’elle dure. Il en va de même pour le code !

S.R.P : Single Responsability Principle – Tout possède une seule et unique responsabilité — vous voyez, nous y revenons. Cela signifie que depuis votre architecture jusqu’à vos méthodes tout se doit de n’effectuer qu’une seule action, mais bien. Ce principe vous mènera parfois à enfreindre la quatrième règle du simple design. Mais cette infraction n’est pas la plus grave, car la règle en question occupe la place la plus basse dans la liste. Attention tout de même, si la quatrième règle peut s’enfreindre ici, cela se produit pour une raison valable et acceptable, sinon respectez-la scrupuleusement !

O.C.P : Open-Closed Principle – Votre système doit être ouvert à l’extension, mais fermé à la modification. Ce principe se révèle souvent le moins bien compris, mais le plus pratiqué… sans le savoir. Vos composants doivent être capables, en tout état de fait, d’absorber une modification sans douleur. Ce qui signifie que vous avez besoin d’abstraction pour définir vos classes.

L.S.P : Liskov Substitution Principle – Tout type pouvant être étendu doit pouvoir être remplacé par un de ses sous-types sans affecter le programme. Cela revient à juger de la hiérarchie de son héritage correctement.

Code smell : la vérification de type dans votre fonction.

Exemple : if (monChat instanceOf Felin) then …

I.S.P : Interface Segregation Principle – Ne pas dépendre de méthodes que vous n’utilisez pas. Simple, rapide, efficace : créez de petites interfaces, référez-vous à S.R.P.

Code smell : Interface avec un trop grand nombre de fonctions, des méthodes implémentées d’une interface qui sont vides.

D.I.P : Dependency Inversion Principle – Les classes ne doivent dépendre que d’abstractions, pas d’implémentation. Pour ainsi dire, ne passez plus le type concret de votre classe, mais donnez son abstraction. Cela assure à la manipulation que l’objet possède bien toutes les fonctions nécessaires.

Plus simplement, en règle générale utilisez l’interface qu’implémente votre objet.

 

A.C.I.D

Parlons également de nos actions, celles menées sur le système. Pour que le système soit fiable, alors nous devons nous assurer que toute action effectuée sur le système ne remette pas en cause son intégrité.

A : Atomicité – Soit une action est complètement réalisée, soit elle ne l’est pas du tout. Si la moindre erreur survient alors l’action est totalement annulée, le système revient à son état initial avant l’action.

C : Cohérence – Aucune action ne doit corrompre le système. Dit autrement, aucune action menée sur le système ne doit mettre en péril l’intégrité des données.

I : Isolation – Aucune transaction ne doit dépendre d’une autre. On peut utiliser les transactions optimistes ou pessimistes : dans le cas de l’optimiste, le système considère que tout se passe bien et ne s’occupe que peu des données ; dans le cas pessimiste, le système verrouille la donnée jusqu’à la fin de l’action.

D : Durabilité – S’assurer que les données sont enregistrées si l’action a réussi. On ne renvoie pas de code de retour OK si l’on n’est pas entièrement certain que l’action a bel et bien porté ses fruits.
Par exemple, nous renverrons l’ID de l’entité que nous venons de créer seulement après l’instruction de sauvegarde, si elle s’est bien passée.

 

Vous voilà armés, au moins de bases solides, pour assurer la qualité de vos livrables. J’aurais aimé vous transmettre encore plus de conseils, mais l’article aurait atteint la taille d’un dictionnaire !

En résumé, dans l’état d’esprit de coder proprement et qualitativement, le développeur doit lui-même s’armer de qualités : la plus importante, être bienveillant. Je pense que vous n’apprécieriez pas si quelqu’un sabotait votre travail sous couvert de vous donner une leçon sur la qualité de votre code. Dans ce sens, ne faites pas aux autres ce que vous ne voudriez pas que l’on vous fasse ! De même, soyez humbles, il faut savoir accepter les critiques tant qu’elles se montrent constructives. Les Merge / Pull-Request sont dédiées à cela, elles représentent l’espace privilégié pour discuter de ce qui peut être amélioré.

Finalement, je vous dirais d’être dogmatique (et là, mes collègues me tomberont dessus quand ils me liront) sur les concepts que je vous ai énoncés. Imposez-vous dès maintenant une discipline stricte jusqu’à ce que viennent des automatismes. Vous serez capables de prendre des décisions pragmatiques avec la pratique.

 

Sources :

• Clean Code, Robert C. Martin, Pearson
• Extreme Programming Explained, Kent Beck, Addison-Wesley Professional