ConceptionSimple

Un article de Agora2ia.

Cette pratique XP est la mise en pratique directe de la valeur « simplicité ». Le code doit passer tous les tests et répondre aux critères de maintenabilité : concision, modularité, cohérence, lisibilité.

Les intérêts de concevoir le plus simplement possible à tous les niveaux sont multiples :

  • L’apprentissage du code existant par tout œil nouveau est facilité,
  • Les évolutions au sein de l’application ou d’un de ses modules seront également facilités et donc moins coûteuses.
  • Pour les mêmes raisons, la maintenance sera facilitée et moins coûteuse.


Mais quels sont les moyens pour favoriser une ConceptionSimple ?

Tout d’abord, une bonne façon de mettre en œuvre des conceptions simples, est de supprimer toute partie de la conception qui touche à des fonctionnalités dont on n’a pas besoin dans l’immédiat. Ne pas tirer de plans sur la commette. « Ok, ça serait cool si j’ajoutais cette fonctionnalité, en plus, je m’éclaterais à le faire, mais n’étant d’aucun intérêt dans l’immédiat, je prend sur moi, et je mets la fonctionnalité de côté ! Snif !». La conception doit être doit être un bon compromis entre « le strict minimum » et « l’utilisation de modèles ou frameworks garantissant une certaine évolutivité ». J’y reviendrais avec « Paul et Mick »…


Ensuite, un autre outil préconisé par XP est le TestDrivenDevelopment...


Enfin, le principal moyen fournit par XP pour garantir une conception simple est le développement itératif et incrémental. Concrètement, les moments où l’on fait de la conception dans XP sont :

  • le PlanningGame
  • une réunion improvisée à la demande d'un développeur,
  • le développement.

On peut pour cela s'aider de fiches CRC...

Paul et Mick dans l’extrême

L’utilisation systématique de design patterns remarquables n’est pas une attitude saine et pérenne sur le long terme. Mais l’utilisation d’un design pattern choisi judicieusement est souvent une bonne solution.


En extrapolant, on peut se poser la question sur le fait de mettre en place des frameworks conçus pas un architecte logiciel. Tout d’abord, étant entendu que la conception de l’application est la « propriété » de l’équipe, on peut se poser la question de la pertinence de l’existence d’un tel framework ?


Ensuite on peut s’interroger sur la pertinence du framework lui-même : Est-il adapté à la problématique ?... Face à cela, j’ai discuté avec un Scrum Master qui m’a dit que lorsqu’il y a un Architecte logiciel qui a pour charge la mise en place d’un framework, cet architecte doit obligatoirement participer au moins 2 jours par semaine au développements comme développeur, parie d’un binôme. Cela afin qu’il prenne conscience des problématiques liées à la mise en œuvre de « son » framework.