On fait comment une conception ?

Suite à mon précédent article un poil critique sur la revue de code, j'ai eu droit à une question intéressante de la part de mon collègue Douglas

sixdouglas Douglas SIX 10 avr. 2021 à 08:38:35 @nmahoude @riduidel Par contre, comment gérerais tu cette activité dans le cadre d’une équipe qui n’a pas une connaissance profonde du produit sur lequel elle travaille (je parle du turnover de l’équipe) ? Pourrait-on simplement faire de la conception ensemble ?

La première chose à noter dans cette question, c'est l'insistance sur le fait que les développeurs ne connaissent pas forcément le produit sur lequel ils travaillent. Et c'est parfaitement vrai.

Donc, ça veut dire quoi "concevoir un développement" ? Il s'agit tout simplement de jouer, pour un développement particulier, le rôle de l'architecte. Et là, je n'aide personne, puisque le rôle de l'architecte est particulièrement flou dans le monde du logiciel. Néanmoins, pour une fois, je pense que la définition de Grady Booch est appropriée :

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

Grady Booch - On design (voir aussi Software Architecture and Related Concerns)

Donc, quand on joue le rôle d'architecte pour un développement, c'est-à-dire qu'on le conçoit, on doit se poser les questions concernant les changements significatifs qu'on va apporter au système. Et pour revenir à la question de Douglas, c'est une excellente façon de découvrir le système et de le comprendre. Autrement dit, je propose d’utiliser ces phases de conception pour prendre le temps de découvrir ce qu'on va modifier.

Mais comment rendre cette connaissance partageable ? D'abord, via un support commun. Et si les issues des bugtrackers marchent bien pour discuter de petites modifications, je trouve que, pour les gros développements, il vaut parfois mieux créer un vrai document de conception qu'on mettra avec la documentation d'architecture - dans la section ADR. Sauf que j'aurais tendance à ne pas formaliser mon ADR aussi simplement que ce que proposent les différents modèles. Non, à titre personnel, j'aurais plutôt tendance à présenter le problème, puis la description de la solution en reprenant justement le plan de l'agile architecture documentation. Parce qu'il permet précisément de segmenter le gros problème en ses différentes facettes.

Typiquement, une grosse fonctionnalité, une qui requiert une documentation spécifique, va avoir des impacts sur différents éléments du logiciel : l'architecture, les donnée,s le déploiement. Et ce modèle de document couvre correctement ces différentes questions, comme je l'ai déjà écrit. Qui plus est, il permet facilement l'amélioration collaborative : un premier rédacteur peut lancer ses idées, et les voir améliorées par un second rédacteur.

Ce qui permet quelque chose que je trouve de plus en plus souhaitable, aussi bien organisationnellement que techniquement : remplacer le synchrone par l'asynchrone via un support permanent, et constamment amélioré.

Pour l'écrire autrement, ce que je propose est assez simple : quand vous lancez un nouveau développement, demandez à un nouvel arrivant d'en faire la conception en suivant le modèle de l'agile architecture documentation, en commençant par un simple commentaire dans le bug tracker puis, si il s'avère que la fonctionnalité est trop importante, dans un document que vous placerez dans vos ADR. Et relisez ce qu'il produit avant de lancer le développement.