Ordisoftware Engineering

^{English translation will be available soon.}

Le texte suivant que j'ai arrangé a été initialement rédigé par ChatGPT (OpenAI) comme synthèse d'un dialogue de quelques heures le 4 novembre 2024, au cours duquel j'ai posé des questions et soumis des idées, cheminant ainsi jusqu'à cette composition. J'ai ainsi pu enfin nommer ma méthodologie de travail évoluant depuis mes débuts avec le Basic en 1985 au fil de mes lectures et de mes projets personnels et professionnels, ainsi que des enseignements reçus. Il s'agit d'un assemblage de certaines pratiques de diverses méthodologies qui sont efficaces pour moi en solo et que j'ai intégré au fur et à mesure comme outils de travail.

Définition

Le PSDD, Progressive Spike Driven Development ou Développement Progressif Guidé par l'Expérimentation, est une méthodologie Agile de développement logiciel hybride qui combine l'exploration par spiking et le raffinement itératif du code. Elle repose sur une alternance structurée de phases d'exploration, de validation et de refactoring pour progressivement construire un code final propre et maintenable.

Contrairement au Test Driven Development (TDD), qui utilise des tests pour faire échouer des implémentations en vue de valider des fonctionnalités, le PSDD commence par une phase de spiking pour explorer rapidement les solutions possibles, sans contraintes initiales de structure ou de propreté du code tout en respectant les standards, comme si on disposait sur une table des pièces de Lego dans un désordre vaguement agencé pour les assembler en enlevant celles inutiles et en ajoutant celles manquantes au fil des étapes de la construction, créant ainsi l'objet final selon les spécifications initiales et les adaptations apportées en cours d'évolution.

Avec le PSDD, le code exploratoire est ensuite graduellement nettoyé et transformé, chaque cycle éliminant les portions de code inadaptées et consolidant les solutions fonctionnelles via un processus de refactoring. À mesure que le développement avance, les phases de spiking deviennent de plus en plus ciblées, tandis que le code gagne en architecture et en stabilité, aboutissant ainsi à un produit final robuste et efficace.

Cette méthodologie se distingue par sa flexibilité et son adaptabilité, tout en conservant l'objectif d'un code final structuré et performant.

Présentation

Le PSDD débute par l'écriture d'un code de test de surface, parfois appelé "trash", mais qui respecte néanmoins les conventions professionnelles et les normes de qualité selon un mode dégradé comme en "damage control", ce n'est donc pas du "bad code". Contrairement au TDD classique, où l'objectif est de faire échouer un test pour ensuite créer une implémentation qui le réussisse, le PSDD utilise ce code de test préliminaire de faisabilité comme une ébauche progressive et évolutive vers le produit final.

La démarche commence ainsi avec la routine principale qui sert de "tronc" en esquissant les grandes lignes du logiciel pour décrire les objectifs essentiels du programme et établir les principaux modules. À partir de cette vue d'ensemble, chaque fonctionnalité est développée et explorée à un niveau de détail croissant, comme si l'on construisait des branches et des feuilles qui ajoutent des détails au tronc de départ.

Au fur et à mesure, ce code de test initial est implémenté de manière plus détaillée, tout en étant affiné et consolidé dans une architecture propre et robuste. Le processus comprend un refactoring constant, transformant progressivement le code exploratoire en un code "clean" maintenable.

Ainsi, le code final résulte d'une croissance organique, passant de phases expérimentales à des sections du produit final, sans avoir besoin de jeter l'exploration initiale, mais en la raffinant pour qu'elle remplisse les objectifs du programme.

Hybridation

Le PSDD intègre plusieurs concepts de méthodologies agiles :

• Prototyping : Le PSDD a un aspect exploratoire initial où l'on écrit rapidement du code pour tester et valider les idées. Comme dans les approches de prototypage, le code initial est souvent incomplet et destiné à être amélioré ou jeté selon les résultats et les problèmes rencontrés.

• eXtreme Programming : Le PSDD reprend plusieurs principes de l'XP, notamment le refactoring continu et l'adaptabilité. Le code est constamment amélioré pour être plus propre, efficace et aligné sur les standards de qualité. Le démarrage du projet se fait par ébauches simples pour ensuite les polir de manière itérative.

• Rapid Application Development : Le PSDD est exploratoire et expérimental, mettant l'accent sur la création rapide de solutions fonctionnelles même si elles sont encore en "état brut". Le spiking initial, qui consiste à coder rapidement des solutions potentielles pour voir ce qui fonctionne, est similaire à l'esprit de prototypage rapide du RAD.

