Traduction de l’article de Dor Tzur du 23 février 2016 sur le site thefullstack.xyz

«L’excellence n’est jamais un accident. Elle est toujours le résultat d’une intention forte, d’un effort sincère et d’une exécution intelligente. Elle représente le choix judicieux des nombreuses alternatives – Car c’est les choix, et non la chance, qui déterminent votre destin. »- Aristote

Nous voulons tous être excellent dans ce que nous faisons. Mais peu d’entre nous mettent le temps et l’effort nécessaire pour faire de l’excellence une réalité. Être excellent est un travail difficile, dans toutes les professions.
Mesurer l’excellence d’un développeur JavaScript est très difficile.

Qu’est ce qui fait un excellent développeur JavaScript?

Il y a beaucoup de critères que nous pourrions utiliser pour guider notre décision nous permettant de dire si un développeur est excellent ou pas : La qualité du code, le respect des plannings, le temps de traitement des tickets…. ne sont que quelques options. Aider les autres membres de l’équipe dans leurs tâches pourrait également être un critère à prendre en compte.
Je pense pourtant que rien de ce qui précède ne fournit une mesure précise de la qualité d’un développeur. Ecrire un chef-d’œuvre de code, mais retarder le projet de 2 mois parce que vous avez voulut tout refactoriser ne va aider personne, même pas vous. De même nous savons tous que fermer des tickets pout fermer des tickets n’a pas de sens.
Il y a beaucoup de variables à considérer et  je suis sûr que si je demande à 10 programmeurs différents ce qui d’après eux fait un excellent développeur, j’obtiendrais 10 réponses différentes.
Je suis certain que vous-même, aussi, en ce moment, vous pensez à votre propre définition de la mesure de la qualité.
Donc vu que j’ai du mal avec cette définition depuis un certain temps, j’ai décidé d’essayer de passer du temps à mieux analyser et comprendre.

“Down & Dirty”

Il me fallait trouver quelque chose que tous les développeurs font. Pour ensuite être en mesure de classer les performances d’un développeur basées sur “comment” ils le font.
Fonder la mesure de l’excellence de l’ensemble de la profession sur une activité est trop simpliste. Mais je vais le faire quand même ? et je vais essayer de vous rassurer sur le fait que l’activité que j’ai choisi est bonne. Celle-ci doit être une activité que chaque développeur fait, tout en gardant séparées les choses positives des choses bloquantes.

Tous les développeurs écrivent du code horribles parfois !
 

Avouons-le, vous et moi savons que de temps en temps, nous finissons tous par écrire du code vraiment horrible : Shameful Code. Code dont nous espérons que personne ne le verra jamais.
Nous avons tous nos raisons pour parfois écrire un code horrible. Je ne vais pas argumenter sur ce que sont des raisons valables pour écrire du code horrible, car nous en avons tous. Alors passons en revue notre liste de raisons.
Bouchons nous le nez pour ne pas sentir l’odeur du code  et allons y :

Quelques raisons communes pour l’écriture de code horrible

1. La nécessité de livrer à temps

“Pas assez de temps» est de loin la raison numéro une pour l’écriture d’un code horrible. L’Engagement pris vis à vis d’un client, un calendrier serré ou une version en attente sont tous des accessoires de la scène de crime.

2. Une goutte dans un océan de misère

Le code existant est si horrible que vous ne vous sentez pas de faire l’effort de réécrire quelque chose de décent. Vous savez qu’il n’y a rien que vous pouvez faire pour sauver cet horrible base de code et l’empêcher de s’effondrer sur elle-même à un moment donné.

3. «Je dois juste faire cette modification et passer à autre chose”

En tant que développeurs, nous nous trouvons parfois à coder sur des terres étrangères. Imaginez que vous deviez écrire ou modifier quelques lignes de code dans un autre projet.
Bien évidement la personne qui a la connaissance réelle de ce projet est en congé et personne d’autre n’est disponible pour la révision du code. Vous ‘Commitez’, Poussez’ la modification et priez qu’il y ai eu assez de tests unitaires pour garantir un minimum de sécurité et de qualité.

Getting Real

Nous avons donc tous écrit du code horrible. Est-ce que cela fait de nous tous des mauvais développeurs ?
Bien sûr que non. Puisque tout le monde le fait de temps en temps, l’activité elle-même n’indique rien de tangible. Cependant, au fil des ans, j’en suis venu à comprendre cette vérité surprenante sur les développeurs.

Le comment nous nous comportons lors de l’écriture d’un code horrible est le test décisif ultime pour mesurer la compétence d’un développeur.

C’est bizarre, mais c’est vrai. Être conscient que le code que vous écrivez en ce moment est horrible, et les mesures que vous prenez pour empêcher cela de se reproduire à l’avenir, en dit long sur la façon dont vous codez et la façon dont vous traitez le code en général.

Qu’est-ce que le code horrible a à voir avec la mesure de l’excellence d’un développeur ?

