24 Mar 2016

La différence entre un excellent, un bon et un mauvais développeur JavaScript

Ceci est la traduction d’un excellent article publié sur le site http://thefullstack.xyz/.

Merci à Dort Zur pour m’avoir donné son accord! Pour le suivre, c’est ici que ça se passe!

Tout d’abord, nous vous invitons à aller jeter un oeil sur les

Excellence is never an accident. It is always the result of high intention, sincere effort, and intelligent execution; it represents the wise choice of many alternatives – choice, not chance, determines your destiny.

Aristotle

Nous souhaitons tous êtres bons dans ce que nous accomplissons. Peu d’entre nous, en revanche, prennent le temps et font les efforts nécessaires pour faire de l’excellence une réalité. Etre excellent est un travail de longue haleine, et ce pour tout les métiers.

Mesurer le niveau d’excellence d’un développeur Javascript est difficile à réaliser.

Qu’est ce qui fait un excellent dev JS?

Il existe une multitude de critères pour nous guider dans notre réflexion.

La qualité de code, toujours délivrer dans les temps ou le nombre de bugs résolus sont des critères possibles. Aider les autres membres de l’équipe dans leurs taches peut aussi rentrer en ligne de compte.

Je pense cependant qu’aucun de ces critères ne nous donne une mesure représentative. Ecrire un chef-d’oeuvre de code mais provoquer un retard de 2 mois sur le projet parce qu’il nécessite de tout ré-écrire n’aide personne. Et nous savons tous que clôturer des tickets ou des tâches ne signifie pas grand chose.

Il y a tellement d’autres éléments à prendre en considération… Je suis certain que si je demande à 10 développeurs différents ce qu’ils pensent des qualités d’un excellent développeur, nous aurons 10 réponses différentes.

Je suis certain que vous pensez à votre propre définition à votre tour!

Je me suis remué les méninges sur cette définition pendant quelques-temps, alors j’ai décidé de me lancer et d’essayer et d’en établir une.

Retroussons nos manches

Je souhaitais trouver quelque-chose que tout les développeurs font. Je pourrais ensuite classer la performance des développeurs en se basant sur le comment ils le font.

Définir le niveau d’excellence d’une profession en ne mesurant qu’une seule activité est un raisonnement simpliste, mais je vais tout de même le faire 🙂

Voyons voir…

Je souhaitais être sûr que l’activité retenue pour cette étude soit adéquate. Une tâche que tous réalisent, mais qui me permette de séparer les pros des crétins.

Tous les développeurs écrivent du code horrible parfois

Soyons réalistes, nous savons, vous et moi, que de temps en temps, nous écrivons du code vraiment, vraiment dégueulasse. Honteux même. Du code que nous souhaiterions ne jamais revoir.

Nous avons tous nos raisons pour écrire cela. Je ne vais pas débattre sur le fait qu’elles soient valables ou non, l’essentiel est que nous en avons.

Avant que nous réalisions nos petites horreurs, nous définissons une liste de raisons. Ensuite on se bouche le nez pour éviter l’odeur de notre oeuvre, puis nous nous jetons à l’eau.

Quelques raisons communes pour écrire du code moche

1. Livrer à temps

“Pas assez de temps” est de loin la raison numéro une pour écrire du code peu soigné. Conjointement à la pression du client, un planning serré ou une livraison en cours sont en général des éléments nous poussant à passer à l’acte.

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

Le code existant est tellement horrible que vous ne vous sentez pas l’envie de faire le moindre effort à écrire quelque chose d’acceptable. Vous savez que vous ne pouvez rien faire pour sauver ce code d’une implosion inévitable et imminente.

3. “J’ai juste besoin de faire ça et d’avancer le reste”

En temps que développeurs, nous nous retrouvons parfois à coder en terrain étranger. Imaginez que vous désirez supprimer quelques lignes de code sur un projet autre que le votre. A priori, pas quelque chose d’assez conséquent pour ennuyer qui que ce soit.

Le type qui bosse sur le projet est actuellement en congés. Evidemment, personne d’autre n’est disponible pour relire le code. Vous procédez aux désormais célèbres commit et push, puis allez poser un cierge (Ou deux. Voir trois. N’oubliez-pas la monnaie dans le tronc) en espérant qu’il y ai assez de TU pour vous garder en sécurité.

Soyons réalistes !

Donc, nous écrivons tous parfois ce type de choses. Est-ce que cela fait de nous de mauvais développeurs?

Bien évidemment, non. Comme nous le faisons tous par moment, cela ne signifie RIEN.

Cependant, au fil des ans, j’ai pu établir quelque-chose d’étonnamment vrai au sujet des développeurs.

La manière dont nous nous comportons quand nous écrivons ce code pourri est le test ultime pour mesurer la compétence d’un développeur.

