Initiez-vous au software craftsmanship
Quel est le point commun entre un développeur, un boulanger et un ébéniste ? Il s’agit dans les 3 cas d’artisans – et dans certains cas d'artistes.
Un développeur est un artisan ?
En quelque sorte oui. Et depuis un certain nombre d’années on entend de plus en plus parler d'artisanat du logiciel (software craftsmanship). De quoi s’agit t’il ?
Il s’agit d’une manière de programmer qui met à l’honneur la méthode et la qualité du résultat. L’objectif n’est donc pas juste de programmer quelque chose qui marche, mais quelque chose qui est bien construit. Puisqu’un logiciel (et tout autre élément produit grâce à la programmation) “bien conçu” bug logiquement moins, il ne nous est pas difficile de faire le lien avec l’objet de ce cours !
Le software craftsmanship implique trois éléments fondamentaux :
Un état d’esprit : l’envie de créer un code propre et maintenable, le désir d’améliorer constamment la qualité de son code ;
Des outils : l’utilisation d’un ensemble d’outils pour monitorer et débugger son programme ;
Des méthodologies : SOLID, Test Driven Development (TDD), Behavior Driven Development (BDD), design patterns, Propositions d’Amélioration de Python (Python Enhancement Proposals ou PEP)...
Le software craftsmanship n’est donc pas une destination mais une route, qui fait non seulement du développeur un collaborateur plus productif et efficace, mais également plus heureux et épanoui.
Je vous propose d’aborder certains des éléments qui le caractérisent.
Découvrez les design patterns
Lorsque vous rencontrez une problématique technique en programmation – et même dans la vie de tous les jours – il y a de très grandes chances que d’autres personnes aient fait face au même problème que vous. Dans ce cas, ne serait-il pas « malin » de capitaliser sur leurs expériences ? En quelque sorte, d’apprendre des erreurs des autres ? C’est exactement l’intérêt des design patterns.
Un design pattern est une solution générale à un problème de programmation. Ce problème peut être propre à plusieurs domaines, mais le même design pattern sera appliqué. Imaginez, par exemple, que vous réfléchissiez à la manière de créer une classe et que vous réalisez que si l’objet qui en est issu change, plusieurs autres objets doivent être informés de ce changement parce qu’ils l’utilisent.
Comment structurer votre classe pour que les objets ne soient pas « trop » dépendants les uns des autres ?
Vous pourriez trouver une solution intéressante vous-même. Et justement, des centaines de développeurs très malins eux aussi ont réfléchi à une solution. C’est le pattern Observer. Il permet à vos classes « d’observer » ce que font les autres et qui est susceptible de les impacter. Alors, pourquoi ne pas l’utiliser ?
Il existe de nombreux design pattern. Ils prennent souvent la forme d’un diagramme de classes auquel est associé sa définition ainsi que les cas de figure où il serait pertinent. Il vous faudra traduire les principes d’un design pattern donné en algorithme, ou vous inspirer de la manière dont d’autres l’ont fait.
Utiliser les design pattern permet d’obtenir un programme plus flexible, plus maintenable et tout ça avec le moins de bugs possible. Ils permettent donc de s’assurer que le programme fonctionnera de manière prévisible puisqu’ils ont été largement testés.
Découvrez le Test Driven Development
Le Développement Piloté par les Tests (Test Driven Development, ou TDD) est un des outils préférés du software craftsman. Il prend à la lettre la phrase vue au chapitre Identifiez les 3 différents types de bug de la partie 1 : « Ce qui n’est pas testé ne marche pas ».
Concrètement, on peut appliquer la méthode dite « Red, Green, Refactor » :
Red : On commence par écrire le test qui vérifiera une fonctionnalité qu’on ne codera qu’après. Comment valider le test si la fonctionnalité n’existe pas ? Très bonne question ! Justement, le test ne sera pas validé, ce qui fait qu’à ce stade il sera rouge (red en anglais).
Green : L’heure est venue de coder la fonctionnalité et de lui faire passer le test. Tout est ok ? Le test passe au vert (green en anglais).
Refactor : Ici on refactorise, c’est-à-dire qu’on améliore, on peaufine. L’objectif n’est pas d’avoir un code parfait, mais d’avoir un code propre.
Évidemment, coder les tests peut prendre du temps, surtout qu’il ne faut pas oublier de les mettre à jour durant l’étape de refactoring (et plus tard si le code évolue). Faire un tour du cycle Red-Green-Refactor ne doit pas vous prendre beaucoup de temps. L’idée est de coder de petites fonctionnalités, pas à pas.
D’ailleurs, à chaque cycle il est possible de repenser totalement ou en partie un test, qui deviendra peut-être au fil du temps inutile. Mais croyez-moi ça en vaut la peine ! Si vous appliquez le TDD, votre code sera propre et fonctionnel. Il sera également plus maintenable et vous aurez beaucoup moins de bugs en production.
Déterminez si la PEP 8 et la PEP 20 en valent le coût
Impossible de parler de software craftsmanship en rapport avec Python sans aborder les Propositions d’Amélioration de Python (Python Enhancement Proposals ou PEP). En effet, Python étant un langage Open source, sa communauté dynamique fait des recommandations pour écrire du code Python à la fois clair, propre et performant. Ces recommandations prennent le nom de PEP 20 et PEP 8. Il s’agit de règles de style de code pour Python.
Pourquoi c’est si important ? Notamment parce que vous travaillerez probablement à plusieurs sur des projets. Et donc, si vous voulez maximiser la lisibilité de votre code, je vous recommande fortement d’appliquer la PEP 8 !
En résumé
Le software craftsmanship fait référence à une approche qui met l’accent sur les compétences du codeur et sur la qualité du code.
Un design pattern est une solution testée et approuvée pour un problème général. Il permet de capitaliser sur l’expérience de nombreux développeurs.
Le TDD est une approche qui met l’accent sur l’écriture de tests. On le met en œuvre notamment en appliquant la méthode Red-Green-Refactor.
Les Python Enhancement Proposals (PEP) sont des recommandations pour écrire du code pythonique dans les règles de l’art.
Il est temps de conclure notre aventure dans la dernière partie. 😭 Validez vos acquis avec un dernier quiz, avant de revenir sur tous les concepts que vous avez vus pendant ce cours avec moi. C'est parti !
