Je souhaite réagir à l'article "Productivité, agilité, industrialisation : même combat?" paru ce mois dans le numéro 113 du magazine PROgrammez. Cet article fait parti d'un dossier spécial dédié à la productivité. L'auteur y défend l'efficacité de la démarche Model-Driven avec génération du code. Il utilise certains arguments pour lesquels j'ai d'autres points de vue.
Tout d'abord, l'auteur affirme que "[la maintenance des modèles] est moins coûteuse que celle d'un code car celui-ci est dépendant de la technologie, des évolutions des outils, etc."
L'auteur a en tête les Platform-Independant-Models qui ne dépendent pas de la plateforme technologique. Par contre, il ne faut pas se leurrer: le modèle est très dépendant de la technologie MDE, de l'outil de modélisation, des outils de transformation de modèles et de l'outil de génération de code. Ainsi, les modèles restent dépendants de la technologie et des évolutions des outils.
Ensuite, l'auteur affirme que "L'éclectisme du code résultant des cultures et sensibilités diverses et variées des programmeurs se paye aussi comptant au moment du calcul des prix de revient des applications." Par expérience, j'ai remarqué qu'il existe autant de manières de modéliser une idée que de manières de la coder. Malgré un standard commun, j'ai pu constater que plusieurs développeurs au sein d'un même projet modélisent de manières différentes. UML n'est qu'une notation. De même, plusieurs rédacteurs rédigeront une même histoire de façons multiples.
Puis, l'auteur donne un avis avec lequel je suis fortement en désaccord: "Comment faire pour qu'un programmeur maintienne sans effort conséquent le code d'un autre? Comment faire pour qu'un programmeur retouchant celui d'un autre n'introduise pas, par simple incompréhension, des bogues? Réponse : le transformer en créateur de modèles et générer le code à partir de ses modèles!" La pratique du pilotage par les tests, le remaniement en continu, la suppression systématique des duplications et l'adoption de la solution la plus simple qui soit viable sont des voies pour modifier du code à moindre effort. Surtout, le pilotage par les tests (systématiques et couvrants) offre la seule garantie concrète que l'application ne régresse pas suite à une modification de code. La génération de code à partir de modèles n'offre pas de telles garanties. Qu'est-ce qui vous garantit que les défauts n'ont pas été introduits dans le modèle? Pourquoi les diagrammes n'exprimeraient que des idées justes? Pourquoi un modèle serait-il correct à priori? Seule l'exécution du logiciel permet d'affirmer qu'il est correct. Ne croyez pas que je dévalorise les modèles. En équipe, nous modélisons tous les jours ... avec des marqueurs et sur des tableaux blancs. Et puis, si nous modélisons en mode esquisse, c'est aussi parce que nous avons échoué en approche MDE ...
Plus loin dans son article, l'auteur avance que "maintenir un logiciel c'est raisonner sur des modèles UML sans présumer d'une technologie spécifique." Pour toutes les raisons vues précédemment, je ne suis d'accord avec aucune partie de cette affirmation. Nous maintenons efficacement des logiciels sans avoir recours à des modèles électroniques. Aussi, la modélisation électronique présume de technologies spécifiques.
Enfin, un leitmotiv flotte à travers l'article. Il est dit qu'il n'est pas toujours possible de développer avec "du personnel d'excellence", des "programmeurs hors-pairs". Parfois, il faudrait se contenter de "simples développeurs". Et puis pourquoi parle t-on si souvent de programmeurs et non simplement de développeurs? La modélisation et la génération de code seraient-ils des outils permettant de tirer le niveau vers le bas? Ces pratiques permettraient-elles de ne pas développer les compétences des équipes? Clairement, il me semble que l'auteur ne fait pas confiance aux développeurs et que la programmation est considérée comme une tâche ingrate.
Mais, pourquoi le mot "agilité" est-il utilisé dans le titre?
Par expérience, je suis complètement d'accord avec vous. Les modèles sont utiles, mais ne permettent de générer tout le code dont on a besoin. Et très souvent les modèles sont remis à jour en fonction des problèmes et mis à jour découverts lors du codage.
RépondreSupprimerDe plus, les développeurs sont rarement excellents, et les modèles sont souvent de trop haut niveaux pour leurs compétences.
Et puis lorsqu'on a besoin d'une technologie particulière, style EJB, si le modèle ne les génère pas, on est obligé d'adapter le code généré et toute nouvelle génération n'est plus possible.
L'auteur manque vraisemblablement d'expérience pratique.
Je suis fervent adepte de la modélisation, cependant je ne peux être que d'accord avec vos commentaires. Je n’ai pas lu cet article mais je me permets cependant de donner mon avis suite à vos commentaires.
RépondreSupprimerCe qui me choque dans les citations de votre article, c'est que l'auteur semble persuadé que la modélisation et le développement sont deux pratiques sans relations, que tout puisse être contrôlé par le modèle.
La modélisation est un outil qui permet de s'abstraire le plus souvent de la technique, pour disposer d'une vision générale et d'identifier des problématiques globales. Elle permet aussi un gain de temps par l'approche MDE via la génération de code, qui permet d'automatiser les taches répétitives spécifiques à des langages ou Frameworks.
Cependant le modèle n'est pas tout, il fournit plus un contexte qu'une véritable implémentation. En aucun cas il ne substitue au développement et tests de l'application.
J'ai le sentiment que l'auteur oubli que le passage de la modélisation vers le concret passe par la prise en compte des spécificités techniques. La modélisation ne permet pas de tout prendre en compte, et il serait utopique de supposer que "maintenir un logiciel c'est raisonner sur des modèles UML".
On dirait que la vision de la modélisation véhiculée dans l'article est la même que l'utilisation d'une documentation excessive : spécifier la totalité de la conception dans des documents avant la réalisation, en supposant que l'on pourra penser à presque tout.
Or c'est fasse à l'absurdité d'une telle démarche que sont nées les méthodes Agiles, permettant de spécifier au fur et à mesure du développement.
J'ai pu lire l'article en question. Même si les modèles sont parfois nécessaires, car cela donne un langage commun aux développeurs pour échanger sur les grandes idées, j'ai du mal à croire que 100 % code puisse être généré à partir de ces dits modèles.
RépondreSupprimerLe terme "programmeur" m'a choqué également, on pourrait le remplacer par "ouvrier" qu'on y serait pas très loin.
Mais l'impression que m'a donné l'article est presque une publi-information, sur un logiciel (BLU-AGE) de modélisation et de génération de code (il suffit de retourner Programmez pour y voir une grosse pub). Je doute donc de l'impartialité de l'auteur de l'article.
zorky, de nos jours, les programmeurs (voire les développeurs) sont considérés comme des "ouvriers" très qualifiés dans la plupart des SSIIs. L'age d'or du programmeur est terminé depuis bien longtemps maintenant. Il n'y a qu'à regarder les salaires pour s'en apercevoir et les commentaires des employeurs pour trouver qu'ils sont bien trop chers pour ce qu'ils font. Et le fait qu'ils sont maintenant offshorisés comme n'importe quelles autres ressources le prouvent.
RépondreSupprimerCa n'aide pas à la réalisation de logiciels de qualité dans les délais, mais c'est malheureusement la réalité.
Depuis les débuts du développement (SpeedCobol, 1978), il y a des applications pour lesquelles la transformation de modèles en code est adaptée et d'autres pour lesquelles le codage spécifiques reste incontournable.
RépondreSupprimerLa dimension temporelle a aussi sa place. Si des outils de génération comme BlueAge ou OptimaJ existent depuis plusieurs années, c'est certainement avec les prochaines versions d'UML, dans quelques années, que leur couverture de presque toute une application sera possible.
Pour finir sur les approches Agiles, si 18% seulement des exigences applicatives peuvent être fixées en début de projet, ce qui implique que les méthodes en cascade sont inadaptées pour 82% des projets, il n'y a certainement pas plus de 18% des applis qui peuvent faire l'objet d'un développement totalement itérarif.
Ce dernier point fait émerger l'idée qu'un mode semi-itératif serait indispensable pour le reste. Ce qui est aussi mis en évidence sur le blog de James Shore :
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
Comme il n'est pas question de supporter 3 méthodes dans une organisation. Il suffit d'une méthode adaptative semi-itérative ou la barre entre la cascade et l'itératif serait positionnée au bon niveau.
Lire a ce sujet le billet : Le mythe de l'itératif sans concession
sur
http://agiles.blog.com