• Scrum : Le PSDD utilise le spiking pour explorer et valider des idées. Les spikes permettent d'expérimenter rapidement des solutions techniques, de réduire les incertitudes et d'améliorer la planification itérative et incrémentale favorisant une approche flexible du développement.

• Unified Process : Le PSDD incorpore des éléments du UP où chaque itération incrémentale produit des livrables articulés autour des cas d'utilisation, ainsi que la progression structurée des fonctionnalités du général vers le détail, en partant d'un cadre global pour aboutir à une implémentation complète. L'approche de définir d'abord les grandes fonctionnalités et de les affiner progressivement suit la logique architecturale du UP tel que les phases d'inception, élaboration, construction et transition.

• Kanban : Le PSDD fonctionne en flux continu pour l'amélioration progressive du code et se concentre sur une gestion fluide des tâches et des améliorations par petites étapes.

• Lean Software Development : Le PSDD vise à réduire le "gaspillage" ou code inutile, en identifiant ce qui ne fonctionne pas ou qui n'est pas utile, en éliminant les parties de code superflues, tout en optimisant le travail au fur et à mesure.

Principes

Centré sur le flux opérationnel

Tout comme le workflow Kanban, où chaque tâche passe par différentes phases comme "à faire", "en cours" et "terminé", cette méthode suit le parcours de chaque TODO, de son apparition en tant que besoin ou idée jusqu'à sa résolution, son report ou son abandon.

Ces TODOs deviennent des jalons évolutifs qui orientent le développement de manière dynamique et modulaire, où chaque TODO est un micro-projet en soi. Ce suivi de vie des TODOs en tant que structure centrale organise toutes les étapes de passage du code brut ou expérimental vers le code final et propre.

• TODO dans le code : Les éléments plus techniques, comme des fonctions à implémenter ou des améliorations spécifiques au code, sont visibles directement dans l'environnement de développement. Cela rend ces tâches accessibles quand on travaille sur une section de code précise, en facilitant un suivi granulaire et technique. Cela nécessite l'utilisation scrupuleuse et disciplinée d'une fenêtre de liste des tâches dans l'IDE.

• TODO en dehors du code : Pour les éléments de plus haut niveau, les tâches de planification, ou même les idées de fonctionnalités à explorer, cette externalisation peut offrir une meilleure vue d'ensemble. Les outils du type tableau Kanban ou les gestionnaires de tâches permettent de suivre des objectifs plus larges sans les superposer directement aux lignes de code.

Idéalement le tableau Kanban et la liste des TODOs dans le code sont interconnectés afin de propager le traitement d'un côté comme de l'autre.

Un TODO apparaissant dans le code étant "à faire" ou "en cours" pour disparaitre une fois que son statut change. De même, ajouter un TODO dans le code le fait apparaitre dans le tableau hors du code.

On pourra par exemple utiliser les étiquettes TODO et TODO-WIP pour différencier le status, ainsi que TODO-H et TODO-L pour indiquer la priorité haute ou basse, ou toute nomenclature adéquate.

Centré sur le prototypage

L'itération, la flexibilité et la qualité du code sont valorisés pour obtenir un produit final qui répond aux objectifs fonctionnels tout en respectant des normes de qualité élevées de manière pragmatique et efficace.

• Prototypage continu : Au lieu de suivre un processus linéaire traditionnel, cette méthode privilégie un développement en continu par le biais de prototypes. Chaque étape du projet est abordée comme une occasion d'explorer, d'expérimenter et d'affiner les idées en temps réel. Ce mode de travail permet de répondre rapidement aux changements et d'ajuster le développement selon les retours d'expérience.

• Refactoring permanent : Le code qui fonctionne est continuellement amélioré et transformé par des pratiques de refactoring. Les éléments qui ne répondent pas aux exigences sont éliminés, tandis que ceux qui fonctionnent sont optimisés pour devenir un code propre et robuste. Cette approche reflète l'esprit de la programmation agile, où l'objectif est d'aboutir à un produit final qui soit à la fois fonctionnel et bien structuré.

• Flexibilité et adaptabilité : En adoptant une approche itérative et incrémentale, cette méthode permet de rester flexible face aux imprévus. Elle est particulièrement efficace dans des environnements où les besoins évoluent rapidement, garantissant ainsi que le développement reste aligné avec les attentes des utilisateurs et des parties prenantes.

