Il y a quelque temps j’ai intégré une nouvelle entreprise dans le cadre d’une “régie”, habitué aux agences web, c’est la première fois que je sortais de ce domaine.
Quand j’ai découvert le code de cette entreprise, j’ai vite compris que j’étais à la ramasse en terme de qualité de code.
Je connaissais tous les concepts utilisés mais je ne les appliquais pas systématiquement.
Pourquoi ? Par manque de temps, des deadline très rapprochés. (beaucoup d’excuses, oui)
Je privilégiais la quantité à la qualité.
Et ça, c’est un gros défaut que pas mal de développeurs (surtout junior) ont.
Aujourd’hui on va parler de “ Clean Code ” et de comment l’ensemble de ces pratiques peuvent faire de toi un meilleur développeur.
Qu’est-ce-que le “Clean Code”
Son importance
Au delà du titre “putaclick”, mon but est de te prouver l’importance de ces méthodologies et comment elles peuvent réellement faire de toi un meilleur développeur.
Le Clean Code , c’est surtout une liste (non exhaustive) de méthodologie à respecter pour faire du code de qualité.
Un code de qualité donne énormément d’avantages (en plus de pouvoir être fier de ton code) :
- Plus maintenable , une modification dans une base de code ne devrait pas te faire peur.
- Plus modulable/améliorable , n’importe quel développeur doit être en mesure d’ajouter et/ou modifier une fonctionnalité très facilement.
Et faire du code de qualité s’applique bien évidemment à tout les domaines, même dans le web pour les “petits sites”.
Il ne devrait pas y avoir d’excuse pour ne pas suivre ces principes.
En plus d’être bien plus agréable pour tout le monde (oui, personne n’aime développer avec du legacy), tu vas prendre un bien plus grand plaisir à développer.
L’objectif est que tu deviennes fier de ton code.
Le Clean Code c’est tout un état d’esprit, on parle de “Software Craftsmanship” (Artisan Développeur). Un manifeste existe même pour cela : https://manifesto.softwarecraftsmanship.org/.
Pourquoi ?
Si tu n’es toujours pas convaincu de l’importance d’utiliser le Clean Code, il faut revenir à la base : pourquoi le développement orienté objet à été inventé ?
Est-ce que nous n’étions pas bien avec nos fichiers PHP de 1000 lignes avec tout un tas de fonctions posées comme ça sans contexte et des includes dans tout les sens ? (Je prends ici l’exemple du PHP puisque c’est celui que je maîtrise, mais tout cet article s’applique bien évidemment à n’importe quel langage.)
Tu l’auras deviné, la programmation orientée objet a été inventée spécifiquement pour ce problème : l’organisation.
Pouvoir organiser son code en classe a été une petite révolution.
De là sont nées énormément de bonne pratiques , acquis à force d’erreurs.
En effet, avez-vous déjà été confronté à une classe de 500 lignes en soupirant parce que vous savez que ce sera long de trouver ce que vous voulez vraiment ?
Beaucoup de développeur l’ont étés avant vous.
Et les principes que nous allons voir ont été créés pour ne pas répéter les mêmes erreurs.
Pour aller plus loin, certains ont inventés des design pattern ( patrons de conception ) pour tout un tas de cas d’utilisation. Nous n’allons pas parler de cela aujourd’hui mais si tu veux en savoir plus je te conseille l’excellent site refactoring.guru !
Les différents principes
Il existe évidemment bien d’autres principes, je vais parler ici des principaux, de ceux que tout le monde devraient appliquer.
KISS (Keep It Simple, Stupid)
Ce principe préconise la simplicité.
Ne pas ajouter une complexité non-indispensable à une application.
Un code simple est bien plus facile à modifier.
Il semble que la perfection soit atteinte non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à enlever.
DRY ( Don’t Repeat Yourself )
Le titre en dit long : ne pas se répéter.
Si le fonctionnement de cette fonction doit changer, il est plus simple de la modifier à un seul endroit plutôt que de devoir chercher toutes les fonctions implémentant le même code.
Attention par contre avec ce principe, il peut être bon de se répéter parfois.
Lorsque les cas d’utilisations ne sont pas les mêmes, par exemple. Un produit dans un catalogue ou dans un panier utilisateur n’est pas le même, il pourrait être bon de le dupliquer dans ce cas là.
Celui-ci est à prendre avec des pincettes, si tu veux approfondir, je te conseille cet article.
SOLID
Le principe SOLID est le plus important de tous.
Responsabilité unique (Single responsibility principle)
Une classe, une fonction ou une méthode doit avoir une et une seule responsabilité
Ouvert/fermé (Open/closed principle)
Une entité applicative (classe, fonction, module …) doit être fermée à la modification directe mais ouverte à l’extension
Substitution de Liskov (Liskov substitution principle)
Une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme
Ségrégation des interfaces (Interface segregation principle)
Préférer plusieurs interfaces spécifiques pour chaque client plutôt qu’une seule interface générale
Inversion des dépendances (Dependency inversion principle)
Il faut dépendre des abstractions, pas des implémentations
Si tu souhaites plus de détails concernant ce principe je te renvois vers l’excellent article d’alexsoyes
Les bonnes pratiques
Au-delà de ces principes, il existe aussi des “bonnes pratiques”.
Cohérence
Être cohérent , toujours utilisé le même nommage dans toute son application, par exemple.
Si tu utilises l’anglais à un endroit, utilise le partout.
Si tu utilises du CamelCase pour le nommage de tes classes, utilise le partout.
Utiliser des noms de variables explicites. Au bûcher les variables a / b / array / variable, il devrait être possible de comprendre le code rien qu’en le lisant.
Conventions
Suivre les normes de son langage, le PSR-12 en PHP , par exemple.
Tous les langages ont (normalement) leurs normes, leurs “coding style”.
Mais les CMS ou framework en ont aussi, exemple avec Symfony ou encore WordPress.
Tu peux facilement trouver les bonnes pratiques liées à ta situation.
Mettre en pratique
On arrive à la partie la plus compliquée : la mise en pratique.
Il n’y a pas de secret, il faut pratiquer.
Réaliser un projet de 0 et appliquer au maximum tout ce que nous avons vu.
Ou alors ne pas hésiter à refactoriser (Retravailler une application informatique pour l’améliorer en profondeur, sans pour autant lui ajouter de nouvelles fonctions. Merci Wikipedia )
Reprends ton code et reprends un à un tous les principes et demande toi si tu les respectes tous.
Tu peux facilement trouver tout un tas d’exemples dans le framework / CMS de ton choix. Pour ma part cet article m’a beaucoup aidé à appréhender SOLID dans Symfony.
Ce qui serait encore mieux ce serait d’avoir des proches à qui demander conseils, pour savoir si tu respectes au maximum le clean code.
Si tu remarques une erreur, ou si tu souhaites améliorer cet article, n’hésites pas à m’envoyer un message via cette page ou directement sur twitter !
Top comments (0)