Les pieds dans le code

Je viens de lire la traduction d’un article parlant des commantaires dans le code source sur le Framablog . C’est un article écrit par Esther Schindler que je ne connais pas. Son article original titré If the comments are ugly, the code is ugly parle donc de code source, de code source avec de vilain commentaires.

Elle signale que les commentaires doivent être irréprochable, sans faute d’orthographe, sans erreur de grammaire, à jour par rapport aux codes sources commenté…

Et bien j’ai trouvé une solution encore plus simple: je supprime les commentaires et j’essaie de rendre le code plus lisible. Les langages de programmations actuel sont assez expressif, utilise des mots anglais clair, certain langage apporte une structure permettant même d’écrire des presques phrases ! Un code propre n’est pas un code avec des commentaires à jour, mais un code lisible, clair et concis

De plus, tout les langages modernes (enfin j’espère) bénéficie d’une librairie de test unitaire, ce qui veut dire que l’on peut écrire un bout de code très simple qui montre l’intention du programme réel, qui montre comment il fonctionne, qui le documente en quelque sorte. Alors pourquoi écrire en plus des commentaires ? Je préfère voir un code lisible, et au pire devoir aller lire des tests unitaires pour comprendre son fonctionnement (voir ajouter des tests pour vérifier que j’ai bien compris).

Alors je ne sais pas qui est cette dame, mais, même si elle a en partie raison, pitié, éviter de faire du code illisible et sans test unitaire programmé sous pretexte que vous avez écrit des commentaire digne d’un grand roman.

Demain ce déroule l’étape Parisienne de l’"agile tour 2009":http://www.agiletour.org/fr/at2009_paris.html . Un jolie programme de conférence/retour d’expérience et autre atelier qui promet de nous faire passer une bonne journée.

L’évènement aura lieu à la Fac de Nanterre… Ca rappelera des souvenir à certain, et donnera peut-être de bonne orientation à d’autres, déjà sur place.

A demain donc ;-)

Vous habitez prêt de Lille ?
Vous aimez coder ?
Vous aimez rencontrer ?

Un dojo s’ouvre prêt de chez vous, et je pense que vous pourriez bien apprecier et apporter votre pierre à l’édifice.

Muni d’un groupe sur google-group: nord-agile le prochain dojo semble être pour le 2 octobre, dans les locaux du campus Lille 1 (pour moi c’est du chinois, mais pour les Lillois, ça doit être parlant non ?)

Bon code à tous ! :)

Demain (lundi 25 mai) et après demain (mardi 26 mai) se déroule les XP Day France 2009 au chalet de la porte jaune (c’est à Vincenne).

Je m’y rend au nom de Kantena. En effet, nous sommes convaincu que beaucoup de projet en échec aujourd’hui le sont à cause d’un manque de bon sens, et les méthodes agiles en général ne sont que du bon sens mis en forme.

Sur la forme, je ne suis pas convaincu par l’une ou l’autre, et je ne me lancerais pas dans un débat Scrum vs XP vs Lean vs MettezIciUnNomDeVotreChoix. Je pense que selon le projet, le client, l’équipe il faut s’adapter et surtout ne pas aller à l’encontre du bon sens. Par exemple, chez Kantena, nous essayons de proposer à nos client des TMA et autres projets au forfait quand le besoin s’y prête. Dans ce context il est très délicat d’avoir la présence d’un utilisateur ou product owner avec l’équipe.

Ce que j’attend de ces deux journée:

• Rencontrer des gens qui partage un interêt pour ces bonne pratique
• Avoir quelque retour d’expérience
• Apprendre et passer un bon moment.

Je me fixe également un objectif professionnel: avoir une vision plus clair de ce que je peut proposer sous forme d’un contrat ou non, autour de projet au forfait, avec un client distant.

Bref, je suis impatient d’y être, surtout quand je regarde le programme

Le courage fait parti des clefs de l’"eXtreme Programming [wikipedia]":http://fr.wikipedia.org/wiki/Extreme_programming. Il est nécessaire lors du refactoring. Bien trop souvent les développeurs n’osent pas modifier du code existant. Il existe plusieurs raisons à cela:

• C’est le code de… AAah et bien si c’est le code du grand guru maison, qui oserais modifier sont code. Il penserait surement que l’on critique son code, qu’on ne le trouve pas assez bien. Et c’est peut-être le cas, ou alors tout simplement, ce code à besoin d’évoluer. Et plutôt que d’ajouter de nouvelle chose, il faut reprendre, modifier une partie du code existant. Cela évitera les redondances, les erreurs, et le code mort. Je garde mon apologie du refactoring pour un autre billet.

• Trop compliqué à lire Justement ! C’est qu’il faut le reécrire ce code ! Quel horreur du code illisible. Source de bugs, peut-être que ce source fait beaucoup trop de chose par rapport au besoin. Simplifions le !

• Je n’ai pas le temps Je crois qu’il faut de temps à autre avoir le courage de prendre le temps, de perdre du temps. Cela pourrais s’avérer bénéfique par la suite. Si j’ajoute plutôt que de modifier, qui me dit que je ne vais pas devoir y revenir une fois, deux fois, n fois pour corriger un bug, un disfonctionnement, un effet de bord ?