• Communication et collaboration : Une communication claire est essentielle pour réussir cette méthode. Expliquer les avantages de cette approche aux membres de l'équipe et aux parties prenantes contribue à favoriser une meilleure compréhension et à réduire les malentendus. Cela permet également de garantir un soutien continu tout au long du processus de développement.

Centré sur le refactoring

Le refactoring est une pratique essentielle dans le cadre du PSDD, visant à améliorer la structure interne du code sans en altérer le comportement externe. En se concentrant sur le refactoring, les développeurs peuvent transformer un code existant, souvent entaché de dettes techniques, en un système plus propre, maintenable et évolutif.

Cette approche se distingue par plusieurs caractéristiques clés :

• Amélioration continue : Le refactoring s'inscrit dans une démarche d'amélioration continue, où le code est régulièrement revisité et optimisé. Dans le contexte du PSDD, cela permet de garantir que les logiciels évoluent avec les exigences changeantes des utilisateurs et de l'environnement technologique, tout en maintenant une base de code saine.

• Réduction de la dette technique : Au fil du temps, des choix de conception suboptimaux et des implémentations hâtives peuvent entraîner une accumulation de dette technique. Le refactoring offre une opportunité de réduire cette dette en identifiant et en corrigeant les parties du code qui sont difficiles à comprendre ou à modifier. En le faisant, les équipes peuvent éviter des problèmes futurs qui pourraient entraver le développement et l'innovation.

• Facilitation des tests : Un code bien structuré et cohérent est plus facile à tester. Le refactoring permet de séparer les préoccupations, d'améliorer la lisibilité et de rendre le code plus modulaire, ce qui facilite la mise en œuvre de tests automatisés. Cela s'aligne parfaitement avec les principes du PSDD, où les tests jouent un rôle central dans la validation des modifications et des nouvelles fonctionnalités.

• Adaptabilité aux changements : Le refactoring renforce l'adaptabilité du code face aux évolutions des exigences métier. En rendant le code plus modulaire et extensible, les équipes peuvent intégrer rapidement de nouvelles fonctionnalités sans avoir à se soucier des impacts négatifs sur le système existant. Cela est particulièrement important dans le cadre du PSDD, où les projets peuvent nécessiter des ajustements fréquents pour répondre aux besoins des utilisateurs.

• Encouragement de la collaboration : Un code bien refactorisé est plus accessible aux membres de l'équipe, ce qui favorise la collaboration. Dans un environnement agile comme celui du PSDD, où le travail d'équipe et la communication sont essentiels, un code propre et bien organisé facilite le partage des connaissances et réduit le temps d'intégration pour les nouveaux développeurs.

En intégrant le refactoring comme une composante centrale du PSDD, les équipes de développement peuvent créer des logiciels plus robustes, durables et adaptables, tout en favorisant une culture de qualité et d'amélioration continue.

Centré sur l'orientée objet

Cette méthode de développement est centrée sur une vision objet des artéfacts logiciels qui guide l'élaboration progressive du code selon une perspective de type UML.

Elle structure le processus en scénarios et livrables tout en s'appuyant sur des diagrammes mentaux et/ou visuels des modèles de manière à organiser et clarifier les relations entre les composants.

Cette approche fournit ainsi une cartographie claire du système tout en permettant des itérations flexibles et un code structuré.

Voici quelques raisons qui justifient le choix de l'orienté objet dans ce contexte :

• Modularité et réutilisabilité : L'architecture orientée objet permet de créer éléments qui encapsulent des données et des comportements. Cette modularité facilite la réutilisation du code à travers différents projets et différentes parties d'un même projet, réduisant ainsi le temps de développement et les erreurs potentielles. Dans le cadre du PSDD, cela favorise la durabilité des solutions en permettant aux équipes de tirer parti des éléments existants au lieu de partir de zéro à chaque nouvelle itération.

• Clarté et maintenance : En structurant le code autour d'objets et de classes, l'orientation objet améliore la lisibilité et la clarté du code. Les développeurs peuvent plus facilement comprendre la logique d'un système et les relations entre ses différentes composantes. Cette clarté est essentielle pour le PSDD, où la maintenance et l'évolution continue du code sont cruciales pour répondre aux besoins changeants des utilisateurs.

