Développeur
Un développeur est un informaticien qui programme des
logiciels dans différents langages de programmation informatiques.
La notion de développement inclut :
- un travail d'équipe : les projets sont en général une collaboration entre plusieurs développeurs, qui traitent chacun
une partie du programme, mais aussi d'autres collaborateurs tels que les commerciaux, qui définissent avec le client la finalité
du produit, les concepteurs graphiques qui définissent l'aspect et l'ergonomie...
- la conception (design) : à partir d'un cahier des
charges (user requirement spécifications), définir les spécifications techniques (structure des données,
communication entre les modules...)
- les tests, qui servent à détecter les non-conformités et les erreurs (bogues) ;
- la maintenance : la correction des erreurs après la sortie du logiciel, et l'amélioration pour faire évoluer le
produit.
Top-down ou bottom-up ?
Le monde du développement informatique a été longtemps agité par la
question suivante : devait-on développer
- top-down, ce qui correspond
à la décomposition progressive de Descartes évoquée ici. On va du complexe au simple.
- Avantage : On est certain que la complexité de ce qu'on étudie se réduit à chaque étape
- Inconvénient 1 : La manière de décomposer n'a pas de raison d'être unique, ergo il se peut qu'on ne choisisse
pas la meilleure. Le problème se répéte et se cumule à chaque nouvelle étape de décomposition.
- Inconvénient 2 : Le découpage d'un problème en tranches peut escamoter involontairement les questions
transversales qui n'appartiennent spécifiquement ni à une tranche, ni à une autre. Pire : au moment où on examine
chaque tranche, on peut de bonne foi croire que le problème transversal est du ressort de l'autre. Or, pour un problème complexe
il ne semble guère possible de garder en tête simultanément tous les problèmes transversaux en suspens, sauf dans les cas où l'on
sait déjà très bien formaliser pour des raisons d' habitude
Ces considérations conduisent à ne pas remettre en cause le modèle top-down dans un cas : celui des problèmes qu'à
quelques détails près on connaît bien.
- bottom-up, ce qui
correspond à la maîtrise progressive d'éléments simples, et que l'on combine pour cheminer vers une complexité de plus en plus
grande. On va du simple au complexe.
- Inconvénient : beaucoup d'essais et d'erreurs, et pas toujours dans les bonnes directions. On tâtonne.
- Mais en contrepartie on se familiarise avec les éléments de la résolution, on voit où on met les pieds, on acquiert des bases
stables.
Un pianiste qui fait des gammes, puis des accords, puis des arpèges, puis des exercices de déliateur avant d'attaquer des
œuvres simples, puis de plus en plus compliquées travaille en bottom-up. En top-down, il prendrait d'emblée la
Fantaisie impromptue de Chopin, puis la
décomposerait, par exemple mesure par mesure. Ca marchera aussi, mais cela serait-il la méthode la plus efficace ?
Le chat qui attrape une souris travaille aussi en bottom-up, en jouant avec la souris et en acquérant peu à
peu les concepts qui le rendent plus efficace. Il n'a pas de théorie générale sur l'apprentissage des souris, qu'il décompose en
éléments pour vérifier chacun un par un.
Peindre la Joconde par la méthode de Descartes sur un écran 1024×1024 : couper le tableau en 4, puis chaque
quart en quatre, jusqu'à ce qu'on tombe sur un pixel. On ne peut pas trouver plus simple ni plus petit. Il n'y a donc plus qu'à
choisir la couleur du pixel. « Diviser chacune des difficultés que j'examinerais, en autant de parcelles qu'il se pourrait,
et qu'il serait requis pour les mieux résoudre », c'est fait. Est-on bien certain d'obtenir la Joconde par ce
moyen ?
Cela suggère une approche où chaque méthode a son domaine d'usage optimal :
- Le top-down pour tout ce qu'on maîtrise à peu près dans les grandes lignes
- Le bottom-up pour explorer efficacement les terra incognita.
Voir aussi
Cet article une ébauche à compléter, partager vos connaissances en le modifiant .

