Mieux coder

Le bon développeur, c’est un gars on lui file un objectif, y code !

Tout le monde peut devenir un bon développeur

Dans une entreprise, la différence entre un bon et un médiocre développeur n’est pas à mon sens une affaire de neurones. Une brute en algorithmie peut finalement se relever être un développeur tout ce qu’il y a de plus mauvais pour une entreprise.
C’est plutôt dans l’attitude que l’on reconnaît les bons développeurs.

Apprenez à maîtriser plusieurs langages

Une personne parlant déjà couramment Français, Anglais et Allemand aura plus de facilité à apprendre le Néerlandais, qu’une personne ne parlant que le Français. Avec les langages de programmation, c’est pareil, plus vous en maîtrisez, plus il est facile d’en apprendre de nouveaux.

Je vous conseille donc de sauter sur l’occasion si on vous propose de participer à un projet utilisant un langage que vous ne connaissez pas encore. Si l’occasion ne se présente pas, provoquez-la en apprenant par vous même un langage à la mode.

L’idéal pour un développeur est de connaître au moins 1 ou 2 langages dans chacune des catégories suivantes:

• Langages bas niveau: C, assembleur, …
• Langages Orienté Objets; Java, C#, Eiffel, …
• Langages de Script: Python, JavaScript, Groovy, …
• Langages Fonctionnel: Ruby, Erlang, Caml, …

Le fait de connaître plusieurs langages vous permettra de vous sentir à l’aise avec tout type de code, de connaître les forces et les faiblesses de chaque langage pour en tirer la quintessence.
Le bon développeur sait donc qu’on ne programme pas de la même façon en Java et en C.

Soyez Perfectionniste

Je connais trop de gens qui se satisfont d’une interface graphique médiocre ou d’une fonction à moitié développée. Je répète souvent à l’envi que lorsqu’on développe une fonctionnalité, écrire le code qui fonctionne ne représente même pas la moitie du travail.

Prenez l’exemple d’une épreuve de philosophie lors du bac, il y a une différence entre rendre un brouillon et rendre une copie propre et relue (OK, ça ne vous empechera pas de vous prendre un 4/20, mais ça c’est une autre affaire).

A titre d’exemple, voici les étapes minimum que je m’essaye de m’imposer lorsque j’écris une nouvelle fonctionnalité:

1. Casser la faisabilité, obtenir un premier code qui marche dans le cas nominal, en écrivant des tests unitaires si besoin.
2. Pour chaque instruction, relire le code et gerer tous les cas d’erreurs qui pourraient se presenter
3. Refactoriser et si besoin optimiser le code si besoin
4. Mettre au propre:
   - Enlever les bouts de code commentés qui ne servent plus à rien.
   - Revoir le nommage des variables et des noms de méthodes
   - Enlever les warnings de compilation si besoin
   - Commenter les bouts de code qui ne sont pas triviaux à comprendre
5. Committer le code sur l’outil de gestion de sources (CVS, SubVersion, …)

Inutile d’etre perfectionniste quand ce n’est pas necessaire, sur un prototype jetable par exemple.
En revanche, ne faites pas l’erreur classique d’abaisser votre niveau d’attente envers vous-même parce que le projet est en retard. C’est justement quand on est pressé que le premier jet est bourré de fautes !

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 !

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 !

C’est le grand mal des projets informatiques ! Je connais peu de projets qui prennent vraiment au sérieux la phase d’estimation. C’est pourtant à partir de ces estimations que sont établis de beaux diagramme de gantt qui se révèlent faux dès la première semaine de développement. Or un projet mal estimé c’est un projet qui démarre mal dans la vie… il sortira certainement en retard ou bâclé.

Pourtant estimer est une tache difficile qui mérite qu’on s’y attarde un minimum. Voici un petit quizz inspiré de celui que vous pouvez lire dans Software Estimation de Steve McConnel. Essayez d’y répondre de telle sorte que vos estimations vous donne 90% chance d’avoir la bonne réponse. Si vous ne connaissez pas une réponse, n’allez pas voir sur Wikipedia mais faite plutôt une estimation suffisamment large pour englober la bonne réponse avec 90% de chance.