C’est étrange, mais c’est vrai. Soyez conscient du fait que le code que vous écrivez maintenant est horrible, et que les actions que vous menez maintenant pour éviter les ennuis futurs, en disent long sur votre manière de coder et sur comment vous traitez le code d’une façon plus générale.

Quel est le rapport entre un code pourri et la mesure de la compétence d’un développeur?

Énorme!

Prenons Ron comme un exemple. Ron écrit une m** aujourd’hui. Ron n’en est pas content. Un sacré désordre avec un héritage sur 5 niveaux empêche Ron de modifier une seule ligne de code sans tout casser.

Ron bypasse le souci en écrivant du code vraiment, vraiment dégueulasse. Ah, tout le monde est content parce qu’il a livré à temps. Tout le monde, sauf Ron.

Il va trouver son chef d’équipe et lui parle de ce qu’il vient de vivre. Ensembles, ils vont revenir sur le souci et regarder comment le corriger. Ils ont décidé que casser l’héritage pour un modèle à plat est la meilleure option.

Ron lui demande ensuite de lui allouer du temps pour implémenter la refacto décidée.

Roger a aussi écrit un code dont il devrait avoir honte aujourd’hui. Il signale à son collègue qu’il a écrit un hack dégueulasse pour bypasser un héritage sur 5 niveaux. Il a placé son code, et livré à temps.

Roger était très content de lui même, pas d’action complémentaire à prévoir.

Les 4 types de développeurs Javascript

Vous pouvez observer l’attitude d’un développeur écrivant un code horrible et le diviser en 4 classes. Ordonnées. De mauvaise, à excellente.

Oseriez-vous me dire que vous n’êtes jamais rentré, à un moment ou un autre, dans l’une de ces catégories?

Barney – Un développeur mauvais JavaScript (malsain)

Barney se contrefout d’écrire du code de me***. La seule chose qui lui importe est de finir le job dans les délais. Rien d’autre ne compte. Si ça marche, ça marche.

Barney écrit du code horrible, qui parfois impact l’avancée complète du projet. Pendant que le code était en place, il a impacté tellement de choses qu’il oblige tout le monde à faire machine arrière. Barney n’a pas l’impression d’avoir besoin d’apprendre quoi que ce soit.

Il sait déjà tout ce qu’il y a à savoir sur Javascript dans l’optique de faire le job.

Bill – Un développeur JavaScript médiocre

Bill ne sais pas qu’il écrit un code horrible. Il suit les préconisations de son équipe et pense le faire bien, mais il ne prend pas le temps de comprendre l’architecture globale du projet et comment les différents composants interagissent.

Le résultat final, malheureusement, est un logiciel pour le moins instable et sur le point d’exploser.

Bill ne consulte personne avant de faire d’énormes choix en terme de design. Il pense avoir bon. Il a lu 3 articles de blogs il y a un an, qui ont depuis lors guidés toutes ses décisions.

Je dis souvent que me plonger dans le code de Bill est comme plonger en terrain miné. Un mauvais changement et tout vous saute au visage.

Roger – Un bon développeur JavaScript

Nous avons déjà croisé Roger avant. Il était alors complètement conscient d’écrire un code horrible. Il savait aussi quelle tête aurait du avoir le code si il en avait écrit un de qualité. Il se crachait simplement dans les mains et se lançait pour écrire ce code.

Le tord principal de Roger est qu’il n’a pas essayé de changer quoi que ce soit. Il a fait ce qu’on lui demandait, plutôt bien d’ailleurs, tout en préférant laisser les choses comme elles étaient sans faire d’effort pour les améliorer.

Ron – Un excellent développeur Javascript

Ron est un excellent développeur. Il doit tout de même écrire des horreurs de temps en temps.

Ce qui met Ron à part, est que bien qu’en train d’écrire un code douteux, il pense beaucoup à “comment” il peut faire pour que la situation ne se répète pas. Pas pour lui, pas pour quelqu’un d’autre. Ron se demande quel type de changements techniques sont nécessaires, et quelle méthodologie peut être changée, améliorée.

Ron s’appuie ensuite sur ces recherches et prend des actions pour faire changer les choses.

La dure et froide réalité

J’ai une confession à faire.

Je suis Roger.
Je suis aussi Ron.
Je suis sur que j’ai été Bill sans même le savoir, et plus d’une fois.

Je ne pense honnêtement pas avoir un jour agit comme un mauvais Barney, mais qui sait…

Nous regardons tous derrière pour avancer vers l’excellence. Parfois nous sommes médiocres, parfois nous sommes bons ou excellents. Nous essayons toujours de ne pas être mauvais.

C’est ce que l’on fait qui nous définit comme développeurs.

La vérité doit être dite. Le passage de médiocre à bon, demande à ce qu’un développeur acquiert plus de connaissances et d’expérience, entre autres choses. Pour faire le saut de bon à excellent, vous avez en revanche à changer une chose. Une seule.

L’attitude.

“Remember, 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

Share