Discussion :

[Invité]

Bonjour !

Je m'adresse aux chefs de projets/équipe et aux développeurs qui ont déjà eu a gérer d'autres développeurs pour avoir des retours sur comment faire progresser les gens, en gros sans les vexer ni passer pour un gros con qui sait tout (c'est TRES loin d’être le cas).

Petite mise en contexte : Je suis développeur web au sein d'une équipe de 3 et je me retrouve a être le référent technique par défaut a qui on demande d'expliquer les choses. Un des devs était la avant moi et la boite vient de recruter un junior. Mon souci c'est que le dev avec l'ancienneté est plutôt médiocre et a tendance a faire des spaghettis. Il dit qu'il fait de l'OO mais en réalité il fout juste ses spaghettis dans des classes. Le junior n'est pas non plus très bon (normal c'est un junior) mais ce qui lui fait défaut ce n'est pas la qualité du code en tant que tel mais la capacité d'abstraction. De manière plus générale, ils n'arrivent pas bien a suivre le fil d’exécution d'un programme, quel processus parle avec qui, les allers/retours entre client et serveur, l'asynchronisme (ca se dit comme ca? ), etc.

Les 2 sont de bonne volonté et je cherche des astuces pour leur faire passer ce plafond de verre mais en tant qu’autodidacte personne ne m'a jamais expliqué ces choses et du coup je ne sais pas du tout par ou commencer. Je n'ai pas vraiment de légitimité, ni par rapport a mon parcours, ni par rapport a l’ancienneté, ni par rapport a mon poste (je ne suis pas du tout le 'chef' de l’équipe) pour attraper un dev et lui dire "tu galères un peu".

Bref du coup je me suis dit qu'il serait intéressant d'avoir des retours d’expérience, des trucs a faire ou a ne surtout pas faire, et de manière plus générale un discussion sur comment progresser me semble constructive.

Merci

PS: j’espère avoir poste ça au bon endroit , n’hésitez pas a bouger la discussion si ce n'est pas le cas.

[DonQuiche]

Pour le junior il n'y a sans doute pas grand chose à faire à part laisser le temps faire son oeuvre : il s'habituera au code et deviendra plus à l'aise avec l'asynchronicité. Sauf si c'est vraiment un problème d'intelligence, auquel cas c'est sans espoir.

Cela dit c'est une bonne idée en général de chercher à simplifier les problèmes asynchrones, en particulier via une meilleure expression des séquences asynchrones. Plusieurs langages offrent aujourd'hui les mots-clés async/await pour cela. A défaut on peut toujours se tourner vers des "promises"/"futures" basés sur des lambdas, avec des mots-clés pour les chaîner ("then"). Pour les cas plus complexes (implémentation d'un protocole ou d'un agent), divers outils existent pour générer automatiquement des machines à états à partir de spécifications plus lisibles et rigoureuses.

Dans l'idéal nos codes devraient être si simples que n'importe quel idiot devrait pouvoir les comprendre. Cette quête éternelle réclame l'adoption de meilleurs outils et des séances de remise en cause du code existant.


Pour le senior, tu peux opter pour plusieurs approches :
* Prétendre que c'est un problème d'équipe, sans mettre en évidence son propre rôle. Mettre en avant une recherche collective d'amélioration de vos talents individuels. Par exemple via une prog en binôme chaque vendredi.

* Approcher le problème avec des données concrètes : métriques du code, et exemples avec un "avant" et un "après". Si le bénéfice est évident, ça peut être un moyen puissant pour l'éduquer. Tu peux aussi simplement venir le voir de temps en temps en proposant un changement donné, sans jamais évoquer un problème général de qualité du code.

* Organiser une discussion autour d'une certaine partie du code afin de rechercher collectivement comment le simplifier. Cela permettra ainsi de découvrir des arguments erronés ou obsolètes chez lui (obsession des performances datant des années 80), et de l'exposer à d'autres modes de pensée.

* Recommander de bons livres tels que "coder proprement" et autres livres du même auteur.

[Invité]

