“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 252 — #262
i
i
i
i
i
i
i
i
252
5
• La programmation avec état explicite
– Réorganisez la conception selon les besoins pendant le développement, pour
garder une bonne organisation des composants. Les composants doivent encapsuler les décisions prises lors de la conception ou implémenter des abstractions
courantes. Cette réorganisation est appelée refactorisation. Il faut trouver une
juste mesure entre une planification complète et une dépendance totale à la
refactorisation. La meilleure approche est quelque part au milieu.
Le développement incrémental a beaucoup d’avantages :
– Les bugs de toute taille sont détectés rapidement et peuvent être corrigés tout de
suite.
– La pression d’échéances est grandement soulagée car il existe toujours une
application qui fonctionne.
– Les développeurs sont plus motivés car ils obtiennent des réactions rapides à
leurs efforts.
– Les utilisateurs ont plus de chances d’obtenir ce dont ils ont vraiment besoin, car
ils ont la possibilité d’utiliser l’application pendant le processus de développement.
– L’architecture a plus de chances d’être bonne car elle peut être corrigée rapidement.
– L’interface utilisateur a plus de chances d’être bonne car elle est continuellement
améliorée pendant le processus de développement.
Pour la plupart des systèmes, même des petits, nous trouvons qu’il est presque impossible de trouver en avance les vraies exigences, une bonne architecture pour les réaliser
et une bonne interface utilisateur. Le développement incrémental est valable, en partie
parce qu’il fait peu d’hypothèses a priori. Pour une vue complémentaire, nous recommandons la programmation extrême, qui est une autre approche qui met l’accent sur le
compromis entre planification et refactorisation [91]. Pour une vue plus radicale, nous
recommandons le développement dirigé par les tests (« test-driven development »),
qui est incrémental d’une façon complètement différente. Le développement dirigé
par les tests prétend qu’il est possible d’écrire un programme sans aucune phase de
conception, simplement en créant des tests et en faisant une refactorisation chaque fois
que le programme ne réussit pas un nouveau test [10]. Il est évident que la conception
de bons tests est cruciale pour la réussite de cette approche !
5.6.2 La structure hiérarchique d’un système
Comment le système doit-il être structuré pour soutenir le travail en équipe et le
développement incrémental ? Une manière qui fonctionne en pratique est de structurer
l’application comme un graphe hiérarchique avec des interfaces bien définies à chaque
niveau (voir figure 5.4). L’application est un ensemble de nœuds où chaque nœud
i
i
i
i
i
i
i
i
252
5
• La programmation avec état explicite
– Réorganisez la conception selon les besoins pendant le développement, pour
garder une bonne organisation des composants. Les composants doivent encapsuler les décisions prises lors de la conception ou implémenter des abstractions
courantes. Cette réorganisation est appelée refactorisation. Il faut trouver une
juste mesure entre une planification complète et une dépendance totale à la
refactorisation. La meilleure approche est quelque part au milieu.
Le développement incrémental a beaucoup d’avantages :
– Les bugs de toute taille sont détectés rapidement et peuvent être corrigés tout de
suite.
– La pression d’échéances est grandement soulagée car il existe toujours une
application qui fonctionne.
– Les développeurs sont plus motivés car ils obtiennent des réactions rapides à
leurs efforts.
– Les utilisateurs ont plus de chances d’obtenir ce dont ils ont vraiment besoin, car
ils ont la possibilité d’utiliser l’application pendant le processus de développement.
– L’architecture a plus de chances d’être bonne car elle peut être corrigée rapidement.
– L’interface utilisateur a plus de chances d’être bonne car elle est continuellement
améliorée pendant le processus de développement.
Pour la plupart des systèmes, même des petits, nous trouvons qu’il est presque impossible de trouver en avance les vraies exigences, une bonne architecture pour les réaliser
et une bonne interface utilisateur. Le développement incrémental est valable, en partie
parce qu’il fait peu d’hypothèses a priori. Pour une vue complémentaire, nous recommandons la programmation extrême, qui est une autre approche qui met l’accent sur le
compromis entre planification et refactorisation [91]. Pour une vue plus radicale, nous
recommandons le développement dirigé par les tests (« test-driven development »),
qui est incrémental d’une façon complètement différente. Le développement dirigé
par les tests prétend qu’il est possible d’écrire un programme sans aucune phase de
conception, simplement en créant des tests et en faisant une refactorisation chaque fois
que le programme ne réussit pas un nouveau test [10]. Il est évident que la conception
de bons tests est cruciale pour la réussite de cette approche !
5.6.2 La structure hiérarchique d’un système
Comment le système doit-il être structuré pour soutenir le travail en équipe et le
développement incrémental ? Une manière qui fonctionne en pratique est de structurer
l’application comme un graphe hiérarchique avec des interfaces bien définies à chaque
niveau (voir figure 5.4). L’application est un ensemble de nœuds où chaque nœud