Archives mensuelles : novembre 2014

Métaphores

Un petit tour des métaphores utilisées pour la construction de logiciels.

Recette de cuisine

Une bonne métaphore pour expliquer la programmation impérative. Une recette de cuisine est une suite d’instructions, plus ou moins abstraites, avec un jargon (« faites revenir les oignons », « montez les blancs, … »), qui permet à la fin d’obtenir un résultat. Le cuisinier jouant ici le rôle de la machine exécutant le programme.

Cette métaphore explique plus ce qu’est un programme que ce que c’est de programmer. Elle ne représente aussi qu’un seul paradigme : la programmation impérative, pas la programmation fonctionnelle ou logique.

Construction

Cette métaphore a été très utilisée, comme le montre les titres d’architecte, MOE et MOA que nous utilisons encore.

Elle a aussi fait beaucoup de mal, parce qu’assez peu pertinente au final.

Pour un bâtiment, disons un pont, on dessine des plans. Une fois les plans dessinés, et surtout les travaux commencés, le projet est figé, il est impossible de changer quoi que ce soir sans tout casser. Modifier le pont équivaut à démolir un pont et à en reconstruire un autre, coût qui est en général inacceptable.

Les logiciels n’ont pas cette contrainte, il s’agit de texte, le coût du changement est proportionnel au changement demandé.

De plus dans le cas d’un bâtiment, le client choisit un projet à partir d’un beau dessin ou d’une maquette, puis fait confiance à l’entrepreneur. La maquette est tout à fait suffisante pour imaginer le résultat final, et peu d’ajustements sont possibles. Dans le cas d’un logiciel, on sait depuis longtemps que le besoin initial est quasi toujours flou et qu’on a besoin du feedback du client tout au long du projet.

On peut comprendre que pour les premiers projets d’envergure, les protagonistes ait cherché à s’accrocher à des méthodes d’organisation existantes dans d’autres corps de métiers. Comme on connait de mieux en mieux maintenant les spécificités du notre, le vocabulaire devrait se renouveler.

Jardin

On compare le produit logiciel à un jardin (plutôt un potager ou un verger) dont il faut s’occuper. Si on n’arrache pas les mauvaises herbes, qu’on ne chasse pas les parasites, le jardin va se détériorer et deviendra moins productif.

Cette comparaison est assez mignonne, et explique pas trop mal pourquoi on passe tant de temps à « ranger », renommer des trucs, rassembler ou découper des fichiers, etc…

Un défaut cependant : c’est le code source qu’il faut entretenir pour éviter qu’il se ne détériore, et c’est le logiciel déployé qui produit de la valeur. Un snapshot pas trop beugué peut produire de la valeur pendant des années sans que personne ne change quoi que soit au code source.

Artisanat

On logiciel est comparé à un produit de l’artisanat, comme un violon sculpté à la main.

Au niveau de la création du produit, celle-ci a presque les même défaut que la métaphore du bâtiment : nécessité d’avoir une bonne idée du produit final au départ et impossibilité de modifier le résultat final.

C’est pour la vision du métier que cette comparaison est intéressante : on parle d’un professionnel qualifié et respecté par son commanditaire qui façonne une quasi-oeuvre d’art.

Livre ou symphonie

On compare l’écriture d’un logiciel à l’écriture d’un roman ou d’une symphonie.

Cette comparaison rend bien le coté créatif de la programmation, ainsi que le coût du changement : celui-ci est toujours possible, et son coût est directement proportionnel à son importance. Il est possible de changer rapidement des choses peu importantes, il est plus long de faire des gros changement, comme modifier la personnalité d’un personnage, mais ça reste possible.

En revanche le romancier ou le compositeur (même pour les histoires sur commande ou les musiques de film) a moins de contraintes, techniques, fonctionnelles, contextuelles.  Et il travaille en général seul, pas au sein d’une équipe potentiellement très hétérogène.

Dette technique

