Genezys : humeurs d'un codeur

Une histoire de plateforme ?

Lorsque vous développez une nouvelle plateforme, comme Windows, Mac OS X ou encore Linux, votre but est qu'elle soit utilisée. Or par définition, une plateforme n'a pas d'intérêt direct, son seul intérêt est de fournir à des développeurs des moyens de répondre rapidement et simplement à des besoins.

À ce titre, il est intéressant de voir qu'il existe d'autres plateformes que les systèmes d'exploitation. On peut considérer que le web est une plateforme avec des languages comme HTML ou CSS. On peut aussi considérer certains logiciels comme des plateformes, Firefox en plus de proposer un navigateur web propose une plateforme de développement avec le principe des extensions.

Bref, une plateforme, c'est un outil fournissant aux développeurs des outils de plus haut niveau leur permettant de développer des applications plus rapidement que s'ils n'utilisaient pas la plateforme. Bien souvent, cela s'accompagne d'un aspect psychologique. Un développeur qui utilise une plateforme recommande généralement son utilisation à ses amis, c'est qui va faire (ou non) le succès d'une plateforme.

Ah non... Une histoire de psychologie ?

C'est cet aspect psychologique qui va nous intéresser. La relation avec une plateforme est généralement fusionnelle : je t'aime, tu m'aimes, je ne te quitterais pas, bref que du nian-nian. Le plus important est qu'un développeur qui est satisfait de sa plateforme va aussi avoir une tendance à ne plus considérer que cette plateforme, avec tous les travers que ça peut apporter.

L'API que propose une plateforme est généralement intéressante, dans le sens où il est généralement plus rapide de passer par l'API de la plateforme que de refaire à la main ce que l'on souhaite faire. Le principe est de simplifier les opérations les plus communes sans pour autant restreindre les opérations complexes. Voilà le principe fort de conception d'une API.

Mais voilà, ce principe n'est jamais respecté, c'est un fait. Aucun API n'est parfaite. Certaines API permettent de faire très rapidement les opérations simples mais nécessitent un effort considérable pour faire une opération complexe, bien plus considérable que si vous n'étiez pas passé par cet API à l'origine. On peut ranger ce genre de désagrément dans la loi des abstractions qui fuient.

Le corollaire de cette observation est que les développeurs vont avoir tendance à s'éloigner des tâches complexes comme de la peste, en prenant en compte uniquement les tâches simples lors de leur conception. Durant la phase de conception, ils vont automatiquement rejeter les idées qui leur semblent complexes à effectuer sur leur plateforme au profit de solution plus simple. On appelle cela « concevoir selon l'API » et il faut être franc, c'est la pire chose qui puisse arriver à votre logiciel car ce n'est plus seulement votre implémentation qui est dépendante d'un tiers mais toute la conception de votre application. C'est généralement le meilleur moyen de voir apparaître de nombreux clones de votre produit conçus sur le même principe.

Finalement, une histoire de feignantise, tout simplement :-)

Pour comprendre notre problème des boites de dialogues, il suffit de regarder les API proposées par les différentes plateformes...

Sous Windows, quelques solutions :

• la fonction MessageBox() qui vous permet d'afficher une boite Oui/Non avec un choix de quelques icônes ;
• écrire votre fenêtre à la main.

Sous Mac OS X, une seule solution :

• créer et gérer un objet boite de dialogue.

Clairement, afficher une boite de dialogue est plus complexe dans une application Mac OS X que dans une application Windows, l'utilisation de la fonction MessageBox() étant vraiment très simple. Quelle est la conséquence de cette différence ?

En introduisant deux niveaux de difficulté dans son API, Windows a créé une tendance chez les développeurs à se tourner vers la solution simple et à s'écarter de la solution complexe. Bien que Microsoft recommande sur son site web de passer du temps à concevoir les boites de dialogues, l'API semble nous dire autre chose.

La différence principale entre ces deux API est que l'API Windows semble nous dire « Oui il faut passer du temps à concevoir les boites de dialogues, mais bon, si vous n'avez pas le temps, il est possible de faire rapidement un truc moyen ». Face à ce genre de choix, ma décision est rapide. Franchement, j'ai mieux à faire pour améliorer mon logiciel que de passer du temps sur mes boites de dialogues, non ? Le dernier Shrek est sorti au cinéma et je n'ai franchement pas envie de rater la séance.

Raté. Perdu. Tout faux. (Bande de petits galopins.)

Si votre utilisateur est frustré par l'un de vos composants, il reportera sa frustration sur tout le logiciel, le pire des composants donne donc le niveau général de qualité de votre logiciel. Vous devez donc assurez un niveau de qualité suffisant y compris dans vos boites de dialogues...

Oui mais voilà, c'est impossible, l'API Windows ne permet de facilement créer des boites de dialogues de qualité. Encore raté, encore perdu, encore tout faux. (Vous être vraiment une bande de petits galopins espiègles.)

Certes l'API Windows ne le permet pas, mais de là à dire que c'est impossible, on tombe dans de « la conception selon l'API ». Car il vous est toujours possible de créer une fenêtre, d'y placer des boutons et d'afficher ça à votre utilisateur en lieu et place de votre MessageBox(). Mieux encore, pourquoi ne pas créer votre fonction SmartMessageBox() qui permet d'afficher des boites de dialogues.

L'idée ici est d'arriver à sortir son esprit de la prison de l'API. Il faut tout le temps conserver à l'esprit votre but et se forcer à y arriver par tous les moyens. Parfois il suffira d'utiliser directement l'API, parfois il faudra reprendre depuis le début pour vous créer votre propre API.

Car finalement, le but d'une plateforme est d'arriver à minimiser votre temps de développement pour atteindre votre but, sans pour autant vous en faire changer. Il faudra donc vous demander ce qu'elle peut apporter mais surtout ce que vous ne pourrez pas utiliser par manque de qualité.

Alors ? Je fais quoi moi maintenant ?

Rien. En tout cas pas sur un coup de tête. Ce serait une erreur de plus que de suivre au mot mes conseils sur les boites de dialogues. Il faudra prendre le temps d'essayer, de comparer, de remettre en cause. Et puis il faudra trouver le courage de casser, de reprendre, d'améliorer.

Ce n'est qu'après ce long travail de recherche que le logiciel gagnera en qualité et donc en visibilité.