Technology Management & Leadership

(Cet article est un pot-pourri d’idées, qui sera probablement clarifié dans différents articles plus tard) Lors de nos nombreuses discussions errant entre la philosophie et l’interrogation technique, Stéphane et moi parlions souvent de notre conception du code et du développement logiciel en général. Certaines différences de point de vue mineures, telles que: “devrions-nous mettre des espaces entre la première parenthèse d’une méthode et son premier paramètre?”, nous ont vite fait remettre en question notre vision du code. Jusqu’ici, le code était le résultat, là ou tous les processus et l’analyse mènent. Désormais, il n’est à nos yeux qu’une vue pour l’interpréteur ou le compilateur, tout comme les fonctionnalités sont des explications au développeur ou les spécifications pour le client. La première idée issue de ce principe était de lier de manière forte les éléments des documents d’analyse à travers le code, ainsi qu’aux différents diagrammes. De cette manière, on pourrait facilement juxtaposer les différents éléments dans une vue propre aux besoin d’un rôle. On pourrait aussi aisément suivre les changements autant en amont qu’en aval. On rend donc la documentation manuelle inutile, en plus d’en fournir une exacte et à jour en tout temps, puisqu’elle implémente un ou plusieurs éléments des documents d’analyse. Cette idée serait principalement traduite par une application de collaboration impliquant une structure de contenu extrèmement rigide.

Certaines fonctionnalités seraient:

• Intégration de code/diagrammes dans les documents d’analyse générés et vice-versa
• Rapport d’impact de modifications dans le code et les documents d’analyse
• Intellisense dans les documents d’analyse et vice-versa
• Intégration et interchangeabilité du jargon technique, spécialisé et du domaine d’affaires
• Rapports d’évolution et changements de l’application versus ses spécifications
• Intégration des tâches à leur contexte logiciel ET fonctionnel

Cherchant des éléments déjà existants pouvant servire de socle à une telle application, j’ai premièrement trouvé Eclipse, un conteneur d’applications ayant principalement un IDE complet supportant le formattage du code (le formattage est selon moi une abstraction importante à appliquer, puisqu’elle permet une personnalisation selon les besoins de visualisations). Quelques fonctionnalités intéressantes à ajouter seraient une nomenclature dynamiques (pourquoi une classe nommée Abonnement ne pourrait-elle pas être vue comme Inscription ou Compte sans avoir à passer par un outil de refactoring, modifiant ainsi la source?) et une vue partielle des classes (un peu comme les Region de Microsoft Visual Studio .NET, mais contextuels au besoin). Le système d’attributs et de commentaires de .NET permettraient de relier ce code rendu “anonyme” à une documentation riche.

Hors, jusqu’ici on ne manipule que du texte. Hormis les diagrammes de structures d’écran ( qui gagneraient à être liées aux tâches, au code et à la documentation au point d’être réutilisables avec très peu d’implication des développeurs ), les vues comportementales et structurelles ont déjà beaucoup d’attention de la part de différents joueurs majeurs dans l’industrie. Le standard UML de l’OMG me semblant une valeur sûre, j’ai fait quelques recherches sur les outils ou idées de cette communauté. En chemin, j’ai été un peu choqué par un principe: UML en tant que langage de programmation. Ce point mérite une explication. Dans mes tentatives d’intégrer le code à sa matière première, soit ses spécifications, je vois des gens tenter de faire le contaire, c’est-à-dire s’en débarasser. Hors, les diagrammes UML définissant avec une telle précision une application ne sont-ils pas du code en soi? Pire: leur structure étant de loin plus personnalisable que le code, il est impossible de les rendre “anonyme” sans les rendre incompréhensibles (je pense aux diagrammes de classes automatiquement générés par certaines applications). Bref, je crois qu’aucun environnement logiciel n’a jusqu’ici vraiment intégré le travail des équipes de développement et d’analyse, quoique les équipes sont grandement rapprochées par des outils tels que Microsoft Visual Studio Team System ou Borland Together. Le seul problème est de permettre une totale liberté dans les méthodologies et processus de travail sans perdre la documentation dans un toile épaisse et opaque. Quelles sont les solutions? Synchronisation avec les fichiers sources? Importation et génération de documents? Environnement collaboratif complet? Ce dernier est alléchant, puisqu’il permettrait une intégration parfaite entre les éléments de l’interface, mais jamais une telle application ne pourrait faire face aux nouveaux outils spécialisés tels que Sparx Enterprise Architect pour l’UML, ou les outils de la suite d’IBM Rational. La clé est donc sans conteste dans l’intégration transparente avec ces applications spécialistes. Hors, très peu d’entre elles permettent nativement une intégration humble. Un défi de taille.