Compte-rendu de la soirée SONAR

Le métier de développeur

La première partie est donc une réflexion sur le jeune métier de « développeur » (analyste, développeur, concepteur, architecte, intégrateur …)
Existe-t-il un problème culturel et d’imaginaire collectif spécifiquement Français ?
Il est certain que dix ans en arrière, le “métier” a connu une vague d’autodidactes avec des résultats plus ou moins heureux. Freddy Mallet estime que sa formation la plus utile reste son BAFA. Il est certain que les capacités de communication sont extrêmement importantes, surtout avec les méthodes agiles. Mais du coup l’image de l’informaticien en a pris un coup (ainsi que sa place dans les grilles de salaire). Même dans la salle, pourtant des profils plutôt technique, seul un dixième se voit finir sa carrière dans le développement (les autres savent qu’ils seront statistiquement au chômage).

Le phénomène existe-t-il dans d’autres métiers? Ou le développeur est-il en plus paranoïaque ? Il faut se méfier des comparaisons. Bien sur, un chef de rayon dans la grande distribution est aussi fortement poussé à évoluer. Mais l’artisan qui n’a pas évolué est-il un raté ?  Au final, comparez-vous le métier de développeur à « Caissier », “professeur des écoles”, « Chef de rayon », “Artisan”, « Comptable », « Médecin » ou “Musicien” ?

Revenons quelques années en arrière. Énumérons les syndromes classiques du développeur “Héros” (“c’est MON code”, peur du changement …). Enfin, soulignons une tendance forte des 10 dernières années: l’industrialisation. Attention, pas au sens “off-shore” dans des pays à bas coût de main d’oeuvre, mais au sens SCM, Intégration continue, traçabilité (SCM + Tickets).
Bref, on sent bien une évolution, mais vers quoi ???

• ReUse ⇨ Integration
• ReDuce ⇨Refactoring
• ReCycle ⇨ Maintenance

Les coûts de maintenance auraient-ils poussé l’industrialisation ? Ou les développeurs ont-ils créés et imposés leur propres outils ?

Visiblement l’industrialisation ne s’est pas faite sur les anciens piliers du Waterfall: Documentation + Modélisation + Planification. Peut être n’accordaient-ils pas assez d’importance au code source ? L’industrialisation a eu lieux bottom-up, elle concerne le code source et le développeur n’est plus relégué en bout de chaîne, mais directement en lien avec l’utilisateur final. (Une note quand même pour dire que modélisation et DSL commencent à revenir sous une forme liée au code et en phase avec l’agilité, mais c’est un autre débat.)

Aujourd’hui, le développeur ne devrait plus être un “lonesome cowboy” qui va remplir sa mission dans la jungle inextricable du code. Il devrait travailler avec les autres et même pour les autres. En effet, on n’écrit pas du code pour le compilateur, mais pour les autres développeurs ! A ce sujet voir Clean Code: Handbook Software Craftsmanshift (by Robert C. Martin): livre dédié à l’expressivité du code source.
Freddy n’hésite pas à dire qu’il faut même s’interdire de faire des choses trop compliquées par rapport au niveau de l’équipe. Comme toujours, il faut garder un équilibre et ne pas toujours niveler par le bas !

Un aparté sur les rythmes de développement. L’intégration continue & agilité permettent de  lisser le rythme de développement grâce aux tests unitaires. Ça évite les rythmes en dents de scies, où on reste des journées à chercher un bug après avoir progressé très vite.

La maturité s’acquiert par étapes (inutile de vouloir faire de l’intégration continue sans maîtriser le SCM par exemple):

1. SCM
2. Ticket
3. Intégration continue
4. Inspection continue = SONAR

Attention aux excès de l’agilité: manque de vigilance sur le long terme. Pour garder une capacité à l’agilité, il ne faut pas accumuler trop de dette technique sans s’en rendre compte. Ça rejoint un peu le problème des exigences non-fonctionnelle en Agilité : SONAR n’est qu’un outil. Il faut une gouvernance.
Freddy aimerait bien s’intégrer dans le processus agile, pour cela il défend le fait qu’une fonctionnalité n’est terminée (Done) que lorsqu’elle est :

1. Développée
2. Testée
3. Approuvée par le “product owner”
4. Tout ça avec une dette technique maîtrisé (par SONAR)

En conclusion, bien des maux et des dérives observés proviennent du manque de transparence du code source. Le développement même du code source s’apparente pour beaucoup à de la magie laissé aux gourous ou à des missions périlleuses laissées à des mercenaires. Après 15 ans d’agilité, on commence à maîtriser les fonctionnalités des applications et obtenir une traçabilité. La prochaine étape consiste à ouvrir la boite de pandore, à apporter de la transparence au niveau du code source. Êtes-vous prêt à travailler au grand jour ? Les outils sont là, nous avons rencontré Freddy Mallet.
Il ne reste plus que la volonté de s’en servir d’en parler à votre DSI: http://www.sonarsource.org/

L’outil SONAR

La seconde partie est donc une démonstration du produit Open Source: SONAR.
Immédiatement l’indicateur global en $ saute aux yeux (surtout pour un DSI) et permet de savoir où on va:

• l’évolution de votre projet à travers le temps. Votre projet s’améliore ou empire ??
• La comparaison avec d’autres projets. Même si vous n’avez qu’un projet SONAR vous montre l’état d’un large panel de projets http://nemo.sonarsource.org/

On survole plusieurs métriques. Visiblement, c’est une science à part entière qu’a appris à maîtriser SONAR. Un support est disponible si votre responsable qualité veut monter en compétence.
La force du portail Sonar ? Lorsqu’on clique sur une métrique (et on peut cliquer partout !) on atterrit systématiquement sur du code ”améliorable”.
La principale évolution de Sonar dès les prochains mois sera d’ailleurs l’intégration de l’outil aux IDE pour lier graphiquement les métriques relevées au code source éditable.

Lors des questions/réponses, un participant a évoqué un besoin récurrent chez les utilisateurs de Sonar, qui consiste à pouvoir fusionner toutes les données qualitative d’un projet sur l’outil.
En effet, les métriques actuellement agrégées par Sonar concernent le code source et se rapporte obligatoirement au code source (c’est d’ailleurs un souhait de sonarsource). Cependant lorsque l’on gère des métriques “runtime” (performances de l’application par exemple), ces métriques ne peuvent plus être intégrées à Sonar.
Freddy Mallet a répondu à cette question en soulignant la différence d’approche entre Sonar orienté code-source  et des métriques “runtime” qui ne peuvent être facilement liées à du code (paquetages, classes, méthodes).
On suivra avec attention les évolutions de Sonar et surtout son adoption !