Coté asynchrone on utilise effectivement des promise (via axios) ainsi que .then (et .catch) et notre techno front c'est React/Redux donc tous les appels ajax sont dans un même répertoire et je pense bien lisible. Quand je parle de difficultés a suivre le fil, c'est plutôt qu'ils se perdent dans les imports ou les portées des variables, et se retrouvent a écrire du code pour tourner autour d'un problème alors qu'ils avaient une méthode disponible qui faisait le job.

Je pense qu'ils galèrent avec le langage, habitués de jquery ils ont beaucoup de mal avec JavaScript natif et encore plus avec ES2015. Du coup ils ont du mal a lire le code qui exploite les "nouvelles" notations comme la déconstruction ou les "fat arrow functions".

Merci pour les astuces, je pense que le code en binome est une très bonne idée dans mon cas

[DonQuiche]

c'est plutôt qu'ils se perdent dans les imports ou les portées des variables

Il serait intéressant de savoir pourquoi. Cela dit ce sont surtout des problèmes causés par votre mauvais outil (JS). Même si je présume qu'une hygiène rigoureuse et une connaissance intime de la base de code permettent d'y remédier. Je connais trop peu JS pour en être certain.

Existe t-il des outils pour y remédier (lint pour forcer bonnes pratiques ? outils pour automatiser les imports ?). Ou des bonnes pratiques que tu pourrais imposer ?

Du coup ils ont du mal a lire le code qui exploite les "nouvelles" notations comme la déconstruction ou les "fat arrow functions".

Cela semble étonnant car c'est trivial à lire. Je pense que tu n'as pas bien ciblé ou explicité leurs difficultés.

[Invité]

Je pense que je me suis mal exprimé. Ce que je veux dire par 'se perdre dans les imports et la portée des variables' c'est leur difficulté a lire le code et a comprendre comment tout s'imbrique. Un exemple récent, hier le junior m'a demandé de créer une simple page avec un appel a notre API pour voir comment je m'y prenais. Je lui ai dit j'allais juste le faire en commentant ce que je faisais en même temps et qu'il n'hésite pas a m'interrompre, et la plupart des questions étaient d'ordre "pourquoi on a accès a cette méthode" alors qu 20 lignes plus haut il y a un "import foo from path", ou "c'est quoi cet objet" en parlant de la déconstruction dans les paramètres d'une fonction, ou "pourquoi .bind(this)". Cela dit c’était constructif comme expérience et je pense que ça l'a aidé.

On développe from stratch donc il n'y a pas de connaissance du code a avoir ce qui rend la chose plus simple. J'ai mis en place une structure de fichiers assez simple a suivre et très standard dans le monde de React.

A mon avis je peux assez facilement dire au junior qu'il doit progresser sur sa compréhension du JS, surtout qu'il veut devenir un expert front-end. Il est bien ouvert d'esprit et tant que je suis pas idiot et que je lui aboie pas a la figure ça devrait passer. Je suis plus embêté pour le senior et pour le coup j'ai beaucoup de mal a déterminer quelles sont ses lacunes. A l'instant par exemple il vient de nous dire "on devrait se demander quelles opérations sont difficilement faisables dans des modales HTML, comme l'upload de fichier", ce a quoi le junior a répondu "une modale c'est juste une div on peut tout faire". Je flaire de très grosses lacunes sans pouvoir vraiment mettre la main dessus.

Je vais regarder pour intégrer JSLint a notre outil de build, je sais que ça existe mais je ne l'ai jamais utilisé.

[Luckyluke34]

Sur JS, je recommande Javascript : The Good Parts de Douglas Crockford (bouquin et vidéos : _https://www.youtube.com/watch?v=hQVTIJBZook) qui est une des références en la matière. Il a aussi un cours plus à jour des dernières nouveautés d'EcmaScript sur Pluralsight il me semble.

JSLint est très strict, ils vont avoir une masse de recommandations et bonnes pratiques à comprendre dès le début, mais pourquoi pas.

Sinon, pour un job qualifié, c'est pas déconnant non plus de suivre des formations de perfectionnement. Je pense à celles de Skills Matter par exemple. Après c'est à Londres, je sais pas trop ce qui existe en NZ.

[Mat.M]

Le junior n'est pas non plus très bon (normal c'est un junior) mais ce qui lui fait défaut ce n'est pas la qualité du code en tant que tel mais la capacité d'abstraction. .

