Depuis un certain nombre d’années, le débat relatif à l’importance ou à l’inutilité des commentaires au sein du code fait rage. D’un côté, les partisans du tout commentaire, pensent que la présence de commentaires est indispensable à la compréhension du code, et que par conséquent, toute portion de code doit être commentée. Le fait de ne[…]
Nous présentons ici quelques caractéristiques que tout bon test unitaire se devrait de présenter. Dans la pratique, et selon le contexte, il est difficile de cumuler toutes ces qualités. Il s’agit avant tout d’indications qu’il est important de garder à l’esprit quand on écrit un test unitaire. Ciblé En ciblant ce qui est testé, on s’astreint[…]
En fin d’année les bêtisiers étant généralement à l’honneur, c’est l’occasion de présenter des exemples de choses à ne pas faire ou à éviter dans le développement d’un projet. Le God Object Le god object est une forme de programmation particulière s’appuyant sur le principe « Dieu est omniscient et omnipotent ». En pratique, on se retrouve avec une seule[…]
La dégradation du code Lorsqu’on travaille seul (ou tout au plus en binôme) sur un projet, il est beaucoup plus facile d’appliquer les règles du clean code. D’autant plus si il s’agit d’un nouveau projet, dont le point de départ est, par définition, propre. Etant seul à faire évoluer le code, on est seul responsable de sa propreté,[…]
N’importe quel développeur peut produire du code qu’un ordinateur est capable de comprendre. Ce qui caractérise un bon développeur, c’est qu’il écrit du code que d’autres développeurs sont capables de comprendre. Dans cette optique, un nommage rigoureux des éléments du code est essentiel. Limiter les commentaires En matière de nommage des identificateurs, la règle d’or suivante devrait[…]
En test-driven development (TDD), on cherche à écrire du code directement testable; cela entraîne des conséquences immédiates sur la conception. Le processus se présente ainsi : on part d’une première fonctionnalité, assez simple, en se basant sur sa spécification; on écrit le code testant cette fonctionnalité et on l’exécute immédiatement : la fonctionnalité n’étant pas implémentée,[…]
Le kata de code Bowling Game tel qu’il est présenté ici par Uncle Bob est une parfaite illustration des concepts du Test-Driven Development, notamment de la boucle red-green-refactor, et de la notion de baby steps. Prenez d’abord connaissance du problème (première slide) et essayez de proposer une solution, en essayant d’utiliser l’approche TDD ou non (à[…]
Dans un monde idéal, le développeur n’écrirait que du code neuf, qu’il pourrait rendre élégant et parfait. Ainsi, il ne serait pas confronté au code des autres, en général moche et incompréhensible. Il ne serait pas davantage confronté à son propre code plus ancien, qui en vieillissant ressemble de plus en plus à ce fameux code des autres.[…]
Clean Code: A Handbook of Agile Software Craftsmanship, par Robert C. Martin (aka Uncle Bob), est un ouvrage de référence dans le domaine du Software Craftsmanship. Pour ces auteurs, le Clean Code c’est : Bjarne Stroustrup (inventeur du C++) : le code clean doit être élégant et efficace, et la gestion des erreurs doit être totale. Grady[…]
Cucumber est un framework de test dédié à l’écriture de tests fonctionnels dans un style behaviour-driven development (BDD). La description des tests s’effectue au moyen de Gherkin, un langage non-technique et orienté langage naturel afin de s’adresser à toute l’équipe de développement, y compris les analystes métiers. Gherkin supporte une cinquantaine de langues (les mots-clés ont été traduits)[…]
Tests façon BDD Dans le cadre de behaviour-driven development (BDD), le terme « spécifications » va être préférable au terme « tests ». L’idée est de rapprocher l’élaboration des tests unitaires de l’élaboration des tests fonctionnels, et d’impliquer fortement les experts du métier dans l’écriture des tests. L’élaboration des scénarios de test repose grandement sur le canevas Given-When-Then : (Given) (Etant[…]
DevOps est un mouvement cherchant à rassembler les équipes intervenant dans le système d’information, réunissant en une même équipe les Dev en charge des évolutions et les Ops en charge de l’exploitation. L’objectif est ainsi de favoriser le travailler ensemble entre les équipes de développement et les équipes de production, produisant ainsi plus de valeur pour[…]
Feature Flipping Le code en cours de développement est livré en production, mais son exécution est conditionnée à la présence d’un flag qui peut être activé ou non par configuration, sans nécessiter un redéploiement. Ce mécanisme peut se mettre en oeuvre de façon simple dans le code, avec un helper chargé de vérifier l’activation de la fonctionnalité[…]
Mono-branche Une seule branche qui est la branche principale Tous les projets commencent par ça L’intégration continue doit forcer les développeurs à committer du code stable Fonctionne en petite équipe mais nécessite beaucoup de communication et une intégration continue performante Une branche par équipe En plus de la branche principale, chaque équipe dispose de sa[…]
Les pré-requis Les trois éléments suivants sont indispensables : un référentiel de contrôle de version, dans lequel tous les éléments du projet sont publiés un build automatisé le plus important : l’adhésion complète de l’équipe Contrôle de version Le référentiel de contrôle de version est indispensable, quel que soit le nombre de développeurs impliqués dans[…]
Définition de l’intégration continue (CI) par Martin Fowler, précurseur et promoteur de cette pratique : « Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to[…]
La gestion de configuration (ou gestion de versions), par l’utilisation du source-control management (SCM) est une pierre angulaire du Continuous Delivery, c’est le référentiel à partir duquel il est possible de construire les livrables de façon reproductible et automatisée. Le SCM est également au centre du travail en équipe et nécessite, pour être efficace, la[…]
Problématique de la livraison de logiciel : c’est traditionnellement un événement qui mobilise beaucoup de ressources à une date prédéfinie à l’avance, qui est synonyme de stress pour les équipes, sur lequel certains intervenants ont le sentiment de jouer leur carrière, et qui se déroule rarement comme prévu. Il est également courant de provoquer une[…]