Faire le quizz

Si vous avez 9 bonnes réponses ou plus, bravo !
Vous savez estimer avec une certitude de 90%.

Si vous avez 8 bonnes réponses ou moins, vous avez été un peu trop optimiste dans vos estimations. Vous avez essayé sur certaines questions de mettre une fourchette qui se rapproche au maximum de la bonne réponse. C’est tout à votre honneur mais mieux vaut toujours une estimation trop large qu’une estimation fausse !

Le developpeur est en effet une espèce (allez savoir pourquoi) de nature plutot optimiste. Quand on lui demande combien de temps ca lui prendra de rajouter la fonctionnalité n°245, il vous répondra qu’il suffit d’ajouter un bouton ici, un bout de code là et que le tour est joué. En bref: “En 2h c’est bouclé !”.
Dans la réalité au bout de 3h de travail, c’est presque fini.. mais pas complètement: “Donnes-moi encore 15 minutes pour boucler l’affaire”. Au bout de 4h, ça y est ! C’est fini… sauf qu’il reste encore 2 ou 3 bugs à corriger pour que ça puisse être livré. Classiquement, il aura fallu 1 journée de travail pour implémenter la fonctionnalité alors que la tache avait été estimée à 2h.

Pourquoi se mettre dans une situation comme ça tout seul? Quand on vous demande d’estimer une tache, n’essayez pas de faire votre kéké pour impressionner la galerie (genre, moi je code plus vite que tout le monde) et essayez de faire l’estimation la plus juste.

Quelques conseils pour terminer:

• Si vous manquez d’information pour faire votre estimation, prenez le temps de réunir les informations qu’il vous faut. Ça peut être de faire un mini prototype, d’aller regarder le temps effectivement pris pour faire une tache similaire, etc.

• Si votre chef insiste pour vous faire baisser votre estimation, ne soyez pas politiquement correct. Dites-lui que vous pensez sincèrement que votre estimation est juste et qu’il peut consulter ses archives pour voir qu’une tache de ce genre prend effectivement le temps que vous avez estimé (et si votre chef ne garde pas un historique de chaque tache, avec l’estimation et le temps effectivement requis, demandez-lui de commencer à le faire.

Quand on développe une application Internet riche en HTML/AJAX, Flex ou Silverlight, nous sommes à la croisée des chemins, entre pages Web et applications riches.

Et quand vient l’heure d’ajouter un bouton à l’application, je me pose toujours la question de savoir s’il vaut mieux mettre un bouton qui ressemble à un…bouton, ou bien un bouton qui ressemble à un hyperlien.

On peut considerer que les hyperliens ont pour unique fonction d’amener l’utilisateur sur une nouvelle page HTML dans le navigateur. C’est leur vocation première et devrait donc rester leur vocation unique. Mais les applications Internet riches ont de ceci de particulier qu’elles n’ont en fait qu’une seule page qui peut changer du tout au tout. Un clic sur un bouton dans une telle application peut donc - meme si l’adresse de la page ne change pas - amener sur une autre interface graphique que l’on pourrait considérer comme une nouvelle page.

On pourrait donc utiliser les hyperliens dans les applications Internet riches quand l’action qui se trouve derrière le bouton va le faire changer d’interface graphique.

Au niveau de l’ergonomie, on peut aussi remarquer que les boutons sont beaucoup plus voyant que les hyperliens. On pourrait donc réserver les boutons aux actions que l’on veut mettre en valeur, et mettre des hyperliens pour les actions que l’on ne veut pas mettre en avant.

Regardez l’interface de Google Analytics permettant de choisir une date et remarquez comme la commande Apply utilise un bouton et la commande Cancel, un hyperlien (Et pour mettre cette dernière encore moins en avant, notez que le mot cancel ne commence pas par une majuscule).

Que pensez-vous de cette utilisation des hyperliens dans les applications Internet riches ? Est-ce intuitif ?