On parle du courage du codeur, le courage de modifier du code, mais je voudrais juste aborder ici un autre courage, celui-ci c’est pour les divers responsables et autres chefs de services: le courage de revenir sur une décision quand elle s’avère être mauvaise.

Trop de projets sont ecrasé contre un mur (ou alors y vont tout droit) parce qu’_en haut_ personne n’ose, personne n’a le courage de tirer les leçons d’une série d’échecs, personnes n’ose revenir sur une méthodologie mauvaise.

Personnellement, je fais de l’informatique pour rendre service à des utilisateurs. Si je vois les utilisateurs heureux lors d’une livraisons, je le suis aussi. C’est un bon moyen de vérifier que nous sommes sur la bonne route. Mais justement, je m’égare de la route du courage dont je voulais parler :-)

N’ayons pas peur de modifier du code. Pour nous aider dans ce sens nous avons plusieurs outils à notre disposition:

• Outils de gestion de configuration (ou versioning): Ces outils nous permette de revenir à une version précédente avec une facilité déconcertante. Alors bien sur il faut en choisir un qui corresponde bien à nos besoin, mais je crois qu’aujourd’hui nous avons l’embarras du choix !

• Test unitaire: Les tests ! En voilà un outil. Avec une bonne batterie de test, nous sommes sur de ne rien casser. Comment ne pas oser un refactoring avec ça ? On modifie, on relance les tests, ça passe ? bien ça marche alors :)

• Langage et architecture: Tout cela est bien beau, mais c’est vrai qu’avec un langage et/ou une architecture ou tout élément et imbriqué dans l’autres, une architecture ou tout est lié, une architecture ou l’on gère plusieurs fonctionnalité dans un même source, c’est beaucoup plus effrayant de modifier un morceau. C’est une des raisons qui me font adorer l’Objet et les architectures associé. Un objet à une responsabilité, et une seul (enfin, il devrait). Pas de code cherchant à tout faire, souvent mal. Au moins c’est simple.

Courage et KISS DRY

Lundi soir, comme apparemment presque tout les lundi soir, c’est rendez-vous au dojo. Non pas celui des arts martiaux, mais celui du développement. Pour rester agiles, l’association XP-France organise des rencontres au dojo.

Dans une salle gentillement fourni par EpiConcept, des praticiens agiles se retrouvent pour un Kata voir un Randori.

J’ai passé une super soirée. J’ai découvert Haskell un langage fonctionnel pur (c’est a préciser apparemment ;-)). J’ai vu des tests, et encore des tests et c’est beau. Vivement le prochain !

Si vous voulez en savoir plus: Voir le projet Dojo sur le wiki de l’asso.

Moi je vais tenter d’y aller tout les lundi :-D

une semaine plus tard

Cet session fût très bonne. Pas loin de 30 personnes ont fait le déplacement pour cette “apéro” qui en fait ressemblait plus à une bonne présentation.

Le thème principal de ce lundi était l’agilité, l’extreme programming, les tests. En effet, des membres de l’association XP-France sont venus nous présenter l’agilité, le développement piloté par les tests le tout dans sous la forme d’un kata, une des pratiques de dojo.

Ensuite, Jean-François nous a présenter une toute nouvelle librairie ruby qui gagne à être connu: Arel également appelé ActiveRessource. Un librairie visant à permettre la création d’ORM(Object Relationnal Mapping). Disont pour résumé que cela enlèverais la couche “concaténation de chaine de caractères” dans ActiveRecord par exemple, et du coup nous aurions le moyen de construire plus joliement des requête SQL. A suivre donc.

Depuis quelque temps déjà je m’interesse aux méthodes agiles, à l’extreme programming, cette présentation à fini de me convaincre qu’il faut absoluement que j’aille en Dojo pour pratiquer le code, échanger avec d’autres personnes aguéri à ces techniques de tests et de façon de voir le code.

On en reparle plus tard ;-)

Dans mes reflexions sur les méthodes qu’il faudrais mettre en pratique dans bien des entreprises, je pense souvent aux méthodes dites agiles.

Alors oui, c’est dur de mettre en place l’"extreme programming":http://fr.wikipedia.org/wiki/Extreme_programming, plusieurs problèmes sont évidant: le code en binome par exemple. C’est pas facile, regardé autour de vous dans l’openspace qui sert de maison aux équipes de developpement: qui ne cherche pas a avoir la souris et/ou le clavier en main ? Vous en avez beaucoup des collègues qui quand ils viennent pour vous aider, ne vous prennent pas le clavier des mains ? Pas beaucoup pour moi, je dois pouvoir les compter sur les doigts de la main gauche (et ce sur plusieurs société).

Mais ça c’est juste une question d’habitude surement.

Le Test Driven Development fais pourtant parti des base de l’extreme programming (à mes yeux en tout cas) mais même ça c’est pas facile à faire. Déjà il faut une technologie qui le facilite. Avec ma techno propriétaire en ce moment, ça serais pas facile à faire (mais j’essaie de trouver une idée pour quand même, na ! :p).

Pour toute ces raison, je regrette de ne pas avoir pu me rendre aux rencontres agiles histoire d’entendre des retour d’expérience, de rencontrer des personnes ayant pu mettre en place de type de méthodologie de travail.

Il faut que je surveille d’un peu plus prêt les activitées de l’association eXtreme Programming France moi.. Ca serais pas mal