Du plus loin que je me souvienne, j’ai toujours eu une motivation et une excitation hors norme dès que j’abordais quelque chose de nouveau, que j’avais personnellement choisi, et inversement, un sentiment d’ennui allant même à la dépression quand il s’agissait de tâches répétitives sur des sujets non stimulants.

Je fais partie de ceux qui, une fois les grandes lignes saisies, ainsi que le but profond, aiment passer à un autre sujet, plutôt que de s’essouffler sur les détails.

Le truc avec les multipotentiels, c’est la soif de savoirs, et par conséquent la transdisciplinarité. J’aime apprendre de sujets totalement différents, et cette soif me permet d’innover plus facilement en connectant des choses qui, pour la plus part des gens n’ont pas de lien. C’est là que s’exerce notre réel talent créatif.

Devoir rester sur un projet, sur un produit, ou sur une prestation qui ne m’intéresse pas, est une réelle torture. Le temps se fige, et les sentiments d’ennui et de perte de temps me submergent. Tout ce temps perdu que je pourrais utiliser pour grandir, apprendre, fabriquer, expérimenter, et qui me serait utile, mais aussi aux autres.

Et au contraire, lorsque le sujet du boulot m’intéresse, je m’investis à un point que j’atteins souvent mes limites, autant physiques que mentales.

Aujourd’hui on pourrait espérer que la plupart des employeurs recherchent des potentiels plutôt que des acquis, car dans la société en perpétuel changement qui nous entoure, il va falloir connecter entre elles des choses qui ne le sont pas encore, et il va falloir être capable d’apprendre vite afin de s’adapter.

Mais la France fonctionne encore de manière assez rigide sur le plan de l’emploi. Du coup gagner sa vie en étant multipotentiel est un vrai problème. D’autant plus que la plupart des multipotentiels, mais aussi des hauts potentiels adultes (souvent les mêmes) s’ignorent. Ils et elles naviguent donc à l’aveugle, poussés par la pression sociale et matérielle à devoir gagner de l’argent, se conformer, sans outil ni arme pour se construire une vie « normale » tout en respectant leur personnalité profonde.

Il faut aussi savoir que nous, les multipotentiels, doutons par nature. Nous somme aussi des introvertis, qui sont plus enclin à collaborer, harmoniser et à travailler soit totalement seul, soit au contraire en intelligence collective. Nous nous plaçons en explorateur des savoirs, et nous ne pouvons donc jamais être surs de rien tant que nous ne nous sommes pas aventurés sur toutes les voies. Nous sommes souvent dépeints comme hésitants, des personnes auxquelles on ne peux pas confier trop de responsabilité, et qui sont de mauvais leaders. C’est à cause de la norme « extravertie », qui joue en notre défaveur. On a toujours cru qu’il fallait être une grande gueule pour être un bon leader. Mais aujourd’hui on commence à se rendre compte que le monde aurait beaucoup à gagner si les introvertis prenaient les commandes. On se rend aussi compte que les métiers de demain sont beaucoup plus complexes et transdisciplinaires qu’aujourd’hui.

Un grand terrain devrait donc enfin s’ouvrir pour permettre aux multipotentiels, aux hauts potentiels et aux intravertis d’enfin prendre la place qu’ils méritent.

N’importe quel logiciel est constitué de code, nous pouvons créer des langages qui sont au plus près des besoins business, nous pouvons créer des outils qui nous aident à analyser et traduire ces exigences, mais il y aura toujours du code, et plus ce code est clean plus le logiciel est maintenable et évolutif.

Mais comment doit être un code clean?

Bad Code

Vous avez déjà été considérablement gêné par un mauvais code, vous avez sûrement fait face à cet obstacle plusieurs fois, mais pourquoi l’avez-vous écrit ? Si vous êtes développeurs, vous avez forcément écrit un jour du mauvais code, c’est inévitable, et les raisons sont multiples, et certainement bien claires dans vos têtes:

• Essayer d’aller vite.
• Pas de temps à perdre sur cette feature.
• Vous n’avez pas eu le temps de faire un bon travail.
• Votre patron serait en colère contre vous si vous preniez le temps de nettoyer votre code.
• Peut-être que vous étiez fatigué de travailler sur ce programme et vous vouliez que ce soit fini.

