bien programmer est un art, où tout au moins un artisanat, un peu comme un ébéniste.
Par programmation, j’entends l’ensemble des activités, permettant de passer de l’expression d’un besoin à un système informatique. Cela regroupe donc ce qu’on appelle l’analyse, la conception, la programmation, les tests, …
Bien sûr, les grosses boites vous parlent de processus industriels.
Ils ne vont pas vous dire le contraire, quand on allonge une facture de plusieurs centaines de milliers d’euros…
Ce sont les mêmes qui réalisent les systèmes informatiques des grosses banques… Vous me suivez ?
Mais la réalité est aujourd’hui plus simple, toute nue : la qualité de votre système informatique, quel qu’il soit, dépend de la qualité des artisans qui le construisent.
Une des qualités fondamentale pour bien programmer, c’est l’art de l’abstraction.
Pourquoi ? (j’aurais pas du regarder Sarkozy l’autre soir moi, j’ai une rechute)
Quand on doit réaliser une application, la base de la programmation, c’est de découper le problème, dans deux sens : verticalement et horizontalement.
Verticalement : on sépare le problème, fonction par fonction (pour un front office, on parlera par exemple du processus achat, du catalogue produit…)
Horizontalement : on sépare le problème en couche (toujours pour notre front, on pourra faire une couche pour les données, une couche pour les objets métiers et enfin une couche présentation).
Ce découpage à pour but de définir des modules, entité informatique ayant d’une part une complexité maîtrisable et d’autre part une certaine homogénéité.
Pourquoi ?
- Un module doit être plus simple à programmer parce que le problème qu’on cherche à régler est une partie du problème global.
- Le module est plus homogène parce qu’il ne résoud qu’un type de problème (les données pour le processus achat par exemple).
Le programmeur, notre artisan, doit donc être capable de faire abstraction des autres problèmes (voisins de gauche et de droite et du dessous) pour se concentrer sur son « morceau » du problème.
ça encore, c’est pas le plus dur.
Le plus dur, c’est qu’il doit à son tour donner une interface à son module ayant le bon niveau d’abstraction.
Il doit bien faire la différence entre « sa cuisine interne » et la vue qu’il donne sur son module.
Concevoir l’interface d’un module est réellement une partie passionnante. On se retrouve dans la situation de définir le « panneau de contrôle », donnant donc une vision la plus simple et la plus abstraite du problème qu’on doit résoudre.
tout à fait d’accord sur l’ensemble, mais je ne vois pas en quoi une « grosse boite » ne serait pas faire ça.
Sa plus value, c’est la gestion de gros projets, la coordinations d’un grand nombre d’acteurs, la compréhension de besoins très complexe, le découpage vertical et horizontal qui en découle, la possibilité de trouver en interne des ressources qui ont l’expérience nécessaire, ou la compétence pour soutenir une entreprise dans ce type de projet. Je suis 100% d’accord pour dire que c’est un travail d’artisan dans le sens noble du terme, mais ce n’est pas une question d’échelle, c’est une question de personne.
@Pascal> Oui, c’est une question de personne, on est bien d’accord. Et bien entendu, il y a des personnes compétentes dans tout type de structure, y compris les grosses boites donc.
Je n’ai donc rien contre les équipes des grosses boites, mon propos n’est pas là.
Ce que je dis, c’est que le marketing des grosses boites essaie de faire croire qu’on a dépassé ce stade, et que la construction d’un programme est un processus industriel, ou la compétence individuelle finalement n’entre pas en jeu.
On est donc bien d’accord, la compétence des équipes est l’élément clé.