“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 250 — #260
i
i
i
i
i
i
i
i
250
5
• La programmation avec état explicite
5.6.1 La méthodologie de conception
Beaucoup de choses, vraies et fausses, ont été publiées sur la bonne méthodologie de
conception pour la programmation à grande échelle. Une grande partie de la littérature existante est basée sur l’extrapolation d’expériences limitées, car la validation
rigoureuse est assez difficile à faire. Pour valider une nouvelle idée, plusieurs équipes
identiques devraient travailler dans des circonstances identiques. Cela a rarement été
fait et nous ne l’essayons pas non plus.
Cette section résume les leçons que nous avons tirées de notre propre expérience de
construction de systèmes. Nous avons conçu et construit plusieurs grands logiciels [42,
69, 96]. Nous avons beaucoup réfléchi à la bonne conception de logiciels dans une
équipe et regardé comment d’autres bonnes équipes fonctionnent. Nous avons essayé
de sélectionner les principes vraiment utiles.
La gestion de l’équipe
La première tâche, la plus importante, est de s’assurer que l’ensemble de l’équipe
travaille de façon coordonnée. Il y a trois idées pour atteindre ce but :
1. Il faut compartimenter la responsabilité de chaque personne. Par exemple, chaque
composant peut être affecté à une personne, qui en est responsable. Les responsabilités doivent respecter les frontières des composants et ne pas se chevaucher.
Cela évite des discussions interminables sur qui aurait dû corriger un problème.
2. Les connaissances doivent être librement échangées et non compartimentées.
Les membres de l’équipe doivent souvent échanger des informations sur les
différentes parties du système. Dans l’idéal, il ne devrait pas y avoir de membre
de l’équipe indispensable. Tous les changements majeurs au système doivent être
discutés par des membres bien informés. Cela améliore grandement la qualité
du système. Il est important aussi que le propriétaire d’un composant ait le
dernier mot sur un changement de son composant. Les membres inexpérimentés
de l’équipe doivent être en apprentissage chez des membres plus expérimentés.
Les membres inexpérimentés deviennent expérimentés quand on leur donne
des tâches spécifiques à faire, ce qu’ils doivent faire le plus indépendamment
possible. C’est important pour la longévité du système.
3. Chaque interface de composant doit être soigneusement documentée, car c’est
aussi l’interface entre le propriétaire du composant et les autres membres de
l’équipe. La documentation est particulièrement importante, encore plus que
pour la programmation à petite échelle. La bonne documentation est un pilier de
stabilité qui peut être consultée par tous les membres de l’équipe.
i
i
i
i
i
i
i
i
250
5
• La programmation avec état explicite
5.6.1 La méthodologie de conception
Beaucoup de choses, vraies et fausses, ont été publiées sur la bonne méthodologie de
conception pour la programmation à grande échelle. Une grande partie de la littérature existante est basée sur l’extrapolation d’expériences limitées, car la validation
rigoureuse est assez difficile à faire. Pour valider une nouvelle idée, plusieurs équipes
identiques devraient travailler dans des circonstances identiques. Cela a rarement été
fait et nous ne l’essayons pas non plus.
Cette section résume les leçons que nous avons tirées de notre propre expérience de
construction de systèmes. Nous avons conçu et construit plusieurs grands logiciels [42,
69, 96]. Nous avons beaucoup réfléchi à la bonne conception de logiciels dans une
équipe et regardé comment d’autres bonnes équipes fonctionnent. Nous avons essayé
de sélectionner les principes vraiment utiles.
La gestion de l’équipe
La première tâche, la plus importante, est de s’assurer que l’ensemble de l’équipe
travaille de façon coordonnée. Il y a trois idées pour atteindre ce but :
1. Il faut compartimenter la responsabilité de chaque personne. Par exemple, chaque
composant peut être affecté à une personne, qui en est responsable. Les responsabilités doivent respecter les frontières des composants et ne pas se chevaucher.
Cela évite des discussions interminables sur qui aurait dû corriger un problème.
2. Les connaissances doivent être librement échangées et non compartimentées.
Les membres de l’équipe doivent souvent échanger des informations sur les
différentes parties du système. Dans l’idéal, il ne devrait pas y avoir de membre
de l’équipe indispensable. Tous les changements majeurs au système doivent être
discutés par des membres bien informés. Cela améliore grandement la qualité
du système. Il est important aussi que le propriétaire d’un composant ait le
dernier mot sur un changement de son composant. Les membres inexpérimentés
de l’équipe doivent être en apprentissage chez des membres plus expérimentés.
Les membres inexpérimentés deviennent expérimentés quand on leur donne
des tâches spécifiques à faire, ce qu’ils doivent faire le plus indépendamment
possible. C’est important pour la longévité du système.
3. Chaque interface de composant doit être soigneusement documentée, car c’est
aussi l’interface entre le propriétaire du composant et les autres membres de
l’équipe. La documentation est particulièrement importante, encore plus que
pour la programmation à petite échelle. La bonne documentation est un pilier de
stabilité qui peut être consultée par tous les membres de l’équipe.