soccer dropping odds footballdroppingodds.com dropping odds movements

Ecrire un code, un travail rédactionnel comme un autre

Ecrire un code, un travail rédactionnel comme un autre

DéveloppeurEcrire du code serait donc un travail rédactionnel « comme les autres » ?

Dans une ancienne publication (2010), je mettais l’accent sur la nécessité d’utiliser « les mots justes » pour se faire comprendre (« évitez une crise en parlant juste »).
Je viens dernièrement d’avoir l’occasion de lire un blog parlant de Bonnes Pratiques chez les Programmeurs et découvrir que, bien que souvent considérées comme des personnes cantonnées à l’utilisation de leur jargon, les programmeurs avaient bien conscience de l’utilité de parler « clairement » entre-eux pour un échange d’informations pertinent.

Je vous propose de découvrir ce que nous dit sur le sujet Fabien Maury, auteur du blog sus-évoqué, qui a aimablement accepté que son texte soit publié sur ce site.

BONNES PRATIQUE DE DEV, PROGRAMMATION
Ecrire du code, un travail rédactionnel comme un autre

Le développement logiciel, qui pourtant n’en est pas à sa première décennie d’existence, n’en demeure pas moins une discipline jeune, et on sent que c’est un monde qui se cherche; Beaucoup de débats ouverts, et de nombreuses métaphores pour s’assimiler à des métiers existants de plus longue date: comparaison avec la construction d’un bâtiment, industrialisation du cycle de vie du logiciel, assimilation à la catégorie des artisans (mouvement Software Craftsmanship), etc.
En ce qui me concerne, je considère de plus en plus qu’un des aspects non négligeable de notre métier est la rédaction. Bon nombre de personnes rédigent des documents: que ce soit l’écriture d’un livre, ou plus proche de nous de la documentation, des spécifications, des contrats, etc.
De même nous « écrivons » toute la journée, certes dans un style très technique, en langage principalement destiné à la machine, mais certains traits d’exigence du travail rédactionnel s’y retrouvent:

Être intelligible
En effet, votre code va être lu par d’autres développeurs, qui voudront le corriger, l’améliorer ou le faire évoluer et pour cela ils devront comprendre ce que vous avez voulu faire.
De la même façon qu’il sera laborieux et fatiguant de lire un livre ou une spécification écrit en langage ‘petites annonces’ (jh ch. apt prox. com. av balc), il sera préférable d’avoir du code compréhensible.

Il faudra donc éviter ce style :

public long calcProf(double pa,double t,double pv,double t2) {
return (pv/(1+t))-(pa/(1+t2));
}

Au profit de celui-ci :

public long calculDuProfit(PrixTTC prixAchat,TVA tvaAchat,PrixTTC prixVente,TVA tvaVente) {
PrixHT prixAchatHT = tvaAchat.reduceFrom(prixAchat);
PrixHT prixVenteHT = tvaVente.reduceFrom(prixVente);
return prixVenteHT.moins(prixAchatHT);
}

Cohérence globale
Imaginez maintenant que vous écrivez un livre à plusieurs: on vous fait le résumé de l’histoire, chacun prend un chapitre et c’est parti !
Si vous ne communiquez pas, vous risquez d’obtenir de multiples fois le récit de l’attaque du dragon écrit avec des nuances mais aucun passage n’expliquant comment les héros sont arrivés là….et si vous ne vous êtes pas mis d’accord sur un style commun, le rendu sera perturbant à lire.
Pour le développement c’est pareil ! Il faut une cohérence globale en terme d’architecture de code et de style, afin qu’il soit possible de trouver facilement ce que l’on cherche une fois que l’on connaît un minimum l’application. En résumé: parlez vous. Une équipe qui ne communique pas court à sa perte.
(Ce parallèle est un peu capillotracté…mais je reste persuadé que le fond fait sens)

Relecture
Je ne pense pas qu’un seul travail de rédaction soit envoyé pour livraison sans relecture (à part le développement logiciel … qui est, lui, rarement relu).
Aucune maison d’édition n’enverrait un livre à l’imprimerie sans relecture juste pour ne pas froisser l’ego de l’auteur. La plus grande barrière a la relecture du code reste, je pense, un problème de fierté, la relecture s’apparentant à du flicage. Rappelons qu’il n’est pas obligatoire que la relecture se fasse par un supérieur hiérarchique; cela peut se faire entre pairs et dans un bon état d’esprit.

La relecture de code c’est:
– un pas de plus vers la propriété collective du code
– un bon moyen de partager la connaissance
– un avis extérieur sur son code

Pensez-y
Un code difficile à lire provoque une perte de temps, une fatigue intellectuelle et devient source d’erreur.
La compréhension d’un code vient aussi du suivi collectif qui en a été fait via le partage de connaissances et le dialogue au sein de l’équipe.
Donc lorsque vous développez, pensez à la prochaine personne qui va venir lire votre code, et essayez de lui donner un coup de pouce.
Si vous ne le faites pas pour lui, faites-le pour vous, car il y a de grandes chances que le prochain lecteur de ce code soit le vous du futur.

Blog Arolla
Les douze travaux d’Arolla
by Maury Fabien • 12 novembre 2014

0 Avis

Laisser une réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*