Agile ou Waterfall ?

Jusque ces dernières années je n'ai jamais été réellement convaincue par l'augmentation de la productivité ou l'agilité des IDEs (Integrated Development Environment) aussi bien pour Java (Eclipse/Netbeans/JDeveloper) que pour .NET (Visual Studio) notamment par rapport à UML (Unified Modeling Language). Ceci explique pour ma part le faible taux de pénétration réel de ce dernier dans les entreprises.

Même si beaucoup de projets se targuent d'en faire, cela restait plus un voeux pieux ou du simple sketching car une approche de type MDA (Model Driven Architecture) est dans la majorité des cas totalement irréaliste bien que très prisé par le Marketing de ces outils pour les vendre auprès des Managers Clients. Martin Fowler, Architecte bien connu dans le monde Java, a pourtant clamé haut et fort que cette approche puriste était déraisonnable car une architecture ne pouvait guère être robuste lorsqu'elle est conçue dans la pure théorie sans l'avoir expérimenté par codage. De ce fait Martin Fowler a toujours favorisé ce qu'il appelle le Sketching UML c'est-à-dire de simples ébauches de diagrammes pour favoriser la communication au sein de l'équipe.

La pratique est qu'aujourd'hui encore, les développeurs ont besoin de coder afin de pouvoir réifier des concepts abstraits. Partir de schémas UML détaillés ne les aide pas dans des cas qu'ils n'ont jamais abordés. C'est uniquement après avoir rencontré ces même cas un certain nombre de fois que le pattern UML finit par s'ancrer dans leurs esprits. Par conséquent, UML est plus utile pour les programmeurs lorsqu'il est utilisé en tant qu'outil de Reflection au même titre que des désassembleurs comme Reflector sauf que cela se fait à un plus haut niveau celui de l'implémentation fonctionnelle.

Bien sûr certains argueront que le Reverse-Enginiering d'UML existaient déjà dans la majorité des IDEs pré-cités. En ce qui concerne Visual Studio, il y avait et il y a toujours le Class Designer dont la philosophie était d'être le reflet à 100% du code. Néanmoins UML ne se limite pas aux diagrammes de classes qui sont en fait suffisamment proches des classes Java ou C# pour que l'on puisse même s'en passer. Le plus utile dans UML sont en effet les diagrammes de séquences:

Pourquoi ? L'approche Objet est censé "simplifier" le développement par rapport à la programmation procédurale. En réalité ce terme "simplifier" est trompeur. Encore une fois il s'agit d'un terme qui a été galvaudé pour des raisons marketing ou simplement de simplissisme. Mais rendre les choses simples ne signifie pas les rendre simplistes. L'approche Objet permet au contraire de s'attaquer à des problèmes complexes en les subdivisant mais tout théoricien de la complexité le sait, l'entropie d'un système ne peut pas décroître mais au contraire que croître. Faire un développement avec une approche objet est en fait plus complexe pour un programmeur car le code n'est plus séquentiel ou linéaire mais éclaté à plusieurs endroits avec des évènements qui déclenchent des appels de méthodes qui s'entrecroisent parfois dans tous les sens entre les objets. Comment peut-on croire après cela que la POO est plus simple ? La POO est un mal nécessaire pour créer des logiciels plus complexes mais cela engendre aussi plus de complexité pour le développeur.

Toute cette disgression sur la complexité pour expliquer la valeur ajoutée des diagrammes de séquences. De même que les diagrammes de classes permettent de faire une projection spatiale plus compacte pour visualiser l'architecture, les diagrammes de séquences permettent de faire une projection linéaire dans le temps qui permet au développeur de visualiser étape par étape le déroulement de son programme comme au bon vieux-temps du procédural. Jusqu'ici le déboggeur ou le log étaient en fait un substitut de fait à cause de l'absense d'outils de reverse-engineering de ce type de diagramme. Il y avait tout au plus des addins que l'on pouvait acheter pour créer des flowcharts d'une méthode mais cela restait insuffisant. Reflector disposait d'un addin pour cela mais cela tendait trop au bricolage et il manque bien sûr tous les autres diagrammes UML.

Enfin autre nouveauté dont on parle beaucoup moins pour le moment qui apparaît aussi dans Visual Studio 2010: le "Generate from Usage" qui introduit un assistant de refactoring qui permet de générer des classes au moment où l'on en a besoin. Du just-in-time ou du TDD (Test Driven Development) camouflé à la porté de tous.

En conclusion ceux qui n'auraient toujours pas migré de Visual Studio 2005 à Visual Studio 2008 feraient bien de directement passer à Visual Studio 2010. Vous ne le regretterez. En cas de doute vous pouvez bien sûr télécharger la version d'essai de Visual Studio 2010 Ultimate sur le site de Microsoft.