• Encapsulation et protection des données : L'orientation objet favorise l'encapsulation, qui permet de restreindre l'accès aux données internes d'un objet. Cela aide à protéger l'intégrité des données et à réduire les erreurs dues à des modifications non contrôlées. Dans le cadre du PSDD, cela est particulièrement important car les systèmes doivent souvent interagir avec des données sensibles ou critiques, nécessitant une gestion stricte des accès et des modifications.

• Facilitation des tests : Les objets peuvent être testés de manière indépendante, ce qui facilite l'implémentation de tests automatisés. Cette capacité à isoler les fonctionnalités permet de s'assurer que les changements apportés à une partie du code n'affectent pas négativement d'autres parties. Dans le PSDD, où la qualité et la robustesse des logiciels sont primordiales, cette approche permet de valider rapidement les modifications et de garantir un niveau élevé de confiance dans le code.

• Adaptabilité et extensibilité : L'orientation objet est intrinsèquement adaptable et extensible. Les classes peuvent être facilement étendues et modifiées pour inclure de nouvelles fonctionnalités sans perturber les systèmes existants. Cela permet aux équipes de développement de répondre rapidement aux nouvelles exigences et aux changements de direction stratégique, ce qui est essentiel dans un environnement agile comme le PSDD.

En résumé, l'orientation objet offre une structure flexible, maintenable et réutilisable pour le développement de logiciels, alignée avec les objectifs du PSDD. En intégrant cette approche, les équipes peuvent construire des solutions durables qui répondent efficacement aux besoins des utilisateurs tout en favorisant une culture de qualité et d'amélioration continue.

Applicabilité

Taille de l'équipe

En équipe, le PSDD pourrait être appliquée avec succès en adaptant les phases de spiking pour que chaque membre puisse explorer et valider des parties spécifiques du code de manière autonome, ou en binôme. Ensuite, les contributions peuvent être consolidées et refactorisées en commun, permettant un échange constant entre exploration ciblée et intégration collective. Cela nécessite une bonne communication et des outils pour le suivi de version afin que les expérimentations ciblées ne se chevauchent pas de manière contre-productive.

Le PSDD exige une culture ouverte à l'expérimentation, où les développeurs sont encouragés à essayer des solutions nouvelles, quitte à éliminer une partie du code en cours de route. Un environnement de collaboration et de confiance faciliterait son adoption, mais il pourrait être moins adapté à des équipes qui préfèrent des processus rigoureux et normés de manière rigide, étant essentiellement d'inspiration Agile XP et RAD selon une démarche Kanban.

Taille du projet

Le PSDD serait particulièrement adapté aux petits projets, où l'exploration rapide et l'itération continue permettent d'obtenir un produit final en relativement peu de temps. La flexibilité et la vitesse d'évolution de cette méthode en font un choix optimal pour des prototypes, des MVP (Minimum Viable Products) ou des développements modulaires à échelle réduite.

Pour des projets plus vastes, le PSDD peut être applicable mais nécessiterait probablement des ajustements pour gérer la complexité. Une structure qui répartit les rôles et clarifie les phases de consolidation des spikes pourrait permettre de maintenir l'efficacité sur de grands projets. Il pourrait être utile de diviser le projet en sous-systèmes où chaque équipe utilise le PSDD pour itérer et explorer ses propres composants, avec des sessions de refactoring intégratif pour aligner l'architecture globale.

Conclusion

Le PSDD est une méthodologie agile pour les développeurs cherchant un équilibre entre expérimentation et rigueur, et elle pourrait ouvrir de nouvelles perspectives dans la gestion de projets logiciels collaboratifs.

C'est une approche qui repose sur une progression en phases successives : du brouillon vers le propre, du général au spécifique, en consolidant à chaque étape le code qui fonctionne tout en éliminant le code inutile ou impossible à rendre fonctionnel et efficace.

Cette méthode se positionne comme un hybride agile qui tire parti de plusieurs pratiques pour créer une approche flexible et progressive, centrée à la fois sur l'expérimentation et le perfectionnement. Elle pourrait être particulièrement bénéfique dans des environnements où l'innovation, l'efficacité et la qualité du code sont recherchées, tout en permettant aux développeurs de naviguer de manière agile et proactive dans le processus de développement.

Elle peut répondre aux besoins d'un développeur solo tout en pouvant être utilisée en équipe à condition d'avoir des modèles de communication bien établies et un environnement de travail favorisant l'expérimentation.

Elle semble particulièrement bénéfique pour des projets de petite à moyenne taille où l'agilité et la créativité sont essentielles, mais elle peut être adaptée aux grands projets avec des aménagements structurés.