Un essai de formalisation de la qualité / An attempt to formalize quality

La maîtrise de la plateforme Mulesoft en général et de Dataweave en particulier étant en soi un sujet difficile, bien des développeurs s'arrêtent à un unique objectif: arriver au résultat demandé en passant par pertes et profit tout le reste. Une telle attitude est catastrophique car dès qu'on tente d'utiliser ce qui est fait en condition réelle, c'est le carnage: incidents à répétition, temps de réponse très au delà du prohibitif, impossibilité de comprendre ce qui se passe, etc, etc.

Dans toute réalisation informatique la question de la qualité est INCONTOURNABLE et le seul fait que "ça marche" est à des kilomètres d'être suffisant. Pour prendre une analogie, c'est toute la différence entre les mots "comestible" et "cuisine". Mais comme la notion de "qualité" en informatique est bien trop vague pour n'être autre chose qu'une invocation et un vœu pieux, permettez moi d'en apporter ici une définition un peu plus structurée. Selon mon analyse, la qualité se divise en sept critères, donnés ici par ordre décroissant d'importance:

1. La Robustesse
2. La Performance
3. La Justesse
4. La Résilience
5. L'Observabilité
6. L'Evolutivité
7. La Lisibilité

Avant d'entrer dans le détail de chacun de ses critères, arrêtons nous un instant sur cette notion de priorité qui peut légitimement interroger. Les deux premiers critères sont ESSENTIELS, c'est à dire que s'ils sont mal remplis:

1. L'application n'est pas utilisable et
2. Il y a une forte probabilité pour que l'application ne soit pas amendable (et donc qu'il faut tout jeter !)

Les deux critères suivants sont CRUCIAUX, c'est à dire que s'ils ne sont pas remplis:

1. L'application n'est pas utilisable mais
2. L'application est amendable (et donc on peut corriger les problèmes, ouf !)

Les deux derniers critères sont SERIEUX, c'est à dire que s'il ne sont pas remplis:

1. L'application est néanmoins utilisable mais
2. Sa pérennité est menacée à terme

Donc lorsqu'il y a des arbitrages à faire, il faut bien respecter ces priorités. Les critères cruciaux menacent tout, y compris le travail accomplis: ils ne peuvent ne aucun cas être négligés et doivent être résolus dès qu'ils se présentent. Les deux suivants sont indispensable, mais ne provoque généralement qu'une perte de temps. Les deux derniers sont un "(Very) Nice to Have". Passons maintenant ces critères en revue:

La robustesse: c'est la capacité de l'application à s'exécuter sans incident, c'est à dire ne pas planter, ne pas freezer, ne pas entrer dans des verrous mortels. Tout le monde comprend que cet aspect est indispensable. Ce qui est moins courant, c'est la conscience que parfois, la robustesse est tellement mal gérée, qu'il est nécessaire de tout refaire pour l'assurer, d'où le caractère absolument critique de ce critère.

La performance: c'est la capacité de l'application à être économe des ressources à sa disposition, qu'il s'agisse du temps d'exécution (la définition la plus commune de la performance), mais aussi la mémoire utilisée, la bande passante réseau, l'espace disque, etc. C'est un critère qui est souvent négligé par les développeurs comme étant accessoire ou amendable. C'est souvent le cas, mais pas toujours et parfois, retrouver de bonnes performances nécessite de revoir toute la conception, d'où le danger inhérent de ce critère.

La justesse: c'est la capacité de l'application de répondre correctement, c'est à dire de restituer les informations ou les commandes attendues par l'utilisateur. C'est la qualité "business" de l'application. C'est très souvent LE critère privilégié des développeurs, et même très souvent le SEUL assuré. Sans en négliger son importance, il ne faut pas oublier que les problèmes de ce type sont - sauf cas très exceptionnels - corrigeables.

La résilience: c'est la capacité de l'application de répondre aux sollicitations agressives, erronées ou défaillantes. C'est la robustesse "externe" en quelque sorte. Un des sujets majeurs de la résilience est la sécurité (sous toutes ses formes). L'autre gros sujet, c'est la disponibilité des autres pièces du SI qui doivent communiquer avec l'application. La résilience est très souvent un sujet qui négligé et le corriger consiste en fait à écrire le code nécessaire, car il est manquant

L'Observabilité: c'est la capacité de l'application à fournir des informations sur son fonctionnement. On y inclus le système de log, l'usage possible d'un débogueurs, la génération de rapport d'exécution, etc. De cette aspect, dépend la faculté des développeurs à identifier la raison d'un problème.