On compare le coût du manque de qualité du code source à une dette financière.

On a deux types de dette technique : une dette délibérée, où on a choisi de ne pas implémenter comme il faut pour livrer plus vite, ou une dette issue d’un manque de discipline. Fowler en parle mieux que moi.

Le gros problème de cette comparaison, c’est que la dette financière n’a aucun impact sur la productivité d’une entreprise. Si une entreprise empreinte un million d’euros, cela ne change rien au quotidien de ses employés, cela n’affecte pas leur travail. Et même comme souvent les entreprises s’endettent pour acquérir des outils de production, celle-ci a plutôt un impact positif. Amazon par exemple n’a jamais été bénéficiaire et est très endetté, personne ne dira pourtant que cette entreprise est en mauvaise santé.

La dette technique en revanche modifie la vélocité : on doit comprendre le code illisible et non testé pour le modifier, le corriger ou tourner autour.

 

Attitude et éthique du développeur.

Après pas mal d’années dans le service, pour différents clients, différents projets et dans différents contextes, après maintes lectures de livres et d’articles, je me suis forgé intérieurement une idée de l’attitude à avoir dans le métier, et l’envie m’est venue mettre cela par écrit et de partager.

Je me reconnais beaucoup dans l’idée derrière le software craftsmanship que nous sommes des artisans, taillant avec nos mains de beaux produits, responsables de leurs qualité, réfléchissant sur notre travail.

J’ai aussi beaucoup d’atomes crochus avec l’agilité.  En XP en particulier, on liste cinq valeurs : communication, feedback, simplicité, courage, respect. On verra qu’on peut les retrouver dans la suite de l’article .

Produire du logiciel

Se focaliser sur le projet

Le but d’un professionnel devrait d’abord être le bien de son projet. C’est pour faire avancer leurs projets que nos clients nous appellent, que nous nous levons tôt et faisons trois quart d’heure de trajet en métro tous les matins.

Il faut s’intéresser au projet : pourquoi a-t-il été lancé, pour quel besoin ? Quel est le planning ? Est-on dans les temps ? Dans quel état de qualité est-il ? Comment peut-on améliorer les choses ? Comment les tâches sont-elles gérées ? Est-ce efficace ?

Ca peut paraître évident mais j’ai vu souvent des gens s’intéresser assez peu à ces questions, le pensant sans soute géré par d’autres. Pour moi il est difficile de faire du bon travail en regardant que des détails épars (le ticket du moment par exemple) .

Etre productif

Good enginners ship
— Tracy Kidder

Produire, cela signifie en premier lieu être productif : il faut implémenter des fonctionnalités, corriger des problèmes, fermer des tickets, des stories, déplacer des post-it (avec une qualité raisonnable bien sur, j’y reviendrais).

Beaucoup de développeurs sont contents quand ils ont passé du temps à intégrer un nouvel outil ou qu’ils ont réalisé quelque chose de compliqué ou tape à l’œil. De mon coté, ma satisfaction est corrélée au nombre de tâches que j’ai terminées. A la valeur produite pour le client. J’ai toujours une todo list et une done list.

La référence en matière de productivité est le livre Getting things done que je conseille à tout le monde, quel que soit sa fiche de poste.

Simplicité : être pragmatique

La simplicité est la sophistication ultime.
— Léonard de Vinci

Mettre en avant la production de valeur pour le client plutôt que l’accomplissement technique amène à éviter certaines dérives courantes comme l’over engineering.  On aura aussi moins tendance à se perdre des heures ou des jours dans une tâche technique. Le pragmatisme et la simplicité sont depuis longtemps des principes encouragés (voir par exemple les YAGNI et KISS)  mais pas toujours bien assimilés ni appliqués.

the_general_problem

