Archive de l'auteur

Toujours dans le chapitre Le bon développeur, voici la suite !

Ne laissez pas sortir le cochon qui est en vous

Même avec les plus belles intentions du monde, il est rare de tenir ses bonnes résolutions plus longtemps que quelques semaines. Aussi, même si vous avez décidé d’être un peu plus perfectionniste à l’avenir, vous n’êtes pas a l’abri d’un moment de faiblesse. Moment de faiblesse qui vous amènerait a écrire du code de cochon: pas relu, bourré de bugs, mal indenté, …

Pour vous mettre a l’abri de ce genre de relâchement, ne prenez qu’une seule bonne habitude:
Faire relire votre code par une personne autre que vous.

Lorsque vous estimez avoir terminé une tache ou une fonctionnalité, présentez vos travaux à une personne pour qu’elle prenne le temps avec vous de les relire. Cette personne peut être un collègue plus expérimenté ou moins expérimenté que vous, une personne travaillant sur un autre projet, peu importe.

Cette validation a plusieurs bénéfices:

  • Pendant que vous développez, elle agit comme une épée de Damoclès, pour vous empêcher de laisser sortir le cochon qui sommeille en chaque développeur
  • Après le développement, elle permet de trouver des bugs ou des situations auxquels vous n’aviez pas pensé.
  • Elle permet aux autres personnes de savoir ce que vous avez développé et permet l’échange entre développeurs

Je vous conseille également, lorsque vous sentez que vous avez cerné comment implémenter la fonctionnalité ou la tache que l’on vous demande (après la phase “casser la faisabilité”), d’aller voir un de vos collègues et de lui exposer votre manière de résoudre le problème. Cela permet parfois de mettre en lumière des problèmes dans la solution originale, et cela permet souvent de trouver une solution meilleure que celle initialement envisagée.

Cherchez a progresser

C’est bête a dire, mais je connais beaucoup de développeurs qui cherchent “juste” a faire leur travail du mieux qu’ils peuvent. C’est une stratégie qui marche bien à court-terme. Néanmoins, ils ne progresseront que de leurs erreurs, c’est à dire pas beaucoup.
Si vous voulez vraiment progresser en tant que développeur, je vous encourage vivement à lire des livres sur votre temps libre.
Il existe quelques classiques que tout développeur doit avoir lu.

Je vous encourage, par exemple a aller voir la liste que conseillait Jeff Atwood en 2004 sur son blog, ou la liste de ses 5 livres indispensables. Le blog de Joël Spolsky passe également en revue des livres recommandés.

Lisez également des journaux, magazines, ou autres blogs qui vous permettrons de mieux appréhender le développement en général.
Lire régulièrement vous permettra de faire évoluer vos connaissance car l’industrie informatique évolue très vite. Une bonne partie vos connaissances actuelles sera démodé dans 5 ans et complètement obsolète dans 10 ans.

Répétez vos gammes

En fait, c’est un peu faux. Il y a certaines choses qui ne seront pas forcement obsolètes dans 10 ans. Je pense aux bases de l’informatique: ce qu’on apprend dans les cursus informatiques.

Voici quelques notions que je considère importante pour faire un bon boulot de développeur:

  • A quoi sert, comment fonctionne, et comment est implémenté: un tableau, une liste chaînée, une pile, une queue et une table de hachage
  • A quoi sert et comment fonctionne un ramasse-miettes
  • A quoi sert et comment fonctionne un thread; comment partager des ressources entre plusieurs threads (sémaphores, mutex, lock, …)
  • Comment marche les réseaux et Internet: TCP/IP, DNS, DHCP, SMTP, POP, VPN, SSL, HTTP, FTP, etc.
  • Connaître les principales attaques informatiques: Cross-Scripting, SQL injection, Buffer overrun, etc.
  • Savoir se servir d’une machine linux

Comments 15 commentaires »

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 !

Comments 16 commentaires »

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 !

Comments 14 commentaires »

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 !

Comments 15 commentaires »

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

Quizz Estimation

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.

Comments Pas de commentaire »