Essais

Il est amusant de constater qu’on peut faire correspondre différents profils de développeurs aux corps de métier du bâtiment. Des maçons, des plombiers et des peintres, voici des profils tout à fait distincts. Chacun peut être un jour l’un un jour l’autre, ou plusieurs corps en même temps. Ce qui me fait toujours peur personnellement, c’est de me voir coller une étiquette et de ne plus pouvoir m’en défaire.

­­­­­­­­­­­­– Tu fais quoi, Papa ? – Ecoute Marc, je suis fatigué ce soir, joue avec ton train… – Quoi ? – Je suis fatigué, joue avec ton train. – Tu fais quoi, papa ? – … – Tu fais quoi, papa ? tu fais du dessin ? – Non, je suis en train d’écrire une lettre à mamie. – C’est quoi une lettre ? – … – C’est quoi une lettre, papa ? – C’est comme un mail sauf que je vais la donner à quelqu’un qui la portera jusqu’à la maison de mamie !

Une bonne partie de cet article est issu du site caplbm.typepad.com/personnelgestion.pdf Master en médecine, psychologie et philosophie, Edward de Bono est parti du constat que la pensée occidentale traditionnelle est entièrement basée sur l’analyse et l’argumentation. Or, l’analyse, si fine soit-elle, ne suscite pas l’apparition de nouveaux concepts au contraire des pensées créative et constructive. Edward de Bono distingue trois formes de pensée la pensée constructive la pensée créative la pensée critique.

De plus en plus d’entreprises éditrices de logiciels organisent leurs équipes de travail en binôme, c’est à dire que les développeurs écrivent des programmes informatiques en se mettant à deux par clavier. Qu’est-ce qui a pu motiver ces entreprises à changer ? Cette pratique est-elle le fait d’illuminés rêvant d’un monde meilleur où la moitié des employés se tournerait les pouces ? Ce qui est étonnant, c’est que le binômage existe depuis plus de 20 ans, mais l’engouement pour ce mode de fonctionnement semble récent.

Lors de mes cours d’informatique, j’ai très tôt appris qu’il était indispensable de réfléchir avant de se lancer dans l’écriture d’un programme. Certains ont poussé ce principe à l’extrême et on inventé le MDA (Model Driven Architecture). Cette approche propose d’écrire en UML l’intégralité du modèle de l’application avant de commencer à travailler. Je n’ai personnellement jamais rencontré de projet informatique ayant réussi en appliquant cette méthode. Le problème de cette approche est qu’elle essaie de manger un mammouth en une seule bouchée.

Musique et Programmation Les spécifications sont à la programmation ce qu’une partition est à la musique. La véritable performance ne se réalise qu’à partir du moment où l’on arrive à s’en détacher. Avez-vous déjà demandé à un ordinateur de jouer une partition de musique ? J’ai essayé, ça ne fonctionne pas. Avec du bon matériel, on obtient un air juste, mais sans âme, sans émotion. Un logiciel informatique n’est pas seulement le produit d’une activité rationnelle, c’est pour cette raison que la génération automatique d’un logiciel à partir d’un modèle UML ne fonctionne pas.

Avez-vous déjà vu un code où toutes les fonctions commenceraient par tester tous les paramètres reçus et qui retourneraient null si l’un des paramètres est null ? Ce type de code existe sûrement (Il est étonnant de constater que tout ce que l’on peut imaginer de plus horrible existe déjà), mais je ne l’ai jamais rencontré. J’ai par contre souvent lu du code où cette intention était présente. Cette pratique s’appelle de la programmation défensive.

Aujourd’hui, on m’a affirmé que les boucles While étaient plus rapides que les boucles For ! Cette affirmation m’a paru pour le moins étrange, et j’ai décidé de vérifier rapidement ce qu’il en était. J’ai fait ma petite expérience en Java. Expérience Voici le code source de l’expérience: public class LoopSpeedTest extends TestCase { private static final int VERY_BIG_NUMBER = 10000000; private static final int NOMBRE_ITERATION_EXPERIENCE = 1000; public void testForLoopSpeed() throws Exception { mesureTempsExperience("for", new Experience() { public void run() { for (int i = 0; i < VERY_BIG_NUMBER; i++) { } } }); } public void testWhileLoopSpeed() throws Exception { mesureTempsExperience("while", new Experience() { public void run() { int i = 0; while (i < VERY_BIG_NUMBER) { i++; } } }); } private void mesureTempsExperience(String nom, Experience experience) { List<Integer> resultats = new ArrayList<Integer>(NOMBRE_ITERATION_EXPERIENCE); int somme = 0; for (int indexExperience = 0; indexExperience < NOMBRE_ITERATION_EXPERIENCE; indexExperience++) { Chronometer.

Suite à la lecture du livre "Software Craftsmanship", je me suis fait quelques réflexions sur la pratique de "client sur site" proposé par XP. Le cycle en V connaît un défaut majeur : l’effet “téléphone arabe”. L’idée de diviser le travail de développement logiciel par spécialisation spec/dev/test en donnant la responsabilité de chaque spécialité à des “chefs” distincts produit un effet de téléphone arabe. En effet la première équipe, chargée des spécification, explore l’“idée” du logiciel et imagine une solution permettant de répondre à tous les besoins du client.

Dans la littérature sur l’eXtreme Programming, on parle du rôle des membres d’un binôme en tant que “Pilote” et “Copilote”. Après trois ans de pratique je viens seulement de réaliser que ces termes font sans doute référence à une équipe de pilote de rallye. Dans la voiture, un des deux équipiers a le rôle du pilote et son travail est de “manipuler” la voiture le plus rapidement possible. Pour améliorer ses performances, il se décharge complètement de la gestion de l’itinéraire sur son coéquipier.