Monthly Archives: juillet 2008

Etes vous un mauvais développeur?

Comme l’écrit Thibault sur son blog, il est aisé de reconnaitre les mauvais développeurs:

Mais au fond, qu’est-ce qu’un mauvais développeur? Intuitivement, nous savons les reconnaître quand nous les voyons (ou quand nous voyons leur code).

Parce que bon, le mauvais développeur, il doit écrire un programme, et ben, il code, tandis que le bon développeur, il doit écrire un programme, bon… il code. Mais bon, c’est un bon développeur

Au passage, si vous ne savez pas différenciez le bon chasseur et le mauvais chasseur, commencez par revoir vos classiques.

Et donc, d’après Thibault, le mauvais développeur a une furieuse tendance à:

  • Recoder ce qui existe déjà
  • Écrire un code illisible
  • Écrire beaucoup de commentaires
  • Optimiser à mort

Mais pas seulement. Je rajouterais qu’il a aussi quelques autres mauvaises habitudes:

Il aime chercher les ennuis

Il parle en français, il écrit en français (enfin un dialecte qui y ressemble, les fautes d’orthographe et de grammaire en plus), donc notre mauvais développeur code en français.

String enlèveLesAccents(String chaîne) {
	String résultat = "";
	for (int conteur = 0; conteur < chaîne.length; conteur++) {
		char caractère = chaîne[i];
		if (caractère == 'é' || caractère == 'è' || caractère == 'ê') {
			caractère = e;
		} else if (caractère == 'à') {
			caractère = a;
		}
		résultat += caractère;
	}
	return résultat;
}

Pour celui qui est derrière, c’est juste pénible de taper les accents.
Il aime donc nommer ses variables et ses méthodes dans la langue de Molière avec les accents et tout et tout. Mais parfois il code quand même en anglais…

C’est un adepte du copier/coller

Et oui, notre mauvais développeur code parfois en anglais… quand il pompe du code sur internet ! Ca ne le dérange pas de mettre l’une en dessous de l’autre deux méthodes qui ne sont pas codé dans la même langue, qui n’ont pas la même indentation, les mêmes conventions, etc.

String enlèveLesAccents(String chaîne) {
	String résultat = "";
	for (int conteur = 0; conteur < chaîne.length; conteur++) {
		char caractère = chaîne[i];
   // Remove german accents
   char c = caractère;
   switch (c)
   {
   case 'ü': c = 'u'; break;
   case 'ä': c = 'a'; break;
   case 'ö': c = 'o'; break;
   }
		caractère = c;
		if (caractère == 'é' || caractère == 'è' || caractère == 'ê') {
			caractère = e;
		} else if (caractère == 'à') {
			caractère = a;
		}
		résultat += caractère;
	}
	return résultat;
}

Il aime la concision

Le mauvais développeur aime les noms de variable et de méthode concis.

Franchement on comprend tout de suite que la méthode qui suit enlève les accents de la chaine passée en paramètre. Non?

elvAct(String c) { ... }

Le mauvais développeur adore donc les acronymes et les abréviations, surtout quand peu de personnes les connaissent.

int calcPZT(int p1, double p2, double p4) { ... }

Et quand l’imagination fait défaut, le mauvais développeur sait toujours s’en sortir pour nommer ses variables: v1, v2, v3, …

int calcPTU(int p1, int p2, double p3) {
	double v1;
	int v2;
	String v3;
	byte[] v4;
	v2 = p2 + 7;
	v1 = p1*4.12d + p3;
	v3 = "" + v2;
	v4 = v3.getBytes("UTF-8");
	return 1 + v4.length;
}

Il aime les mystères

Le mauvais développeur aime tester plusieurs versions de son algorithme, et aime laisser des lignes commentées sans qu’on sache pourquoi, ou bien indiquer ce qui ne marche pas sans explications.

int calcPTU(int p1, int p2, double p3) {
	int v2 = p2 + 7;
//	if (v2 < 9) {
//		v2 = 9;
//	}

	double v1 = p1*4.12d + p3;
	String v3 = "" + v2;
	byte[] v4 = v3.getBytes("UTF-8");
// TODO: Si p1 vaut 7, alors la fonction ne retourne pas le
// bon résultat, il faudrait corriger ça dans une prochaine version.
	return 1 + v4.length;
}

Remarquez le test sur v2 commenté sans qu'on sache le pourquoi du comment. Le mauvais développeur aime être mystérieux !

Améliorez vos estimations

Pouvez vous me dire avec précision en combien de temps vous courez un 400 mètres?

La réponse est certainement non, si vous ne connaissez pas votre temps sur 400, 200 ou 100 mètres. L’avantage d’un athlète, c’est qu’il s’est déjà chronométré des centaines de fois sur ces distances. Avec tout cet historique, il est capable d’estimer avec précision le temps qu’il va mettre pour courir la distance en se référant au temps qu’il avait mis un jour comme celui d’aujourd’hui (même état de forme, même conditions climatiques, …) et en l’extrapolant légèrement si besoin.

Et l’informatique… c’est comme la course à pied. La première étape pour faire une bonne estimation du cout d’une nouvelle fonctionnalité, c’est d’avoir des données objectives sur le cout réel d’une tâche similaire.

Si vous n’avez pas l’habitude de noter toutes les estimations que vous faites, puis de les comparer avec le temps que vous avez effectivement mis pour réaliser cette tache, vous pouvez grandement améliorer vos estimations en suivant les quelques conseils suivants.

Avant de commencer une tache, je vous conseille donc de faire une estimation du temps requis pour effectuer cette tache. Ensuite réalisez la dite tache, puis notez le temps que vous avez mis pour effectivement réaliser la tache. Lorsque vous aurez réalisé une dizaine de tache de la sorte, vous aurez assez d’information pour calculer votre qualité relative d’estimation.

Une qualité d’estimation relative supérieure à 1 signifie que vous êtes généralement un peu optimiste dans vos estimations. Si a l’inverse votre qualité d’estimation relative est inférieure à 1, vous êtes plutôt du genre pessimiste. Dans tous les cas, plus vos estimations sont justes, plus votre qualité d’estimation relative est proche de 1.
Ne soyez pas surpris ou frustré si au début, votre qualité d’estimation est de l’ordre de 3 ou de 0.33, elle s’améliorera au fil du temps.

Une fois votre première qualité d’estimation relative calculée, lorsqu’on vous donnera une nouvelle tache à estimer, faites votre estimation en âme et conscience, puis calculez une estimation corrigée.

Cette estimation corrigée devrait normalement être plus proche du résultat final car elle compense votre relative pessimisme ou optimisme. Faites ainsi pour les 5 taches suivantes que vous donnera a réaliser, puis recalculez votre vélocité relative.

Et ainsi si de suite… jusqu’à ce que vous n’ayez plus besoin de compenser vos estimations tellement elles se révèlent exactes !