Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

« Le glas sonne pour les environnements d'essais traditionnels | Page d'accueil | L'équipe décide de la solution »

07 juillet 2010

Êtes-vous un développeur professionnel?

Le titre du keynote de Robert "unclebob" Martin, lors du dernier Better Software Conference", était provocateur. Bien sûr que je suis un professionnel! Je ne suis pas un amateur. Mais entre les deux Martin introduit le "laborer", que je traduis librement par: ouvrier. Le titre aurait donc pu être "Êtes-vous un développeur professionnel ou un ouvrier?".

Qu'est-ce qui distingue l'ouvrier du professionnel? Il est clair que je me comporte parfois comme un ouvrier. Quand je fais ce qu'on me dit (sans trop réfléchir), que j'applique la recette que je connais (indépendamment du contexte), que je dis oui (mais que je devrais dire non). Quand je prends un raccourci pour gagner du temps (quand je sais que quelqu'un d'autre va payer pour, plus tard). Quand je reste dans ma zone de confort. Quand je fais juste mes 35 heures/semaines.

J'ai observé ce comportement au sein de notre entreprise, pas seulement chez moi, Robert Martin l'observe dans notre industrie et Seth Godin, dans son livre Linchpin, l'observe dans toutes sortes de domaines et d'industries. Le phénomène est donc largement répandu. Alors, où sont les professionnels, qu'est-ce qui les distingue?

Uncle Bob dit que les professionnels répondent à des "standards de la profession ". Pensons à l'ingénieur, ou au médecin qui doit exercer leur métier à l'intérieur de normes et de règles reconnues. Un ingénieur professionnel n'acceptera pas de concevoir une structure en coupant les coins ronds. Un médecin n'acceptera pas que le patient écrive sa prescription.

Un professionnel demeure calme sous pression. On a qu'à penser au plombier, à l'avocat qui plaide un cas difficile ou au commandant Piché lorsque son Airbus A-330 s'est trouvé en perte de moteur complet au large des Açores.

Robert Martin nous a présenté son "serment du développeur professionnel", à la manière du serment d'Hippocrate pour les médecins .

Ne nuis pas au fonctionnement du système
Essentiellement, soyez certain que le système fonctionne correctement. Et quel meilleur moyen pour s'en assurer que d'exécuter les tests automatisés. Selon Martin, l'équipe d'assurance qualité ne devrait pas trouver de bugs et s'ils en trouvent ils devraient en trouver la cause (dans le code et dans le processus de développement). J'ajouterais qu'on s'attend au même comportement des équipes de maintenance. Martin indique qu'on devrait viser un taux de couverture d'essais de 90 à 95% ("code coverage").

Ne nuis pas à la structure du système
Ici il faut s'assurer de ne pas introduire, ou laisser, du mauvais code, du code qui sent ("code smell") dans le système. Il faut aller rapidement, en progressant sur des fondations solides. Le truc est de refactoriser constamment et sans pitié afin d'obtenir du code simple et facile à modifier. Pour refactoriser sans merci, il faut des tests automatisés.

Maîtrise ton métier
Un professionnel connaît son métier et reste à jour. Je préfère un médecin qui connaît les derniers médicaments ou traitements à celui qui connaît ceux qui existaient lorsqu'il a fait ses études. Notre domaine évolue constamment. Au cours des cinquante dernières années on est passé de la modularité, aux gros programmes, à la programmation structurée, à l'orienté objet, aux design patterns et aux approches agiles. Pourtant, l'essence même du métier reste assez stable. Comme professionnel, maîtrisez-vous UML, les designs patterns, plusieurs langages, un langage dynamique, les diagrammes de flux de données, le principe de substitution de Liskov?

Comme un médecin, un musicien, il faut apprendre et pratiquer de façon continue (voir mon article sur les coding dojos). C'est notre responsabilité d'apprendre, pas celle de notre employeur (tant mieux s'il nous supporte dans cette démarche). Selon Martin il est de notre responsabilité d'investir 20 heures par semaine dans ces apprentissages!

L'importance des essais
Robert Martin, a insisté tout au long de sa présentation sur les tests (je ne rajoute pas "automatisé", car ça devrait être implicite). Pour le développeur, les tests automatisés sont comme les méthodes utilisées par les comptables pour s'assurer qu'ils ne font pas d'erreur. En informatique, on écrit deux fois du code, une fois pour le test et une autre pour la fonctionnalité. En comptabilité, ils écrivent les montants deux fois, une première fois dans les débits et l'autre dans les crédits.

Martin mentionne un phénomène que j'ai observé avec le TDD. J'ai développé des applications Groovy/Grails en TDD et quand j'ai fait une démonstration à des collègues, rapidement ils m'ont demandé comment fonctionnait le débuggeur. Je dois admettre que je ne comprenais pas pourquoi ils étaient aussi préoccupés par la présence d'un débuggeur. Après plusieurs mois de développement, je n'avais jamais senti le besoin d'utiliser un débuggeur. Comme moi, Robert Martin observe que l'utilisation du TDD et du développement par petit pas réduit l'utilisation du débuggeur par un facteur de dix.


Pour en savoir plus :

Keynote de Robert Martin
http://www.agilejournal.com/day-1-agenda/3050-keynote-are-you-a-development-professional (requiert inscription)
http://www.viddler.com/explore/oredev/videos/125/ (même présentation faite en 2008)

Podcast de Robert Martin sur sa présentation http://perseus.franklins.net/hanselminutes_0171.wma


http://fr.wikipedia.org/wiki/Serment_d%27Hippocrate
http://fr.wikipedia.org/wiki/Principe_de_substitution_de_Liskov


11:39 | Lien permanent | Commentaires (0) | Tags : professionel, better software conference