Un exemple de manque de pragmatisme : j’ai déjà vu sur un projet, les intégrateurs faire toute l’intégration d’un site avec flexbox, puis passer des jours à tout refaire dans une autre feuille de style pour IE, alors qu’il était établi dès le départ que IE8 était dans la cible. Ils avaient envie d’utiliser flexbox, ce qui est compréhensible, mais dans ce contexte c’était une perte de temps pour tout le monde. La bonne technique aurait du être de faire une version correcte sur IE8, avec les techniques utilisables (ça ne manque pas), et d’ajouter ensuite les beaux dégradés, ombres, etc… que permet CSS3.

CV Driven Development : ce n’est pas un but dans un projet d’avoir le plus d’outils possible. La taille du package.json ou du pom.xml ne rend pas le projet plus intéressant. Chaque dépendance ajoute de la complexité, et doit être bien réfléchie.

Respect : il y a toujours un contexte, une histoire, des contraintes

Il y a toujours ou presque un contexte dans lequel on travaille. D’autres systèmes avec lesquels interagir, pas forcément pratiques (« quoi du SOAP ? »), parfois vraiment anciens (« ce vieux système mainframe est vraiment bizarre est limité »). Il faut faire avec. Dans un SI de taille significative, il est impossible que tout soit toujours flambant neuf, implémenté avec la dernière technologie à la mode. Un DSI ne va pas refaire en Scala ou en Java 8 son mainframe qui est le cœur du business de la boite et qui a pris des années à être implémenté. Ce serait couteux, dangereux et peu utile.

La bonne attitude n’est pas de râler ou de troller mais de réfléchir et de proposer des solutions, par exemple une couche de médiation pour transformer du SOAP mal formaté en JSON mignon.

Respect : Respecter la productivité des autres

interruptVous trouvez ça pénible quand quelqu’un vous interromps en pleine réflexion pour poser une question ou ajouter une petite tâche ? Ne le faites pas subir aux autres.

S’il n’y pas d’urgence, pas de raison d’interrompre la personne en lui parlant ou en lui téléphonant ; soyez asynchrone : envoyez un mail ou un message chat (Skype, ou autre, si votre équipe l’utilise). Groupez aussi les questions, attendez d’en avoir plusieurs c’est plus efficace pour tout le monde.

De même, déléguer prend du temps : il faut expliquer la tâche et vérifier son exécution. Si la tâche ne prend que quelques minutes il est contre productif de la déléguer. J’ai eu une fois un manager qui m’a à plusieurs reprise demandé d’éditer une page wiki (à l’oral, donc en coupant ma tâche en cours), alors qu’il aurait pu faire modifications lui même en quelques dizaines de secondes.

Courage : être présent en cas de crise

Les problèmes, ça arrive. Découvrir un bug bloquant en prod, voir passer un commit qui casse tout la veille d’une démo importante, … Il peut y avoir plein de situations d’urgence, de crise, et dans ces cas là il faut être prêt à offrir son aide, à réparer ce qui est cassé, que cela soit de notre faute, ou non. 

Le produire bien

En tant que professionnel, on doit non seulement produire un logiciel, mais aussi un logiciel de qualité.

Respect : être lisible

Un code ou une architecture très complexe demande une certaine forme d’intelligence pour être mis en place, mais la personne qui vous relire et essayer de vous comprendre va vous hair. Vous lui ferez perdre son temps, et par conséquent le temps et l’argent du client. Comme le relève Sandro Mancuso, écrire quelque chose de cryptique est un manque de respect pour les personnes qui vous relit.

Exemple : que fait ce code ?

1
2
3
4
5
var total = (Math.max(0, Math.min(base, 11991) - 6011)) * 0.055
+ (Math.max(0, Math.min(base, 26631) - 11991)) * 0.14
+ (Math.max(0, Math.min(base, 71397) - 26631)) * 0.3
+ (Math.max(0, Math.min(base, 151200) - 71397)) * 0.41
+ Math.max(0, base - 151200) * 0.45;

