La base de toute réussite : les bonnes pratiques
Cet article fait partie d’une série nommée “Maximisez les chances de réussir votre projet informatique”.
Celui-ci aborde le thème des bonnes pratiques, que tout développeur se doit de connaître, mais il est bon de les garder en tête et de rappeler leur importance !
Style de code
Le style de code (accolades, tabulations, taille des classes et méthodes…) étant déjà très largement connu de tous, je n’en aborderai pas le détail.
💡 Néanmoins, sachez que je préconise systématiquement à mon équipe de définir un formateur automatique afin de partager le même et minimiser les conflits pour le gestionnaire de version
Commentaires et documentation
Les meilleurs commentaires sont ceux qui n’existent pas. A l’opposé, les tests constituent la meilleure documentation possible, du moins ils devraient ! (cf TDD)
Les commentaires ne doivent venir qu’en dernier recours, lorsque le code ne peut pas être simplifié au point de s’auto-documenter. Le nommage des variables, méthodes doit permettre de comprendre ce que le code fait !
En tant que développeur, le code est la seule documentation fiable et à jour que l’on puisse avoir, comme l’indique Alan Mellor sur Quora.
💡 Plus la documentation est loin du code, moins elle est fiable. Alors, pourquoi dépenser du temps et de l’énergie à essayer tant bien que mal de la créer et la maintenir sur un logiciel externe ?!
Workflow Git
Pour travailler plus efficacement au sein d’une équipe, ou bien même seul sur un projet, il est indispensable d’utiliser un workflow Git adapté.
💡 Je préconise l’adoption du workflow GitLab Flow qui selon moi est le plus pratique et cohérent
Outils d’analyse de code en continu
L’utilisation d’outils ou de logiciels qui permettent de surveiller la progression de l’état du projet.
Mettez en place ces outils, mais surtout, exploitez les ! Trop souvent, je rencontre des projets où SonarQube est en place mais n’est jamais ouvert.
💡 Il peut-être intéressant de paramétrer quelques règles spécifiques et revoir l’importance d’autres, pour coller au mieux au contexte
Intégré à la chaîne d’intégration continue, les outils d’analyse de code permettent d’avoir un retour sur le code rédigé et a tout à fait sa place dans une équipe agile. Plus les retours sont faits et pris en compte tôt, plus la qualité sera au rendez-vous.
👨💼 Un collègue a développé un Plugin SonarQube pour remonter les anomalies sur GitLab, directement sur le commit et donc la Merge Request
Principes de conception
La ligne directrice de conception KISS, acronyme de Keep It Stupidly Simple ou d’autres variantes, “laisse-le stupidement simple”, préconise d’opter pour la simplicité et d’éviter toute complexité dans la mesure du possible.
KISS est souvent associé à YAGNI, pour You Ain’t Gonna Need It, “vous n’en aurez pas besoin”.
On parle également très souvent de DRY, Don’t Repeat Yourself!, “ne te répète pas !”, car toute redondance introduit des difficultés pour la maintenance.
SOLID, acronyme de cinq principes de base pour la programmation orientée objet :
- SRP, pour Single Responsibility Principle, “Principe de responsabilité unique”, qui dit qu’une classe ou une méthode doit avoir une et une seule responsabilité
- Open/Closed, “Ouvert/fermé”, qui dit qu’une classe doit être ouverte à l’extension, mais fermée à la modification
- Liskov substitution principle, “Substitution de Liskov”, qui dit qu’une instance de type T doit pouvoir être remplacée par une instance de type G, telle que G sous-type de T, sans que cela ne modifie la cohérence du programme
- Interface segregation principle, “ségrégation des interfaces”, qui dit qu’il faut préférer plusieurs interfaces spécifiques pour chaque client plutôt qu’une seule interface générale
- Dependency inversion principle, “Inversion des dépendances”, qui dit qu’il faut dépendre des abstractions, pas des implémentations
Programmation en binôme
“Deux cerveaux valent mieux qu’un” ! Cette pratique peut sembler peu productive du point de vue du client, mais en réalité, elle s’avère être très intéressante. Chacun a quelque chose y apprendre et le risque d’erreurs est minimisé. C’est un vrai gain de temps à moyen et long terme.
💡 Il est possible d’aller encore plus loin dans la démarche avec le Mob Programming
Revue de code
Intégrez les revues de code dans votre flux de travaux. La revue de code se fait par une personne tierce, qui n’a pas participé au développement. Ce n’est en aucun cas l’expert technique qui doit effectuer l’intégralité des revues de code !
En plus de gagner en qualité de code et homogénéité, vos équipiers auront une meilleure connaissance du projet.
👉 J’aborde ces points plus en détail dans mon article : Travailler efficacement en équipe avec la revue de code
Les sessions de peer review permettent de faire grandir tous vos collaborateurs en même temps. Elles peuvent être organisées de façon récurrente, bien que je préfère les organiser selon le besoin pour maximiser leur intérêt.
Katas
Mettez en place des katas ou insistez pour qu’il y en ait qui soient mis en place. Ces katas vous permettront de gagner en efficacité, d’exercer les bonnes pratiques et même de découvrir de nouvelles méthodes de travail ou de nouveaux frameworks, langages ! Motivants pour les développeurs, c’est un grand plus pour votre équipe d’y avoir régulièrement recours.
💡 Vous pouvez trouver toute une série de katas sur Coding Dojo. Faites en et refaites en ! C’est avec la pratique qu’on s’améliore
La plateforme d’intégration continue, indispensable
La plateforme d’intégration continue doit impérativement être en place. Je ne conçois pas de développer sans elle.
👉 J’aborde ces points plus en détail dans mon article : Livrer de la qualité tout en restant productif
GitLab, ou Jenkins ?!
J’ai une grande préférence pour GitLab au dépend de Jenkins, car GitLab est plus proche du code. Ils ont fait un excellent travail autour des pipelines et intègrent nativement des fonctions essentielles. L’ajout d’un runner est très simple et configurable. La documentation et la communauté sont présentes.
Les retours sur la Merge Request peuvent directement être intégrés par la chaîne d’intégration continue. Le feedback est facile et immédiat via les événements proposés par GitLab, tels que les webhooks sur Mattermost.
Docker
Ah, Docker ! Qui ne connaît pas cette formidable plateforme de nos jours, au moins de nom ? Docker permet notamment de faciliter la livraison et la reproductivité en s’affranchissant d’une grande partie des détails techniques de l’infrastructure. Testez sur Windows, vous aurez le même comportement sur Linux (sauf si vous liez votre conteneur à votre OS et autres mauvaises pratiques).
Docker augmente la productivité et réduit le time to market.
Pour les développeurs, Docker peut notamment être utilisé au sein de votre chaîne d’intégration continue, pour builder vos sources, mais également pour publier un environnement de review de votre feature. Cet environnement sera alors monté pour chaque branche, vous permettant de tester directement votre évolution, pour ensuite être détruite lors de la validation de la Merge Request. Pratique !
Pour plus d’informations
Consultez le reste de la série “Maximisez les chances de réussir votre projet informatique” :
