Archives mensuelles : décembre 2013

Le bon nommage dans la programmation, un vecteur d’agilité

Un bon nommage dans un code permet une meilleur lisibilité du code facilitant son test, sa modification et son évolution sans recourir à une documentation exhaustive. Les équipes peuvent alors concentrer leurs efforts sur la production de fonctionnalités plutôt que de documentation: Working software over comprehensive documentation.

Intérêts du bon nommage

Si vous codez en Java il vous est certainement déjà arrivé de commencer à taper « au hasard » un nom de classe ou de méthode dont vous n’êtes pas certain de l’existence, l’assistance à la saisie de votre IDE aidant et une excellente convention de nommage qu’est celle de l’API java permet souvent de trouver la classe ou la méthode dont vous avez besoin sans ouvrir la documentation.

Outre l’utilisablité quand vous développez une librairie, un bon nommage rends le code facilement lisible et donc facile à valider et corriger.

Entre ce code:

int debit(int m) throws Exception {
    int a=solde-m;
    if(a < 0) update(-m);
    else throw new SoldeException();
    return a;
}

et celui ci:

int debiterCompte(int montantADebiter) {
    int soldeRestant=soldeCourrant - montantADebiter;
    if(soldeRestant < 0) mettreAJourSolde(-montantADebiter);
    else throw new ExceptionSoldeInsuffisant();
    return soldeRestant;
}

Il est plus facile de valider et déboguer le code dans le second exemple que dans le premier. Et l’erreur de comparaison du solde dans le deuxième cas se déclare par elle même à la relecture du code.

En effet, un bon nommage permet de lire le code comme si on lisait un texte est donc utiliser les capacités logiques de la vie courante pour valider le code.

Un vecteur d’agilité

Le deuxième principe de l’Agile Manifesto édicte

Working software over comprehensive documentation

Or la capacité de réduire la documentation sans faire courir de risque au projet dépend fortement de la lisibilité du code. Un bon nommage favorise cette lisibilité.

Cela est en lien avec une pratique du lean qu’st le Management Visuel

Le Management visuel est l’une des techniques lean conçue de telle sorte que toute personne entrant dans un atelier, même ceux qui
sont pas familiers avec le détail des processus, peuvent voir très rapidement ce qui se passe, comprendre et voir ce qui
est sous contrôle et ce qui ne l’est pas. (source)

Dans ce sens, un code lisible en soit favorise l’efficacité et améliore la quailité. En effet, un nouveau développeur arrivant sur un code lisible n’a pas besoin de documentation exhaustive pour le prendre en main et peut directement concentrer ses effort sur la valeur ajoutée à apporter au Product Owner.

Une documentation dit ce que fait le code, un code lisible dit ce qu’il fait mais aussi comment il le fait, cela encourrage alors le développeur, au besoin à améliorer améliorer le code quand l’opportunité se présente.

Syndrôme de la page blanche

Comme un écrivains on a face à l’écran un syndrome de la feuille blanche, syndrome qui pousse souvent à adopter des règles de nommage techniques ou sans aucun sens. Ainsi, j’ai eu dans mon équipe un développeur qui nommait les variables avec des combinaisons de ses initiales. Cela faisait en exagérant un peu quelque chose comme :

int jpl = 3;
int plj = 10;
if((plj-jpl)>23) doSomeThing(jpl);
....

Pour stimuler la créativité, dans la suite de l’artice je vais donner quelques tuyaux pour bien nommer les variables.

Quelques tuyaux pour trouver des idées pertinentes des noms de variables.

Chapter 1. Nommer une variable selon ce qu’on doit en faire

Comme par exemple {{{itemsToRemove}}} ici :

ArrayList itemsToRemove = new ArrayList();
for(MyType elem : myCollection) {
    if(elem.needsRemoval()) 
        itemsToRemove.add(elem);
}
myCollection.removeAll(itemsToRemove);

Cette approche est souvent plus pertinente pour les variables plutôt locales et éphémères qui ne sont utilisées que pour une tache précise dans l’algorithme.

Chapter 2. Nommer selon la nature de ce qu’elle contient

Comme unsold items dans :

ArrayList unsoldItems = getUnsoldItems();
for(Item item : unsoldItems) {
    item.setAsAvailableForSale();
}
...
warehouse.markAsAvailable(unsoldItems);
...
for(Item item : unsoldItems)
    paymentProvider.refund(item.getCustomerId(), item.getPrice());

Cette approche est souvent très pertinente et donne une lisibilité exceptionnelle au code.
Elle nécessite cependant de trouver une façon judicieuse pour décrire le contenu de la variable en peu de mots:

//Unsold items including new items returned by the user after delivery but not used ones.
ArrayList unsoldItems = ...

et non pas

ArrayList unsoldAndReturnedItemsButNotReturnedOnes = ...

En effet, une caractérisitique du bon nom est qu’il puisse être retenu par le lecteur, il se doit donc d’être succinct. Et de ce fait, 2 ou 3 mots sont un max.

Chapter 3. Nommage des booleans

