Avec l’explosion du monde de l’informatique, de nombreuses personnes sont attirées par le métier de développeur informatique. Nous avons vu l’émergence de multiples formations et MOOCs pour une reconversion rapide au métier de développeur. Bien que cette accessibilité soit souhaitable et permette à tous de se lancer dans cette belle aventure, elle peut être à double tranchant. En effet, être un développeur professionnel ne se résume pas à “pisser du code”, cette pratique qui consiste à pousser des lignes de codes sans trop réfléchir à ce qu’on fait tant que la fonctionnalité demandée est réalisée.

Dans cet article je résume les trois premiers chapitres du livre “The Clean Coder” de Robert C. Martin alias Uncle Bob pour vous transmettre sa vision du professionnalisme dans notre métier.

Prêt(e) à devenir un développeur exemplaire ?

I) Être professionnel lorsqu’on écrit du code

Ne pas endommager le fonctionnement du logiciel

Le but principal d’un développeur est de ne pas créer de bugs lorsqu’il écrit du code. Beaucoup de développeurs pensent que c’est impossible car le code est beaucoup trop complexe et c’est effectivement compliqué de penser à tout. Cependant si on crée un bug (oui ça arrive à tout le monde) et qu’on s’en aperçoit, on en prend pleinement la responsabilité. Uncle Bob va jusqu’à dire que si on fait perdre de l’argent à l’entreprise à cause d’un bug, il faut être prêt à rembourser cet argent.

D’autres pensent que s’il existe un pôle QA (pour Quality Assurance) ce n’est pas pour rien, c’est leur job de détecter les bugs après tout. Grave erreur, le pôle QA est le dernier rempart pour éviter qu’un bug arrive jusqu’en production. Lorsqu’on leur envoie du code, on est 100% convaincu que notre code est propre et certifié sans bugs. C’est pourquoi à chaque découverte de bugs par un membre de l’équipe QA ou un utilisateur, le développeur sera surpris, puis déçu et enfin déterminé à empêcher que cela se reproduise.

Dans ce cas, comment s’assurer qu’un code marche parfaitement ?

Pour cela il faut le tester de très nombreuses fois, même après avoir changé une seule ligne de code. “Mais ça va prendre énormément de temps !” me direz-vous. C’est pourquoi il faut écrire de nombreux tests unitaires et couvrir toutes les parties importantes du code en pensant à tous les cas particuliers. Et si certaines parties du code sont compliquées à tester c’est qu’il y a un problème dans le design du logiciel. Pour être sûr que son code est facile à tester, le mieux est d’écrire les tests en premier : on appelle ça le TDD (pour Test Driven Development).

Ne pas endommager la structure du logiciel

La structure du logiciel est tout aussi importante que ses fonctionnalités. Il est important de noter que lorsqu’un développeur compromet la structure du code, il compromet le futur du logiciel. En fait, tout bon logiciel devrait être modifiable sans surcoût exorbitant.

La meilleure façon de prouver que notre code est facile à modifier est de faire de multiples petites modifications sans relâche. Uncle Bob l’appelle “la règle du Scout” : toujours laisser un module plus propre que lorsqu’on y est entré.

La plupart des développeurs ont peur de modifier des petites parties du code à la volée et de créer des bugs. Les tests sont justement là pour s’assurer que le code fonctionne toujours comme prévu après ces multiples modifications. Ainsi, tel un sculpteur, le développeur peut tailler et modeler continuellement son code sans avoir peur d’y toucher.

II) Être professionnel pour progresser sur ses compétences de développeur

Éthique de travail et apprentissage continu