Pas évident hein ? La version ci dessous est plus verbeuse mais plus claire (peut-être perfectible mais ce n’est pas le sujet) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
function calculImpotSurLeRevenu(revenu) {
var tranches = [
{ "seuil" : 0, "plafond" : 6011, "taux" : 0.0 },
{ "seuil" : 6011, "plafond" : 11991, "taux" : 0.055 },
{ "seuil" : 11991, "plafond" : 26631, "taux" : 0.14 },
{ "seuil" : 26631, "plafond" : 71397, "taux" : 0.3 },
{ "seuil" : 71397, "plafond" : 151200, "taux" : 0.41 },
{ "seuil" : 151200, "plafond" : null, "taux" : 0.45 }
];

var impotSurLeRevenu = tranches
.map(impotParTranche)
.reduce(function (tranche1, tranche2) { return tranche1 + tranche2}, 0);

return impotSurLeRevenu;
}

function impotParTranche(tranche) {
if (revenu < tranche.seuil) {
return 0;
}
var borneMax = revenu;
if (tranche.plafond !== null) {
borneMax = Math.min(revenu, tranche.plafond);
}
var imposablePourLaTranche = borneMax - tranche.seuil;
return imposablePourLaTranche * tranche.taux;
}

Simplicité (humilité) : tester, tester, tester !

In God we trust, Everything else we test. –

Je ne m’attarde pas c’est la base : écrire des tests automatique et toujours tester en vrai avant commiter. C’est la seule façon d’être confiant que ça marche.

Courage et humilité : accueillir le feedback, même négatif

(et paf trois valeurs dans le même sous titre!)

Analyse statique, code review, recette, dialogue avec le métier, démos ratées, remarques des autres collaborateurs… Il y a plein de sources de feedback sur notre travail, qui souvent lèvent des problèmes et amènent des corrections et améliorations possibles; donc du travail. C’est positif! C’est bon pour le projet! Accueillons le avec plaisir et améliorons notre produit.

Courage : il n’y pas de fatalité sur la qualité

We are what we repeatedly do. Excellence, then, is not an act, but a habit.
— Aristotle

Quel que soit le niveau de qualité d’un logiciel, il n’y a pas de fatalité, on peut toujours améliorer les choses, petit à petit. La règle du boy scout est emblématique à ce niveau : toujours laisser les choses plus propre qu’on les a trouvées, rendre le monde meilleur. C’est aussi une marque de respect pour les suivants :-).

Relations avec les collaborateurs

Communication : être pédagogue et empathique avec les collaborateurs peu techniques

usersTout le monde ne connait pas les difficultés de CSS, les niveaux d’isolation des transactions ou la différence entre SOAP et JSON. Il faut savoir se placer à un plus haut niveau, et comprendre les questions et problématiques des collaborateurs, au delà de leurs implications techniques (en général, qu’est-ce qui est faisable, à quel coût). S’il y a vraiment besoin, on peut recourir à des métaphores pour expliquer certains problèmes.  Ne parler que technique, même avec des gens dont ce n’est pas le métier et que cela intéresse peu laisse une image de geek perdu dans son monde, qui s’intéresse peu à la finalité du projet ou de l’entreprise.

Respect : pas de bashing des autres pour leur niveau ou leur poste

Tout le monde n’a pas le même niveau, la même motivation à apprendre, à faire de la veille. On peut aussi oublier des choses si on n’y a pas été confronté depuis longtemps. La bonne attitude : répondre aux questions, expliquer, encourager la curiosité et l’apprentissage.

Respect : pas de troll sur les technologies

Chaque technologie a sa philosophie, ses points forts, ses points faibles. Cela implique des choix techniques (ex : je travaille surtout en Java et Javascript et pourtant j’utilise wordpress, donc PHP) à faire.

Il n’y a par contre aucun intérêt à troller des heures sur la verbosité de Java ou la lenteur de Ruby. Cela peut susciter des séparations inutiles entre des équipes et des gens qui par ailleurs pourraient très bien s’entendre.