Tout !
Prenons quelques exemples :
Ron a écrit du code horrible aujourd’hui. Ron n’était pas content. Un satané problème d’héritage de 5ème niveau dans le modèle Backbone a empêché Ron de changer la moindre ligne de code sans tout casser.
Ron à contourné le problème en écrivant du code qui sérieusement est horrible. Mais tout le monde était content parce que Ron à livré à temps. Tout le monde … sauf Ron.
Ron a discuté avec son chef d’équipe à propos de ce qui est arrivé. Ensemble, ils ont fait des aller-retours sur la façon de résoudre ce problème. Ils ont décidé que la rupture de la chaîne d’héritage en modules composables plat était probablement le meilleur plan d’action.
Ron a ensuite demandé que du temps lui soit alloué pour lui permettre de mettre en œuvre le refactoring que lui et son chef d’équipe avaient discuté.
Roger a également écrit du code horrible aujourd’hui.
Il a expliqué à son ami développeur le hack incroyable qu’il a développé pour contourner le problème d’héritage de 5 ème niveau. Il a réussi à contourner l’ensemble de l’architecture, en plaçant son code au bon endroit, et donc à livrer à temps.
Roger était très content. Aucune action complémentaire est nécessaire.

Les 4 classes de Développeurs JavaScript

On peut prendre les attitudes des développeurs ci-dessus et les classer en 4 catégories : allant du mauvais à l’excellent.

Barney – Un mauvais développeur Javascript

Barney ne se soucie pas qu’il ait pu écrire du code horrible. La seule chose dont il se soucie est de faire le travail à temps. Rien d’autre ne compte. Si cela fonctionne, cela fonctionne.
Pourtant Barney écrit du code horrible qui empêche parfois les progrès de l’ensemble du projet. Même si le code fonctionne, il casse tant de choses sur son passage que c’est une catastrophe en terme de régressions. Barney ne se remet pas en cause et ne pense pas avoir de choses à apprendre. Il pense déjà tout savoir sur le JavaScript, suffisamment en tout cas pour faire avancer les projets convenablement.

Bill – Un développeur JavaScript Médiocre

Bill ne sait pas qu’il fait du code horrible. Il suit les conventions de l’équipe et les règles et donc pense qu’il fait tout bien. Mais il ne prend pas le temps de comprendre entièrement la structure de l’ensemble du projet et comment les différents composants interagissent.
Le résultat final, malheureusement, est un tas de code mal structuré et fragile.
Bill ne consulte personne avant de faire des choix d’architecture impactants. Il survole le sujet. Il a lu 3 articles de blog il y a un an qui guident ses décisions depuis.
Je dis souvent que se plonger dans le code de Bill et comme courir dans un champ de mine. Un seul faux pas et tout vous explose à la figure.

Roger – Un Bon développeur Javascript

Nous avons rencontré Roger avant. Complètement conscient du fait qu’il est l’écriture de code horrible. Il sait comment le code aurait regardé s’il écrivait bon code. Il se tapote sur le dos et se déplace sur l’écriture que morceau de code horrible.
principal défaut de Roger est qu’il ne cherche pas à changer quoi que ce soit. Il fait ce qu’il a été demandé de le faire et le fait bien. Mais Roger préférait laisser les choses comme elles sont au lieu de prendre le temps et faire l’effort de les changer.

Ron – Un excellent développeur Javascript

Ron est un excellent programmeur. Mais il écrire encore parfois du code horrible.
Ce qui distingue Ron est que pendant qu’il écriture le code malodorant, il pense à comment faire pour que la situation ne se répète pas. Qu’elle ne se répète pas pour lui, mais également pas pour quelqu’un d’autre non plus. Ron pense à quel type de refactoring sera nécessaire, et à quelles sont les méthodes qui doivent être modifiée ou améliorée.
Ron agit alors sur ses conclusions, en prenant des mesures pour mettre en mouvement le changement.

La dure vérité :

J’ai une confession à faire :

Je suis Roger. Mais je suis aussi Ron.

Et je suis sûr d’avoir souvent laissé des additions salées sans même le savoir à plus d’une occasion.
Honnêtement, je ne pense pas avoir jamais agi comme un mauvais Barney, mais qui sait.
Nous allons et venons tous sur un continuum d’excellence. Parfois, nous sommes médiocres, parfois nous sommes bons ou excellents. Toujours en essayant de ne pas être mauvais.
C’est ce ‘qui’ on finit par être la plupart du temps qui nous définit en tant que développeurs.
À vrai dire, le saut de médiocre à bonne exige d’un développeur d’acquérir plus de connaissances et d’expérience entre autres choses. Mais pour faire le saut de bon à excellent il suffit de changer une chose : l'<b>Attitude</b>.
Souvenez vous que :

“before you can be great, you’ve got to be good. Before you can be good, you’ve got to be bad. But before you can even be bad, you’ve got to try.” – Art Williams

Traduction de l’article de Dor Tzur du 23 février 2016 sur le site thefullstack.xyz