Posts

Qu’est-ce qu’on apprend en lisant du code ? Il existe 5 raisons qui font que le code est ce qu’il est : - limitation de la machine - limitation du langage - limitation du programmeur - historique - specification (at last!) «There are many reasons why programs are built the way they are, although we may fail to recognize the multiplicity of reasons because we usually look at the code from the outside rather than by reading it.

Avez-vous déjà observé un dessinateur en action ? Avez-vous déjà ressenti la fascination de voir apparaître quelques traits qui ne semblent avoir aucun sens puis finalement, de voir le dessin surgir comme par magie. Étant le fils d’une dessinatrice de bandes dessinées, j’ai souvent observé ce phénomène. Je l’ai remarqué aussi en voyant par exemple Cabu dessiner quelques Grand Duduche en direct à la télévision. Quand je regarde un dessinateur, je me rends compte qu’il utilise certaines techniques spécifiques pour obtenir son dessin.

Java bean Spring bean Hibernate bean web bean service bean backing bean … Ça y est, j’ai une métaphore pour mon application : c’est un cassoulet !

A votre avis, qui est le plus agile ? Le chevalier avec ses 90 kg d’armure ou le paladin en tunique avec sa hache ? Supposons qu’au cours de l’écriture de mon programme je rencontre soudainement le besoin d’une fonction d’affichage. def affiche (a, b) Supposons, dans un premier temps, que je sois sûr que cette fonction n’est jamais appelée avec des paramètres nuls. Deux tactiques sont possibles ici: -* Programmation défensive: -** J’écris un test unitaire pour vérifier que ma méthode affiche bien a et b dans le cas où ils sont tous les deux non nuls -** J’ajoute immédiatement dans le corps de ma fonction, au début, quelques lignes de code pour retourner une exception si l’un des deux paramètres est nul1.

Ce soir, je lisais un livre très intéressant à mon petit bonhomme : “Tous différents” par Todd Parr. Je me suis en particulier arrêté sur la page suivante: On peut parler de ce qu'on ressent Voila quelque chose qu’on oublie trop facilement dans les projets professionnels. Par exemple, que penser d’un chef de projet qui insisterait pour être vouvoyé ? Ne serait-ce pas le meilleur moyen de fermer ce type de communication ?

L'agilité à ses balbutiements, avant même que le manifeste agile ne soit écrit, c'est à dire avant que le terme "agile" ne soit inventé, était identifiée par l'intitulé "processus légers" (lightweight processes) par opposition aux processus classiques de type cascade ou cycle en V qui se trouvaient de fait qualifié de "lourd" the founding of the agile alliance. Connaissez vous l’histoire de Galilée telle qu’on la raconte aux élèves de collège ?

Extraordinaire ! Voila mon sentiment général au retour de cette conférence de 2 jours et demi. Il s’est passé quelque chose pendant ces quelques jours. malheureusement, pour les lecteurs qui aimeraient bien comprendre, je n’ai pas d’autre réponse à donner que “il fallait venir”. Ce type d’évènement apporte directement aux participants “là où ça les chatouille”. C’est la magie de l’auto-organisation qui a opéré, magie en partie due à l’extraordinaire largeur de la bande passante d’une communication orale et spontanée entre personnes passionnées par le même sujet.

Mercredi, jeudi et vendredi, je serais à AgileOpen France, une conférence au format OpenSpace Technologie (en français Forum ouvert) sur le thème des méthodes de développement logiciel agiles. Cette conférence sans orateur identifié, ni programme préétabli, réunira très certainement de nombreuses personnalités de l’agilité francophone. Cela promet d’être passionnant. L’inscription est encore possible.

Quand on se fait agent du changement vers des pratiques de développement agiles, on se fait rapidement traiter de fanatique et c’est effectivement ce que l’on a l’air d’être. Je ne sais pas comment font les autres, mais personnellement j’utilise l’idéal comme une référence et une vision de l’objectif à atteindre. Il n’est pas si facile de garder le cap quand on est plongé dans la réalité. Voici ce qu’un client a pu dire de moi dernièrement :

Voici quelques remarques générales sur les commentaires de programme. Cet essai a été écrit suite à la lecture du poste de Christian Faure sur la litterature de code. Comme le fait remarquer Christian Faure dans une réponse à ce message, il s'agit ici du point de vue d'un développeur professionnel. D’une manière générale, je réduis les commentaires au minimum car ils constituent une forme de duplication d’avec le code écrit juste à coté.