Peu importent les raisons, le point commun à cette session de mauvais code est toujours une promesse malheureusement vite dite et vite oubliée, « je nettoierai plus tard ».

Une fois que notre code marche, on se dit : « un mauvais code qui marche, c’est mieux que rien », puis on passe à autre chose avec l’idée de nettoyer plus tard, sauf que Plus tard est égal à jamais.

Seulement voilà, plus les features s’accumulent, plus le mauvais code est présent, et moins votre logiciel est maintenable, ce qui se traduit par une productivité de l’équipe qui ne cesse de diminuer, et qui tend finalement vers zéro. Ce qui nous mène à la nécessité de réécrire le code, proprement cette fois ci, afin d’y voir plus clair

Clean code ?

Vous êtes bien conscient qu’un mauvais code est un obstacle important, et la seule façon d’aller vite est de garder le code propre.

La question qui se pose est « Comment pouvez-vous écrire du code propre », il n’est pas possible d’essayer d’écrire du code propre si vous ne savez pas ce que cela signifie!

• Un code propre est avant tout un code qui doit être agréable à lire.
• Un mauvais code permet au désordre de grandir! Plus on a des bouts de code mauvais, plus la qualité de notre logiciel tend vers la décadence.
• Un code propre doit prêter attention aux détails et doit être est focalisé, chaque fonction, chaque classe, chaque objet expose une attitude simple qui reste entièrement indépendante, et non polluée par les détails non nécessaires.
• Un code propre doit clairement exposer le problème à résoudre et ne doit contenir que ce qui est nécessaire.
• Il y a une différence entre le code qui est facile à lire et le code qui est facile à changer, un code propre doit être facile à améliorer par d’autres personnes.
• Un code non testé n’est pas un code propre, peu importe s’il est lisible et accessible.
• Un code propre est un code qui a été pris en charge par quelqu’un qui a pris le temps de rester simple et ordonné.
• Ne contient pas de duplication.
• Un code propre est aussi un code qui réduit au maximum le nombre d’entités telles que les classes, méthodes, etc.
• Évident, simple et convaincant: quand on lit un code propre, on ne doit dépenser trop d’effort pour le comprendre,
  Savoir si le code est propre ou mauvais n’est pas suffisant, comment peut-on écrire un code propre ?

Plusieurs techniques et bonnes pratiques faciles à adopter existent pour aider à écrire un code propre : nommage explicite de vos fonctions et variables – se passer de commentaires le plus possible, fractionnement de votre code en de multiples petites fonctions et bien d’autres, etc …

