Après un mois et demi dans mes nouvelles fonctions, je viens de faire une présentation de l'intégration continue à mon équipe. Cela vient au moment où nous avons déjà des premiers résultats : intégration via Continuum dans WebSphere d'une douzaine de modules Maven sur une centaine, réalisée par un petit groupe, même pas dédié à cent pour cent.
En plus des questions sur le sujet stricto sensu, la présentation a été suivie d'un débat ouvert où toute l'équipe a eu l'occasion de participer et de s'exprimer, sur le thème « existant, problèmes, améliorations ». Le côté expression libre est primordial quand on a de gros enjeux de développement informatique. Je pense réitérer l'expérience, que j'ai jugée extrêmement positive, quand le moment viendra.
Bref, une bonne fin de journée. J'ai cadré la réunion sur deux heures, ni trop ni trop peu. On verra par la suite si les-filles-zet-les-gars alimentent de leurs réflexions le wiki commun.
Mais je suis bien confiant :-)
09 septembre 2008
06 septembre 2008
Un peu de code pour la détente
Ben oui, histoire de se faire un peu plaisir, quelques heures de programmation bien installé dans son fauteuil. Dans le temps on lisait des polars.
C'est drôle, ça se ressemble aujourd'hui, dans l'aspect quête de la vérité.
Dans un polar on vous donne assez souvent le contexte et les événements à élucider, le plus généralement un meurtre ou plusieurs. S'ensuit une histoire, qui ne raconte pas l'histoire elle-même (sinon autant lire de la mythologie), mais qui est un déroulé de la recherche de la « solution ». Solution au sens de résolution plus que de preuve. Le plaisir réside dans ce déroulé, et évidemment dans le succès final qui est moins la compréhension (penser au Big Sleep, incompréhensible, de son propre aveu pour son auteur même) que l'élucidation, la mise à la lumière de ce qui était caché ou obscur.
Dans le développement informatique aujourd'hui, avec des méthodologies comme TDD (Test Driven Development), on a un peu le même aspect, et évidemment le même plaisir. Je m'explique. En TDD, on commence par écrire les tests, c'est-à-dire que le programme n'existe pas encore, mais on commence déjà à le faire planter. Ensuite, le travail consiste à réaliser le programme pour faire passer les tests. Et quand on a fini, il arrive selon la complexité ou le déroulé qu'on ne comprenne plus rien (c'est rare) à ce qu'on a programmé, mais dans tous les cas au moins les tests passent. On peut alors livrer le programme, et c'est bien cette élucidation qu'on recherchait.
Je parlais au début de quête de la vérité, dans le sens de sa nature, évidemment, pas de son contenu.
Bien qu'en poursuivant l'analogie avec le polar, écrire du code aujourd'hui apprenne aussi des choses sur le monde : quelques clics sur Wikipédia pour cerner un cas fonctionnel, et on découvre de nouveaux espaces à connaître, de façon comparable à ce qui se passe lors d'une digression dans un roman policier, Série Noire ou pas. La seule chose qu'on n'ait pas est l'aspect historique : les informations du web sont d'une part récentes (moins de 20 ans), et sans cesse actualisées. Un exemplaire de la Série Blême a, lui, une présence qui vient tout droit d'une autre époque.
Toujours dans l'analogie entre code développé en TDD et polar, on pourrait dire que dans le code les tests s'accumulent de la même façon qu'on peut toujours dans un livre revenir aux pages précédentes sans qu'elles aient changé (non, le « Livre de sable » que décrit Borgès n'est pas un polar ;-)). Ce n'était pas du tout le cas avec d'autres façons de programmer, où au contraire les tests se faisaient de façon globale à la fin, sur l'objet complet. C'était de l'ingénierie classique, pas du développement.
Alors, un peu de code pour la détente.
C'est drôle, ça se ressemble aujourd'hui, dans l'aspect quête de la vérité.
Dans un polar on vous donne assez souvent le contexte et les événements à élucider, le plus généralement un meurtre ou plusieurs. S'ensuit une histoire, qui ne raconte pas l'histoire elle-même (sinon autant lire de la mythologie), mais qui est un déroulé de la recherche de la « solution ». Solution au sens de résolution plus que de preuve. Le plaisir réside dans ce déroulé, et évidemment dans le succès final qui est moins la compréhension (penser au Big Sleep, incompréhensible, de son propre aveu pour son auteur même) que l'élucidation, la mise à la lumière de ce qui était caché ou obscur.
Dans le développement informatique aujourd'hui, avec des méthodologies comme TDD (Test Driven Development), on a un peu le même aspect, et évidemment le même plaisir. Je m'explique. En TDD, on commence par écrire les tests, c'est-à-dire que le programme n'existe pas encore, mais on commence déjà à le faire planter. Ensuite, le travail consiste à réaliser le programme pour faire passer les tests. Et quand on a fini, il arrive selon la complexité ou le déroulé qu'on ne comprenne plus rien (c'est rare) à ce qu'on a programmé, mais dans tous les cas au moins les tests passent. On peut alors livrer le programme, et c'est bien cette élucidation qu'on recherchait.
Je parlais au début de quête de la vérité, dans le sens de sa nature, évidemment, pas de son contenu.
Bien qu'en poursuivant l'analogie avec le polar, écrire du code aujourd'hui apprenne aussi des choses sur le monde : quelques clics sur Wikipédia pour cerner un cas fonctionnel, et on découvre de nouveaux espaces à connaître, de façon comparable à ce qui se passe lors d'une digression dans un roman policier, Série Noire ou pas. La seule chose qu'on n'ait pas est l'aspect historique : les informations du web sont d'une part récentes (moins de 20 ans), et sans cesse actualisées. Un exemplaire de la Série Blême a, lui, une présence qui vient tout droit d'une autre époque.
Toujours dans l'analogie entre code développé en TDD et polar, on pourrait dire que dans le code les tests s'accumulent de la même façon qu'on peut toujours dans un livre revenir aux pages précédentes sans qu'elles aient changé (non, le « Livre de sable » que décrit Borgès n'est pas un polar ;-)). Ce n'était pas du tout le cas avec d'autres façons de programmer, où au contraire les tests se faisaient de façon globale à la fin, sur l'objet complet. C'était de l'ingénierie classique, pas du développement.
Alors, un peu de code pour la détente.
Inscription à :
Articles (Atom)