Le principe de gratification
12 07 2007
Si comme moi, vous pensez que la motivation est le critère numéro un de productivité des développeurs, vous devez alors vous poser la question de savoir comment entretenir cette motivation. L’auto-gratification est un de ces principes psychologiques.
Il s’agit d’adapter son style de développement en mode incrémental. L’idée est de développer bout par bout plutôt que de chercher à réaliser de « grosses » fonctions en one-shot.
Prenons l’exemple d’une fonction « Réaliser une interface de gestion d’utilisateurs avec création/suppression/consultation« .
On peut utiliser deux stratégies : Soit construire chacune des couches (interface, puis métier et enfin données) en mode horizontal, soit construire en vertical chaque sous fonction (d’abord faire toute la consultation, puis la création, etc.)
Et bien le principe de gratification voudrait que l’on utilise la stratégie verticale afin de découper la fonction en petits morceaux réalisables unitairement. Pour la bonne raison que pour chaque sous fonction réalisée, il sera possible de constater que notre bout de code donne un résultat. La voilà notre motivation : voir que notre code fonctionne !
C’est exactement ce que nous encourage à faire le développement orienté par les tests (TDD) : En effet, vous codez un test qui échoue, et vous écrivez le code suffisant qui fait passer le test. A chaque barre verte affichée (le signe que le test passe), c’est une satisfaction de constater que l’on « avance », que le programme se construit et qu’il fonctionne…
C’est un point de vue intéressant, mais il faut également prendre en compte l’équipe de développeurs dans sa globalité. Si tu mets deux personnes à travailler sur un même sujet, il se peut qu’elles fassent du code redondant. Le développement en couche permet d’éviter cette redondance. Alors que le développement vertical le permet moins.
Wolf : je suis tout à fait d’accord mais l’exemple partait sur le principe d’une personne seule effectuant le développement d’une fonction complète.
Das ce cas, ce n’est pas l’organisation des tâches entre développeurs qui importe.
J’ai trop souvent vu des développeurs commencer par coder un bout de composant service, puis un bout d’IHM et revenir sur la couche données, …
En voir le bout revient à carrement réaliser un mini-projet d’intégration !