la capacité d'abstraction c'est là toute la problématique ça fait l'épine dorsale d'un projet et ça ne s'apprendra jamais à l'école ni même dans les grandes Ecoles ( Polytechnique,école d'ingénieur sans vouloir troller )
Cependant en faisant des études après le bac on apprend à avoir de la capacité d'abstraction en principe.
Mais le risque c'est d'apprendre des théorêmes tout faits bref des patterns

Pour développer la capacité d'abstraction il y a un truc un peu à la mode c'est la méthode Montessori..mais ce n'est sans doute pas la panacée.
Le mieux c'est d'être créatif et de jouer aux legos

Ce que je veux dire par 'se perdre dans les imports et la portée des variables' c'est leur difficulté a lire le code et a comprendre comment tout s'imbrique.

ne pas comprendre l'imbrication de classe en étant tout juste embauché sur un projet info je comprends ; mais à la longue ne pas comprendre les principes de base de la POO là j'ai des inquiétudes


sinon je partage l'avis à 100% de DonQuiche, lecture de code croisée , instauration d'une métrique du code c'est là l'essentiel et c'est important

[Invité]

JSLint semble en effet trop stricte, je pense que je vais intégrer ESLint qui est beaucoup plus configurable même si ça prend un peu plus de temps.

La vidéo de Crockford date de 2009 j'ai peur que ce soit un peu vieux. Ça dure trop longtemps pour que je puisse la regarder au boulot donc je ferais ça chez moi pour être sur En tous cas ce sera un bon point de départ pour trouver des sources.

J'ai la chance de bosser pour une boite qui a une vision a long terme du coup je vais voir avec notre manager si c'est possible de consacrer les vendredis après midi par exemple (qui ne sont pas des plus productifs) pour que les devs se tiennent a jour et lvlup. Personnellement j'ai beaucoup utilisé les sites qui proposent des contenus vidéo (souvent payants), et si aujourd'hui ça ne m'apporte plus autant qu'au début ça m'a vraiment aidé a franchir le cap de la professionnalisation a l’époque. Je pense que je vais suggérer ce genre de choses.

Merci pour vos retours en tous cas !

[ovh]

Je pense que le mieux c'est de montrer l'exemple en faisant des revues de code le plus souvent possible. Et dans ces revues tu indiques le chemin diplomatiquement : "tu vois, en faisant ça et ça, tu gagnes en perf ou en maintenabilité", ou "pourquoi n'as-tu pas utilisé ça ou ça", etc. tu vois le genre. Quand tu détectes un problème, tu leur montres comment faire mieux.
Tu peux aussi proposer des ateliers de programmation en binôme avec toi, ça ne peut être que bénéfique.

[Invité]

Petit retour d’expérience après quelques semaines :
- Le linting est un échec cuisant qui a généré plus de frustration et de 'je suis nul' qu'autre chose.
- Le code en binôme est de loin ce qui a été le plus efficace même si ça prend beaucoup de temps, avec le junior on a "trouvé" un système ou je code et il m’interromps quand il veut et en 2 semaines je dirais a la louche qu'il me stoppe 5 fois moins qu'au début.
- Le code review avec le senior n'a pas vraiment fonctionné, il est sur la défensive malgré la tonne de diplomatie employée et il a pondu un système de login que je soupçonne très fortement d’être un c/c d'un tuto sur le net qui malheureusement complexifie les choses inutilement (aka. les 2/3 des méthodes sont la 'au cas ou') et quand je lui ai demandé de m'expliquer ce que faisait le code pour que je l'utilise et ça a été la levée de boucliers.

J'ai abandonné l'idée avec le senior, trop compliqué et trop risqué pour qqch qui n'est même pas mon boulot, en revanche l’expérience avec le junior est des plus plaisantes et je pense qu'on sortira grandi tous les 2 de cette pratique régulière.