L'évolutivité: c'est la capacité de l'application à être étendue afin d'intégrer de nouvelles fonctionnalités sans remise en cause fondamentale.

La lisibilité: c'est la capacité de l'application à être comprise par un développeur qui n'a pas - ou peu - participer à son écriture.

Il arrive parfois que certains critères soient en contradiction avec d'autres. C'est en particulier le cas entre celui des performances (qui peut entrainer un accroissement de la complexité) et ceux de l'évolutivité et de la lisibilité (qui supportent assez mal l'accroissement de la complexité). Pour faire les choix pertinents, il est nécessaire de se référer aux priorités telles que données ci-dessus et la gravité des problèmes rencontrés (par exemple, s'il est licite d'accroitre la complexité pour améliorer significativement des performances réellement insuffisantes, il ne l'est pas forcément pour faire des optimisations pour une réalisation déjà suffisamment performante).

______________________________________________________________

Because mastering the Mulesoft platform in general, and Dataweave in particular, is in itself a difficult subject, many developers focus on a single objective: to achieve the required result, and write off everything else. Such an attitude is catastrophic, because as soon as you try to use what's been done in real-life conditions, it's carnage: repeated incidents, response times that are far beyond prohibitive, the impossibility of understanding what's going on, etc., etc.

In all IT projects, the question of quality is INCREDIBLE, and the mere fact that "it works" is miles from being sufficient. To take an analogy, this is the difference between the words "edible" and "cooking". But as the notion of "quality" in computing is far too vague to be anything more than an invocation and wishful thinking, allow me to provide here a slightly more structured definition. According to my analysis, quality can be divided into seven criterion, listed here in descending order of importance:

1. Robustness
2. Performance
3. Correctness
4. Resilience
5. Observability
6. Scalability
7. Legibility

Before going into the details of each of these criteria, let's stop for a moment to consider the notion of priority, which may legitimately raise questions. The first two criteria are ESSENTIAL, i.e. if they are not met, the application cannot be used:

1. The application is not usable and
2. There's a high probability that the application won't be amendable (and therefore has to be thrown out!).

The next two criteria are CRUCIAL, i.e. if they are not met:

1. The application is not usable, but
2. The application is amendable (and so the problems can be corrected, phew!)

The last two criteria are SERIOUS, i.e. if they are not met:

1. The application is still usable, but
2. Its long-term viability is threatened

Robustness: this is the ability of the application to run without incident, i.e. not to crash, freeze or enter deadlocks. Everyone understands that this aspect is essential. What is less common is the awareness that sometimes robustness is so poorly managed that it's necessary to redo everything to ensure it, hence the absolutely critical nature of this criterion.

Performance: this is the ability of the application to be economical with the resources at its disposal, whether in terms of execution time (the most common definition of performance), but also memory used, network bandwidth, disk space, etc. It's a criterion that is often overlooked in the design of applications. This is a criterion that is often overlooked by developers as being incidental or amendable. This is often the case, but not always, and sometimes restoring good performance requires a complete rethink of the design, hence the inherent danger of this criterion.

Correctness: this is the ability of the application to respond correctly, i.e. to deliver the information or commands expected by the user. This is the application's "business" quality. It is very often THE preferred criterion for developers, and very often the ONLY one guaranteed. While not neglecting its importance, it should not be forgotten that problems of this type are - except in very exceptional cases - correctable.

Resilience: the application's ability to respond to aggressive, erroneous or faulty requests. It's a kind of "external" robustness. One of the major subjects of resilience is security (in all its forms). The other major issue is the availability of other parts of the IS that need to communicate with the application. Resilience is very often a neglected subject, and correcting it means writing the necessary code, because it's missing.

Observability: this is the ability of the application to provide information about its operation. This includes the logging system, the possible use of debuggers, the generation of execution reports, etc. The ability of developers to identify the reason for a problem depends on this aspect.

Scalability: this is the ability of the application to be extended to integrate new functionalities without fundamental changes.

Readability: this is the ability of the application to be understood by a developer who has had little or no involvement in writing it.

Sometimes, certain criteria are in contradiction with others. This is particularly the case between performance (which can lead to an increase in complexity) and scalability and readability (which don't cope well with an increase in complexity). To make the right choices, it is necessary to refer to the priorities given above and the seriousness of the problems encountered (for example, while it is legitimate to increase complexity in order to significantly improve performance that is really insufficient, it is not necessarily the case to make optimizations for a project that is already sufficiently efficient).