L’intégralité organique, fonctionnelle, une petite définition.

Suite à la rédaction d’un billet sur la revue de code   et dans laquelle je parlais d’intégralité organique et fonctionne du code. Et j’ai reçu un commentaire judicieux d’une personne qui me demandait d’expliquer ces concepts.

Donc, voici ma vision (une définition qui n’en est pas une) sur ces deux concepts.

Commençons par l’intégralité fonctionnelle. Lorsque nous écrivons du code. Nous ne le faisons pas parce que cela fait joli. Pour démontrer, que nous capable de faire des algorithmes complexes, du code qui ne sert à rien, juste écrire du code.

Une fonction, une classe ou simplement quelques lignes doivent avoir un objectif à remplir. Si j’écris la fonction SupprimerLesEspacesDansUneChaine (la fameuse fonction « TRIM »). Son objectif est de supprimer les espaces dans une chaine et la retourner à la fin, une fois le traitement terminé.

Dans notre exemple, on ne devrait jamais trouver du code pour le calcul de Pi dans cette fonction. Par contre, elle doit contenir le traitement de validations des entrées et une gestion d’erreurs adéquates.

On doit aussi avoir les outils qui démontrent l’atteinte d’objectif. Ce n’est pas juste la parole de son programmeur qui le valide. Souvent, je conseille d’avoir de petits programmes de tests (Unit Test and Fonctionnal Test). Mais, une série d’exemples d’utilisation, lorsque c’est une classe ou fonction d’utilités (la fonction « Trim », ne fait rien de spécifique dans l’application. Mais, elle aide d’autre traitement à atteindre leur objectif à eux.)

Cette intégralité fonctionnelle devrait être couverte par les tests unitaires bien sûr. Mais aussi, par des tests fonctionnels; automatiser si possible. Il est intéressant, de conserver une copie des tests et de leurs résultats aux fins d’archives.

L’intégration organique (ou logiciel),  couvre plusieurs aspects. Bien entendu, le respect de la nomenclature de l’écrire du code (Nom de la classe, des fonctions et méthodes, des variables, etc).

Mais, il faut aussi vérifier que le code produit, ne compile pas juste le poste du développeur qui l’a écrit. Il doit aussi compiler dans les environnements continus ou sur les « Build Machines ».  J’ai déjà vu du code qui compilait sur tous les postes des développeurs. Mais, lorsque nous avions voulu, faire une version officielle avec la Build Machine. Ça avait fait « Boom », le code ne compilait pas du tout.

Pourtant, ce code avait révisé par toute l’équipe. Il respectait les standards de programmations. Mais,  il n’avait jamais été compilé entièrement avec les sources de la version officielle qui était pour la livraison chez les clients.

L’autre aspect souvent oublié, c’est la manière de faire les choses. Beaucoup, d’organisation on des librairies de composantes utilitaires. Et il faut les utiliser, lorsque nous travaillons.

Par exemple, on a beau avoir construit la meilleure fonction de validation d’un NAS (Numéro d’Assurance sociale). Si nous n’avons pas utilisé, la fonction standard de l’organisation. A mes yeux, nous avons un problème d’intégrité organique (ou logiciel).

Il faut chercher à ne jamais réinventer la roue. Il faut l’utilisé au besoin, encore plus en orientés objets avec les principes de la surcharge et de l’héritage.

L’autre aspect, les fameux algorithmes géniaux. Mais, donc le nom du programmeur est marqué en dessous. A moins, que nous lancions une fusée sur Mars.  Je n’aime pas voir, du code que seul le programmeur qui l’a écrit comprend. Que pour toutes corrections ou modifications, nous avons besoin de lui.

Nous devons toujours écrire, du code pour les 10 programmeurs qui vont faire la maintenance de celui-ci. Il existe encore du code qui a été écrit avec des cartes perforées.

La continuité du désigne est aussi une autre chose importante. Les architectes ou les concepteurs des modèles organiques de l’application. Ne sont pas toujours à côté des programmeurs, lorsqu’ils ont besoins d’ajouter une classe ou une fonction dans cet ensemble.

Dans un mode idéal, je sais que c’est la responsabilité du concepteur de prendre cette décision. Mais, nous savons tous qu’en tant programmeur ou analyste qu’il arrive parfois de prendre cette décision sans l’approbation immédiate du concepteur.

Il faut voir l’intégralité comme une gestion des impacts du code produit dans le reste de l’application ou de la solution logiciel.

Et je me répète, encore et encore, les programmes de tests avec leurs résultats sont aussi importants.

Donc, l’intégralité fonctionnelle et organique d’un code est bien plus que le regarde de la qualité d’écriture du code lui-même. C’est une vue d’ensemble dans la validation du code produit.