Je vais tenter ici de vous expliquer une méthode qui vous permettra d’évaluer très rapidement la qualité de l’environnement de travail d’une équipe de développement.
Il s’agit du « Joel Test ». Une méthodologie imaginée par Joel Spolsky ( http://www.joelonsoftware.com) qui est notamment co-fondateur de http://stackoverflow.com/. Si vous voulez lire l’article original c’est ici : http://www.joelonsoftware.com/articles/fog0000000043.html
Ce test est basé sur 12 simples questions. Chaque question donnant un point si la réponse est « oui ». Si vous obtenez un score de 12 c’est que vous avez tout bon. Un score de 11 est tolérable mais d’après lui un score de 10 ou moins dénote de gros problèmes.

The Joel Test
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

Évidemment ce n’est pas la seule métrique à prendre en compte, ni un indicateur de réussite. Vous pouvez avoir un score de 12 et une super équipe, mais un produit dont personne ne veut avec des technologies qui ne vous intéressent pas. Et inversement, un score inférieur à 10 avec une équipe qui n’a pas trop de rigueur, mais faire des choses fantastiques où vous vous sentirez super bien.
Je vais maintenant décrire ces 12 questions.

1. Do you use source control?
Autrement dit : utilisez-vous un outil de gestion de version des sources (cvs, svn, git…)? Il me parait essentiel d’avoir un outil de versionning, pour pouvoir travailler de manière collaborative et également garder un historique du travail effectué. Ceci peut nous éviter bien des problèmes (notamment la perte de code) et nous aider à réparer des erreurs en récupérant facilement une ancienne version.

2.Can you make a build in one step?
Considérant le build comme un livrable issu des dernières versions snapshot. Joel part du principe que si votre application nécessite plus d’une étape pour construire votre livrable, les risques d’oublier l’une de ces étapes lorsque vous livrez ne sont pas négligeable. Par ailleurs lorsque la deadline de livraison approche vous n’avez pas envie d’avoir 15 étapes à faire. Vous voulez livrer rapidement et ne pas perdre de temps sur cette tâche.

3.Do you make daily builds?
L’idée est surtout d’avoir un outil d’intégration continue effectuant un build quotidien. On a tous un jour ou l’autre eut cette conversation avec un collègue :
Vous : « Je pense que tu as oublié de commiter un fichier, je n’arrive pas à builder sur mon environnement. »
Votre collègue : « Non, j’ai tout commité, tu n’es peut être pas à jour ou alors c’est toi qui a cassé le build »
S’en suit une discussion stérile ou chacun reste persuadé que l’autre a oublié quelque chose et ne veut pas l’admettre.
L’avantage majeur d’un tel outil est de travailler uniquement sur ce qui a été commité. Vous pouvez donc à tout moment connaître les sources que vous pouvez ou non récupérer. Joel suggère un build pendant le déjeuner pour que chacun commit son travail avant de déjeuner et récupère toutes les modifications au retour de la pause. C’est une solution envisageable mais je préfère l’idée de réparer un build cassé le plus rapidement possible. Ce qui implique de le détecter le plus rapidement possible. La plupart des outils d’intégration continue permettent de programmer les builds tous les X temps ou sur évènement (par exemple à chaque commit). Après, à chaque équipe d’adopter la solution qui lui convienne le mieux.

4. Do you have a bug database?
Effectivement pour ce point je rejoins l’opinion de Joel qui explique que les cerveaux des développeurs ne peuvent pas constituer une base fiable de toutes les anomalies connues et/ou corrigées. Il existe beaucoup d’outils sur le marché (Jira, Mantis, …)

5. Do you fix bugs before writing new code?
Joel nous explique avec une anecdote enrichissante sur le développement de Microsoft Word l’intérêt de cette méthodologie. En résumé leurs équipes étaient tellement en retard dans le planning qu’ils ont développé chaque fonctionnalité rapidement pour passer à la suivante et respecter le planning. Toutes les anomalies seront détectées et reportées, mais feraient l’objet de corrections prévues une fois la deadline passée. Cette façon de reporter à plus tard été baptisé « infinite defects methodology » ou comment fabriquer une roue couverte de rustines.
Suite à cela, Microsoft a appliqué la « zero defects methodology » la priorité étant de corriger chaque anomalie connue avant de développer de nouvelles fonctionnalités.
Ce concept permet sur le long terme de gagner beaucoup de temps pour différentes raisons :
– plus rapidement vous corrigez le problème, plus le code est frais dans votre mémoire, ce qui vous permettra de le corriger plus vite que si vous devez d’abord vous rappeler du code écrit.
– si l’anomalie à corriger a déjà été livrée il vous faudra plus de temps pour la corriger (vous devrez potentiellement relivrer, créer une branche, reporter sur le tronc …)
– le temps de correction n’est pas toujours prévisible : on a parfois des bugs dont le temps de correction variera selon le temps de détection de la cause. Par contre, le temps de développement des nouvelles fonctionnalités est estimable. Si l’on développe toutes les fonctionnalités et que l’on s’occupe de corriger les anomalies à la fin, on aura respecté le planning initial mais la date de bouclage sera très difficilement prévisible. Corriger les bugs avant de faire de nouveaux développements permet d’avoir un planning plus proche de la réalité.
– cela permet également d’avoir une application de qualité dans un état quasiment toujours livrable, ce qui permet d’être réactif au marché.

6. Do you have an up-to-date schedule?
Avoir un planning à jour apporte une aide précieuse. Grâce à lui nous pouvons organiser les évènements et les décaler si besoin. L’autre atout s’affilie à l’un des avantages de scrum : si l’on a du retard mais que la date finale ne peut être déplacée, nous devons réévaluer la nécessité des fonctionnalités et ainsi travailler par ordre de priorité en fonction de l’importance des celles-ci.

7. Do you have a spec?
Tout le monde est d’accord pour dire que l’on a besoin de traces écrites sur le fonctionnel d’une application. Que ce soit une spécification fonctionnelle détaillée en bonne et due forme, ou bien une liste d’US rédigées de manière concise et claire. En tant que développeur, on pense tout d’abord à la façon dont on implémentera le code. Si l’on n’a pas, en amont, rédigé la description de la fonctionnalité, même de façon sommaire, on risque de découvrir les éventuels problèmes fonctionnels une fois le code écrit. Ce qui implique que l’on devra repasser sur ce code, voir également sur la spécification de la fonctionnalité.
Si l’on définit par écrit le besoin et le fonctionnement d’une nouvelle fonctionnalité, on aura plus de facilité à corriger les éventuels problèmes fonctionnels lors de la rédaction. Ainsi le code pourra être implémenté pour répondre au besoin dès le départ. Corriger des anomalies sur une application non documentée peut devenir tellement complexe que certains décident de tout jeter pour recommencer de zéro. Joel préconise d’appliquer la règle « no code without spec » pour éviter ce genre de problème.

8. Do programmers have quiet working conditions?
Lorsqu’un développeur est au meilleur de ses capacités, on dit qu’il est dans la « zone ». Cette zone (cf article : 7 idees pour transformer une bonne equipe, en equipe exceptionnelle) est atteinte au moment où il est complètement concentré sur son travail et ne prête aucune attention à l’environnement qui l’entoure. Il faut en moyenne 15 minutes pour atteindre la zone de travail optimale. Mais le fait est que l’on peut en sortir très rapidement. Que ce soit à cause du bruit, d’un coup de téléphone, d’une pause, d’une interruption par un collègue etc. Dans les open space et autres bureaux partagés, la principale raison est l’interruption intempestive de nos collègues. Du coup lorsque l’un de vos collègues pense gagner du temps en vous posant une question qui vous prendra 1 minute à chacun, au lieu de prendre 5 minutes à chercher seul, il fait en réalité perdre 15 minutes de votre temps pour gagner 4 minutes du sien. La meilleure solution est de considérer que vos collègues sont dans un bureau fermé avant de les déranger et également de se demander si cela ne nous prendrait pas moins d’un quart d’heure pour trouver une solution seul.

9. Do you use the best tools money can buy?
On ne parle pas d’avoir toutes les licences des dernières applications à la mode mais uniquement d’avoir des outils adaptés au travail demandé. En réalité un développeur perd parfois beaucoup de temps car sa machine n’est pas assez performante. Si sa machine prend par exemple 15 secondes à la compilation, ce temps est perceptible et fera perdre patience au développeur. Il pourrait s’en lasser, être démotivé et décider régulièrement d’aller sur internet pendant ce temps. Mais puisqu’il y passera certainement plus de 15 secondes c’est au final de nombreuses heures de productivité qui seront perdues.
Si l’on doit travailler sur des IHM, avoir deux écrans peut rendre la tâche beaucoup plus facile. Idem pour les retouches d’images, utiliser Paint au lieu d’un outil spécialisé pour cela rend la tâche plus fastidieuse.
Fournir à ses équipes le matériel et les outils les plus adaptés peut représenter un coût important à première vue. Mais un meilleur environnement de travail, rendra vos équipes plus heureuses sur le long terme. En répercussion, cet investissement pourra vous faire gagner une meilleure productivité.

10. Do you have testers?
Ici, Joel explique que si l’on n’a pas un ratio d’un testeur pour deux à trois développeurs on s’expose à une forte probabilité que, soit nos produits ne sont pas de qualité, soit nos produits coûtent extrêmement cher pour être de qualité. Cette déduction est moins évidente en France car la différence de coût entre un développeur et un testeur n’est pas aussi flagrante qu’aux Etats-Unis (il parle d’un coût de 100$/heure contre 30$/heure pour un testeur). À mon avis, il est effectivement important d’avoir des personnes qui font des tests. Que ce soit les développeurs eux-mêmes en changeant de rôle temporairement ou bien qu’il y ait une équipe de test spécifique. Le principal problème est qu’il est très difficile de recruter de bons testeurs. Il faut donc parfois se construire une équipe avec des profils mixtes pour pouvoir faire des tests croisés entre développeurs. Ce qui est important ici n’est pas que chacun ait un rôle définit et ne puisse pas en sortir mais que le rôle de testeur existe dans chaque équipe même de manière temporaire. Il vaut mieux, par exemple, avoir des développeurs qui testent un jour par semaine qu’aucun testeur ou même un mauvais testeur.
J’ajouterais également que l’existence d’une équipe d’intégration est un vrai plus. On a tendance à livrer son produit et oublier qu’il doit potentiellement interagir avec d’autres applications. Lorsqu’un échange est en échec, souvent chaque équipe accuse l’autre. Une équipe d’intégration permettra de tester ces interactions et vérifier que chaque partie a bien fait les choses.

11. Do new candidates write code during their interview?
Il est vrai que souvent lors des entretiens, nous avons droit à une batterie de questions techniques. Nous préparons donc nos entretiens pour pouvoir répondre correctement à toutes ces éventuelles questions. Il est également très rare d’avoir un test écrit. Que ce soit sur ordinateur ou sur un tableau, on nous demande rarement de coder ou d’écrire un algorithme.
Ce qui est en théorie absurde car nous sommes alors recruté sur l’hypothèse de correspondre au profil recherché. C’est pourtant l’un des rares métiers où cela est très fréquent. Joel prend l’exemple d’un magicien. En effet, on n’embaucherait pas un magicien sans avoir vu quelques tours. Alors pourquoi continue-t-on à embaucher des développeurs sans les avoir vus coder ? Cela permettrait d’éviter parfois de grosses surprises et donc la perte de temps à vos équipes.

12. Do you do hallway usability testing?
Ce point est très enrichissant. “Hallway usability testing” est le fait d’arrêter des personnes que vous croisez dans le couloir et leur demandez d’utiliser le code que vous venez de développer. En faisant cela avec cinq personnes, on devrait découvrir 95% des problèmes de conception de son code.
On peut également utiliser cette méthode pour les IHM. En prenant cinq ou six personnes et en leur demandant d’utiliser notre IHM, on découvrirait les plus gros problèmes ergonomiques. Cela nous permettra d’avoir une application plus facile d’utilisation et plus rapide à prendre en main pour les nouveaux utilisateurs.
Ce point est à mon sens le plus difficile à mettre en œuvre car comme le pair-programming, il est souvent ardu de faire comprendre sa valeur ajoutée à la hiérarchie, qui d’un œil extérieur ne verra que du temps gaspillé par cinq personnes alors qu’une seule aurait pu faire ce travail. Mais s’il est compris, vous arriverez certainement à sortir un meilleur produit.
D’une manière plus poussée, certaines équipes font ça sous forme de réunion informelle. En réunissant un panel d’un certain nombre de personnes issus de différents services de l’entreprise, on leur fait utiliser l’application et on récolte leurs avis et suggestions. Vous pourrez ainsi avoir une application qui sera utilisable par tout type de personnes qu’elles soient techniques ou non.

Conclusion
En conclusion, je dirais que ces 12 points sont effectivement importants. Mais d’autres points sont également à considérer. Certaines équipes atteignent un score très bas mais auront la volonté de l’améliorer. D’autres pourraient avoir un score moyen et seraient tentés de se reposer sur leurs acquis. Il faut donc également essayer de déceler cette part de volonté. Il sera plus facile pour une nouvelle équipe et une entreprise récente d’atteindre plus de 10 points, comparée à une société ayant de nombreuses applications à maintenir depuis des années. Mais ce qui compte également est votre implication. Si travailler dans un environnement qui applique un certain nombre de ces points est important pour vous. Si vous pensez que cela pourrait vous enrichir professionnellement. C’est à vous de faire en sorte que cette métrique augmente et d’en convaincre vos collègues. En quelques mots : soyez acteur de votre carrière.