D’après Uncle Bob, l’employeur n’est pas tenu de former ses développeurs. S’il le fait (par exemple en payant des formations ou en achetant des livres), les développeurs de cette entreprise doivent en être reconnaissants. Pendant les 39 heures de travail hebdomadaire pour lesquelles les développeurs sont payés, ils doivent travailler sur les problèmes de l’employeur. Il faut donc dégager du temps pour se former personnellement et Uncle Bob conseille 20 heures par semaine. Bon, pour ne pas vous décourager, commencez déjà par quelques heures hebdomadaires. Pendant ces heures, il préconise de faire des activités qui renforcent la passion du développeur pour son métier, le but étant de se former de façon ludique. Trouvez la façon d’apprendre qui vous convient le plus et foncez !

Lire des livres, des articles, des blogs, participer à des conférences, échanger avec ses pairs, apprendre des choses en dehors de sa zone de confort (par exemple pratiquer de nouveaux langages) sont autant d’activités qui pourraient vous plaire et vous feront monter en compétence. Le monde du développement informatique étant en perpétuel mouvemenent, il est important de se tenir à jour.

Enseigner à un autre développeur permet aussi d’apprendre énormément, par exemple lors de sessions de pair programming. Cela permet de se rendre compte de ce qu’on a réellement compris.

Connaître les concepts essentiels

Ceux qui ne peuvent se rappeler le passé sont condamnés à le répéter

Uncle Bob considère que tout développeur professionnel devrait connaître :

Même si ces concepts sont relativement anciens, la plupart reste d’actualité et ils sont tous utiles à connaître.

Pratiquer

Une bonne habitude est de faire des exercices de programmation quotidiennement, comme un pianiste fait ses gammes (20 minutes suffisent). Rendez ces exercices ludiques pour vous plongez facilement dedans. On m’a conseillé CodinGame sur lequel vous trouverez des défis autour du code et où vous pourrez défier d’autres développeurs. Lorsque le développpeur code au travail, il ne pratique pas, il performe, de la même façon qu’un sportif s’entraînera régulièrement pour être prêt le jour du championnat.

Connaître les problèmes de ses utilisateurs

Plus le développeur connaît les utilisateurs finaux et leurs problèmes, plus il sera à même de répondre à leurs attentes. Un développeur professionnel prendra du temps pour apprendre à connaître ses utilisateurs et leur métier. Vous pouvez par exemple :

  • répondre aux demandes des clients qui contactent le service support
  • aller sur les salons avec les équipes commerciales pour voir comment ils présentent le logiciel et échanger avec les prospects
  • participer à des clubs utilisateurs et à des réunions de restitution avec les clients

N’hésitez pas à laisser en commentaire d’autres façons d’en apprendre plus sur l’utilisateur final que vous pratiquez dans votre entreprise.

III) Être professionnel dans la gestion des demandes

Dans ce dernier chapitre nous allons voir que le professionnalisme se trouve aussi dans la gestion des sollicitations et demandes auxquelles doit répondre un développeur.

a) Savoir dire Non

Un professionnel doit savoir dire la vérité à son supérieur (ou à son client), même quand c’est pour dire non. Par exemple “Non, nous n’arriverons pas à livrer cette fonctionnalité dans 2 jours”. Il faudra vous munir de courage pour y arriver mais c’est essentiel pour avancer de façon constructive.

Rôles contradictoires

Il faut bien comprendre que les objectifs des chefs de projet ne sont pas les mêmes que ceux des développeurs. Les chefs de projet doivent gérer les contraintes telles que les dates butoires, les budgets humain et financier à allouer ainsi que les relations utilisateurs, alors que les développeurs doivent gérer l’ergonomie des fonctionnalités, la cohérence du logiciel, la maintenabilité du code et sa pérennité dans le temps.

Il vaut mieux savoir dire non au chef de projet quand il demande des choses impossibles à livrer plutôt que de dire “ok je vais essayer” en sachant pertinemment qu’on y arrivera pas. En disant non à la requête initiale et en restant constructif, on arrivera à trouver la meilleure solution pour tout le monde. Il ne faut pas éviter la confrontation à tout prix car elle s’avère positive quand les échanges aboutissent au compromis idéal.

