Technology Management & Leadership

Dans la veine de Le code; un simple format de spécifications?, voici une idée qui pourrait peut-être devenir une jointure possible entre les avantages des modèles graphiques et les éditeurs déjà très avancés disponibles aujourd’hui. Elle éveillera peut-être quelques gens ayant travaillé avec Macromedia Flash.  

Vérifions certains requis pour une solution applicable:

• Le code doit rester flexible
• On doit pouvoir coder aussi rapidement qu’en mode textuel pur
• On doit pouvoir accéder à des vues différentes en navigant et en contexte
• Une application de collaboration et de développement devrait permettre de “voir” autant la documentation que le code d’une manière flexible et fortement typée

Imagineons maintenant une page de code dans Microsoft Visual Studio. Considéront maintenant chacun des éléments imbriquables dans l’exemple suivant:

1.public Person FindOwner( Car lostCar )
2.{
3.  ValidateCarOwnership( lostCar );
4.  Person owner = base.FindOwner( lostCar );
5.  if( owner != null )
6.    return owner;
7.  else
8.    return new UnknownOwner();
9.}

Si on considère base.FindOwner, on sait qu’un appel est fait à la super classe. Celle-ci contient un algorithme et un contexte d’exécution lui aussi encapsulé. Dans ce cas précis, nous pouvons imaginer les choses suivantes:

• Ne voir que la hiérarchie des appels à l’intérieur de la méthode, dans un format de liste
• Remplacer la ligne 4 par le code du parent (peut-être grisé)
• Garder l’opération et remplacer la méthode par sa documentation
• Remplacer la ligne 3 par l’opération et sa méthode imbriqués
• “Écraser” la classe et son parent ensemble de manière à ne voir que l’implémentation finale pour faciliter la lecture

Pour arriver à modeler la vue textuelle, il faudrait que chacun des éléments soit utilisable comme un objet visuel sur lequel un clic simple, par exemple, sélectionnerait l’élément (en plaçant bien sûr le curseur sous la souris dans le texte). Une double-clic ouvrirait l’élément dans son contexte (encore une fois, un code de couleur pourrait identifier les éléments liant les variables du corps de la méthode avec l’appellant). Un contrôle-clic quant à lui donnerait plein focus à l’élément sélectionné. Pour chaque élément sous la souris, de petits icônes pourraient être disponibles pour passer du code à la documentation, et de la documentation à une liste cliquable des relations.

D’un côté, une telle approche forcerait le développeur à mettre autant d’emphase à clarifier les relations entre les objets que les objets eux-même, ce qui en soi n’est pas une mauvaise chose. D’un autre, elle offrirait une manière plus “graphique” de travailler sur le code dans un environnement liant étroitement les documents d’analyse à l’implémentation. Finalement, cette approche permettrait de travailler sur un aspect du code en gardant une approche 100% orientée objet.

Un tel éditeur sera par contre un vrai défi à prototyper.