La meilleure approche est de les nommer par en une affirmation logique qui est vraie quand la valeur du boolean est true. Ainsi, à comparer ces deux codes :

if(availibity && price) return false;

on comprends moins le sens que dans

if(itemIsAvailable && priceIsValid) return false;

cette approche permet de faire en sorte que les assertions logiques, même longues soient « vérifiables »

if(basketIsNotEmpty && (userHasPaymentInfo || basketIsAGift || !productIsPrivate)) allowDelivery();

Quelques pièges et solutions

  1. Les noms trop longs : Quand il est absolument nécessaire de manipuler des notions dont le nom est trops long, une technique est d’utiliser un acronyme ou les initiales avec une définition dans un commentaire, mais c’est une technique à éviter et il est préférable de chercher des noms courts.
    //PSP : Payment Service Provider
    Operator selectedPSP = getSelection().geProvider();
    
  2. Remettre le nom de la classe dans le nom de ses attributs. C’est une pratique à rejeter complètement, sauf dans d’extrêmement rares cas, cette approche ne fait que rallonger le texte sans apporter d’information du genre {{{ Product.price }}} n’a rien qui manque par rapport à {{{ Product.productPrice }}}. D’autant plus que dans le nommage des instances, la pratique de mettre le nom de la classe (ou de préférence une de ses spécialisation) est bonne :
    Product selectedProduct; //Bonne pratique
    

En conclusion

La rédaction d’un code lisible avec un bon nommage est un art. On peut souvent négliger le fait qu’il faut « coder pour être lu » non seulement par la machine, mais par soit même ou un autre qui dans plusieurs mois ou années aura affaire au code pour le corriger ou le faire évoluer. Quoi qu’on en dise, barder un code de commentaire ou l’accompagner de documentation est une technique beaucoup moins efficace et introduit de la rigidité et de la non-valeur dans le projet.

La mobilité, le cloud, le big data : la révolution du SI est pour tout de suite.

Les ruptures technologiques peuvent impacter de façon importante le système d ‘d’information et son rôle stratégique dans l’entreprise. De la même façon que la démocratisation du PC qui a sorti l’informatique des centres de calcul a permis au SI de devenir un élément stratégique de la performance des métiers, divers experts prévoient une nouvelle révolution du SI à l’horizon 5 à 10 ans.

Une révolution complexe

Cette fois-ci il ne s ‘agit pas d ‘une technologie mais de la convergence de plusieurs tendances. Identifiées par IDC sous le nom de la 3ème plateforme et par Gartner sous le nom du Nexus of Forces, cette convergence concerne :

  • Le cloud en tant que possibilité nouvelle offerte directement aux directions métier de se fournir en services au delà des catalogues de la DSI. Plus en phase avec le rythme effréné des nouvelles technologies et facilement pris en main par la nouvelle génération de salariés, les services cloud mettent à mal la DSI qui doit sortir du rôle de mise à disposition d’application métier internes vers la mise en oeuvre maîtrisée d’un SI forcément ouvert vers le cloud.
  • La mobilité comme une fenêtre vers le cloud dans la poche des clients, des fournisseurs ou des salariés. Un véritable vecteur de performance des métiers et de relation client, la mobilité est aussi un challenge en terme de sécurité et d ‘interopérabilité.
  • Les médias sociaux comme une nouvelle façon pour les salariés de collaborer et une nouvelle façon pour l’entreprise d ‘interagir avec ses clients et partenaires, les médias sociaux permettent aussi de comprendre, mesurer et rester en phase avec les évolutions rapides de la société.
  • L’internet des objets et le BigData comme promesse, non seulement de disposer de données plus abondantes et plus précises sur l ‘entreprise et son environnement, mais aussi de pouvoir les analyser et les visualiser pour en extraire une information pertinente.

A l’entreprise de se préparer

Autant les éditeurs que les entreprises utilisatrices doivent intégrer dans leur feuille de route la préparation à cette révolution. Si bien que l’IDC rajoute à cette recommandation pour les éditeur « quit à cannibaliser leurs marché actuel », car de leur point de vue c’est une réelle redéfinition du paysage ou toutes les places sont remises en jeu, même celles des leaders.
De son côté l’Open Group a lancé le Forum Plateform 3.0 dont le but est de définir des standards et pratiques permettant aux entreprises de bien négocier ce virage. Ainsi, pour l’Open Group l’entreprise de demain doit se doter de Capacités nouvelles, dont :

  • Traiter des données dans le cloud en maîtrisant tous les aspects (réglementaire, sécurité …).
  • Intégrer des données de diverses sources y compris celles issues d’objets communicants ou des médias sociaux.
  • Gérer, partager et distribuer un gros volume de données.
  • Extraire et exploiter l’information utile depuis ces données.

Cela nécessite bien entendu de la préparation en amont et une réelle mutation de la façon de concevoir le rôle de la DSI et l’Architecture du SI, d’autant plus que le travail d’identification des fonctions nécessaires pour supporter ces capacités sont à définir et les briques techniques à même de fournir ces fonctions sont encore en maturation.