Finalement vous arriverez souvent à un Oui mais pour cela vous serez passés par une ou plusieurs étapes de Non. Ces étapes de Non permettent de donner un maximum d’informations aux décideurs et ainsi de reprioriser et faire des choix éclairés.

b) Savoir dire (de vrais) Oui

Le Oui d’un professionnel est très lourd de sens et a beaucoup de valeur.

S’engager à faire quelque chose comporte 3 étapes :

  1. Dire qu’on va le faire
  2. Le penser vraiment
  3. Le faire vraiment

Très peu de gens, quand ils disent quelque chose, le pensent sincèrement et le font réellement. Il suffit de prendre comme exemple toutes les bonnes résolutions de la nouvelle année ;)

Il existe quelques astuces pour s’assurer qu’une personne qui s’engage sur une tâche le fera vraiment.

Reconnaître le manque d’engagement

Le manque d’engagement peut se repérer par les éléments de langage utilisés :

  • Devoir/Falloir : “Il faut que je perde du poids”, “Il faut que nous le fassions”, “Quelqu’un doit le faire”
  • Espérer/Penser : “Je pense finir ça pour demain”, “J’espère qu’on se reverra”

La liste n’est pas complète mais prenez garde au langage qui est un bon indicateur du réel engagement de votre interlocuteur. Entraînez-vous à remarquer l’emploi de ces termes autour de vous, vous verrez vite que tout le monde les utilise et vous aussi.

Dans ce cas, comment reconnaître un réel engagment ?

Reconnaître le vrai engagement

Quelqu’un qui s’engage réellement va être précis sur la tâche qu’il réalisera et le délai pour la réaliser.
Dire “je vais réaliser cette tâche pour demain” implique un réel engagement. Lorsque vous le dites devant une audience (d’au moins une personne), l’engagement est pris et l’audience pourra vous en tenir rigueur si vous ne vous y tenez pas. Le but étant de s’engager sur des choses dont on a le contrôle à 100%. Quand vous ne savez pas si une tâche est réalisable, engagez vous sur des tâches qui vous rapprochent du but et dont vous êtes 100% sûr de leur faisabilité.

Par exemple, si vous devez corriger les 20 bugs restants avant le deploiement en production mais que vous ne savez pas si c’est réalisable, engagez vous sur des tâches comme :

  • Reproduire ces 20 bugs
  • Récupérer un maximum d’informations pour détailler les bugs
  • S’engager à en corriger un certain nombre d’ici le deploiement

Si quelque chose d’inattendu vous empêche de réaliser votre tâche, il est temps de revoir les objectifs à la baisse et de prévenir le plus tôt possible les personnes envers lesquelles vous vous êtes engagé. Ainsi l’équipe pourra se réorganiser au plus vite et changer ses priorités.

S’entraîner à utiliser un langage engageant (bien qu’effrayant) est une bonne chose pour limiter les erreurs de communication et permet de mieux s’organiser. Quand un professionnel dit “Oui”, il le dit avec assurance et il n’y a aucun doute ce sur quoi il s’engage.

Être professionnel n’implique pas de dire “Oui” à tout ce qu’on nous demande. Cependant un professionnel fera tout ce qu’il peut pour rendre ce “Oui” possible.

Et après ?

À travers ces 3 premiers chapitres nous avons vu ce que signifie être professionnel dans son métier de développeur selon Robert C. Martin. Il met l’accent sur la philosophie du bon codeur, l’apprentissage continu et le comportement humain. Je vous invite à appliquer ces idées dans votre quotidien, vous constaterez des effets spectaculaires !

Je résumerai dans un futur article les derniers chapitres du livre où Robert C. Martin détaille les bonnes pratiques lorsque l’on code et aborde les sujets de la gestion du temps et de la pression. D’autres livres parlent du professionnalisme chez les développeurs. On m’a conseillé le très bon The Pragmatic Programmer que je vais me faire une joie de lire.

Et vous, quel livre vous a le plus marqué dans votre carrière de développeur ? Et quel conseil vous a le plus aidé pour vous professionnaliser ?