Dev Back - Comment m'améliorer sur ces axes ?

Bonjour à tous !

Suite à mes 5 ans d’XP (au début en tant que dev fullstack wordpress / PHP / HTML CSS, puis dev back Laravel) et notamment mes 6 derniers mois (dev back Laravel), je souhaiterais passer à la vitesse supérieure concernant ces trois points :

• Tests : j’ai rencontré des ralentissements de livraison à "cause" des tests. Pas parce qu’ils ne passent pas ou que le code derrière n’est pas correct, mais parce qu’il faut à chaque fois réunir les données et leur cohérence pour pouvoir tester le code. Je parle des tests unitaires et de features (sortes de scenarii de tests unitaires, peut-être spécifiques à Laravel). Comment aller plus vite à ce niveau ? Je connais déjà certaines pratiques, mais je me demandais s’il n’y avait pas des outils / plugins permettant de gagner du temps, quitte à ce que ce soient des techniques du genre "liste sur post-its collé à l’écran des données et de leur relations pour qu’elles soient cohérentes entre-elles, pour telle et telle fonctionnalités à tester", ou même des outils impliquants Github Copilot ou je ne sais quoi.

  • Accessoirement : jusque-là je testais uniquement avec mes tests Laravel (unit et feature) et Postman. J’ai appris à mes dépens qu’il faut en fait tester le travail des collègues frontend car on peut te faire porter la responsabilité que "ça ne marche pas" alors que toi t’es juste dev back et que tes tests unit/feature/Postman fonctionnent bien.
  • Important : c’est bien de générer les données et correctement les lier entre elles mais encore mieux d’utiliser les données de production en dev. Le CTO de ma boîte actuelle aurait dû, je pense, en faire sa priorité (migration des données de l’ancienne prod vers la V2 du projet en dev). J’imagine que sur ce point, il n’y a pas spécialement de conseil à me donner malheureusement sinon de bien me renseigner durant les entretiens de recrutement.

• Organisation du travail : c’est propre à ma startup dont l’équipe tech voire produits est plus que restreinte et débordée, mais il y a eu des problèmes de communication en amont qui ont engenré des retards de livraison de mon côté. Par exemple des fonctionnalités à faire mais certains aspects clés qui avaient des conséquences techniques ont été oubliées en amont, donc j’ai dû les rajouter. Ou encore concernant certaines features on ne m’a jamais dit "tiens : pour faire ça, tu peux partir du travail que j’ai fait ici : XYZ" (même pas à chaque fois que je montrais l’avancement de mon dev). Ou encore : le CTO qui me donne des informations fausses (ou alors, éventuellement, bonnes mais très mal communiquées) ce qui me fait partir sur du dev plus long (donc retard de livraison). Je souhaiterais réduire la probabilité que cela arrive à l’avenir. Je précise que je communique (énormément) sur Slack, notamment sur mon avancée, et sur mes devs.

• Prise d’initiative : je suis dans une toute petite équipe startup avec 2 devs et demi (dont un CTO, qui est donc l’autre dev). J’aurais dû passer en force pour installer Sentry par exemple, ou alors pour écrire la documentation technique (inexistante à 90% - et d’ailleurs j’en pâtis car à chaque tâche je dois poser des questions métier ou technico-métier au CTO pour savoir quoi développer et comment). Mais si je l’avais fait, j’aurais pris du retard sur mes tâches ou l’aurais aggravé. Donc j’ai manqué de prise d’initiative. A l’avenir, que me conseilleriez-vous ?

Merci beaucoup !

• Tests : j’ai rencontré des ralentissements de livraison à "cause" des tests. Pas parce qu’ils ne passent pas ou que le code derrière n’est pas correct, mais parce qu’il faut à chaque fois réunir les données et leur cohérence pour pouvoir tester le code.

C’est le cas de beaucoup d’équipes que je connais. Pour commencer, il faut t’assurer que tu écris bien des tests fonctionnels (est-ce qu’en lisant tes tests tu comprends ce que fait la fonctionnalité ?).

Ensuite, la plupart du temps, ce ne sont pas les données en elle-même qui nous intéresse. Mais les propriétés du système. Essaie de te renseigner sur le Property Based Testing et de t’assurer que tu testes bien ce qu’il faut.

• Important : c’est bien de générer les données et correctement les lier entre elles mais encore mieux d’utiliser les données de production en dev.

Tout dépend des données de prod, mais c’est rarement une bonne idée : les données de prod peuvent être confidentielles (par ex, info personnelles) ou difficilement exploitables car bruitées. C’est plus simple de se mettre dans un cas précis pour faire ses tests.

Je souhaiterais réduire la probabilité que cela arrive à l’avenir. Je précise que je communique (énormément) sur Slack, notamment sur mon avancée, et sur mes devs.

Il existe pas mal de type d’ateliers pour aligner tout le monde et s’assurer que toute l’équipe a bien compris la même chose. C’est même l’objectif du Domain Driven Design stratégique (event storming, example mapping, etc.). Ou tout simplement des choses plus simples (et moins sympa) comme les three amigos.

Le Behavior Driven Development aide aussi énormément quand il ne se résume pas à écrire du given/when/then…

• Prise d’initiative : je suis dans une toute petite équipe startup avec 2 devs et demi (dont un CTO, qui est donc l’autre dev). J’aurais dû passer en force pour installer Sentry par exemple, ou alors pour écrire la documentation technique (inexistante à 90% - et d’ailleurs j’en pâtis car à chaque tâche je dois poser des questions métier ou technico-métier au CTO pour savoir quoi développer et comment). Mais si je l’avais fait, j’aurais pris du retard sur mes tâches ou l’aurais aggravé. Donc j’ai manqué de prise d’initiative. A l’avenir, que me conseilleriez-vous ?

Parles-en à ton équipe. J’ignore comment vous fonctionnez mais si vous faites des rétrospectives (ce que vous devriez faire, dans le cas contraire), c’est typiquement le moment d’en parler.

La façon dont tu codes peut aussi grandement t’aider : si tu fais en sorte que ton code se rapproche le plus possible du fonctionnel et qu’il est le plus simple possible, il devient plus facile à comprendre et nécessite moins de documentation.

Sinon j’ai (re)découvert le fait que j’adore conseiller les gens et leur apprendre des trucs (j’adore partager mes connaissances, plus exactement). Je souhaiterais savoir s’il existe des métiers mêlant développement/production et "enseignement/conseil", s’il vous plaît ? Peut-être du 50–50 par exemple voire du 75% de conseil/enseignement. Surtout qu’en ce sens j’ai eu plein d’encouragements des personnes avec qui j’ai fait ça (dans un contexte pro, c’était des devs juniors).

Le coaching technique/craft est un très bon mélange entre dev et conseil/enseignement. Ca demande une bonne base technique et une appétence pour l’accompagnement mais c’est plutôt cool (tant qu’on ne tombe pas dans le travers du coach dogmatique hors-sol)

Il est tard, je te répondrai demain plus en détails, mais je tenais à te remercier concernant le craft développent , je ne connaissais pas du tout.

Maintenant, à vrai dire, à part rechercher sur Google "offre emploi craft back développer" ou "offre emploi coaching technique back développer", je ne vois malheureusement pas trop comment trouver une boîte qui puisse m’offrir ça , car la plupart chercheront à ce que tous leurs devs soient uniquement placés sur la chaîne de production et non une chaîne mêlant production & enseignement/pairing de conseil/mentoring

Salut,

Évite de créer 2 sujets aussi proches stp. J’ai mis le second à la corbeille, c’est un sujet que tu peux aborder également ici.

Je n’ai de solution pour accélérer les tests, parce qu’écrire des tests, si c’est rarement compliqué, ça prend du temps de bien le faire.

ça doit dépendre beaucoup des fonctionnalités mais moi :

• Soit je suis chaud le jour J, je vois exactement quelles données de tests réunir pour écrire mes tests Unit et Feature Laravel, et ça va vite ,
• Soit pas en super forme et ça peut prendre des heures et des heures voire, en cumul, plus de 4h (+ rarement une journée)
• Concernant les tests Postman et sur l’application frontend : ça nécessite d’avoir l’esprit clair sur quelles données envoyées et de créer ces dernières en base de données.
• Quel que soit le type de test : il suffit que la feature implique des appels à une API externe pour que du coup il faille ajouter / lier des données dedans à la DB Laravel (mapping de données) et la mocker… Et ça rajoute encore du temps et de la charge mentale pour savoir comment et quoi réunir comme données de tests.

Du coup globalement ouais, si on fait la moyenne, je dirais que je peux passer 4h voire 6h. Rarement, 8h.

Après des fois je dois modifier le code du contrôleur (soit parce que je travaille en TDD, soit parce que je n’ai pas travaillé en TDD mais que le contrôleur n’est pas totalement correct (perso ça m’arrive plus rarement, en général je me débrouille bien) ).

N’existe-t-il pas d’outil ou autre faisant gagner du temps sur la partie "rassembler / lier les données pour faire passer les tests" ?

Concernant le fait qu’on me reproche de ne pas avoir testé l’application de mon collègue devfront :

en fait je suis dans une petite startup (1 alternant, un CTO back, un freelance front, et moi back), donc je trouve ça normal qu’il me faille tester l’app du dev front pour vérifier qu’il ait bien fait son taff. On a aussi un product owner mais apparemment c’est pas son travail.

@SpaceFox :

En effet, c’est bien moi qui définis les données de test. Mais imagine que certaines données sont dépendantes de valeurs d’autres données. Imagine aussi qu’en plus de ça, il faille mocker une API tierce car elle renvoit des données qui sont utilisées en guise de dépendances avec d’autres données. Comme tu peux le voir, tu as des relations dans tous les sens, et pour que la feature passe, il faut donc que telle donnée soit liée à telle valeur d’une autre donnée, et bien sûr avoir toutes les données qu’il faut.

C’est pour ça qu’il faut avoir l' "esprit clair" comme je le disais, pour savoir exactement quelles données, quelles valeurs, et quelles relations, utiliser pour faire passer les tests. Je parle de unit test, feature, Postman/Frontend (= fonctionnels si je ne m’abuse).

C’est cela que j’appelle « rassembler/lier les données pour faire passer les tests ».

C’est surtout ça qui prend du temps je trouve, car en soi écrire les assertions et valider les tests c’est assez rapide, quand le code back a bien été écrit en amont (en non-DD). En TDD, par définition, on procède par itérations.

Ce que tu décris là c’est des tests croisés dans le cadre d’une toute petite équipe (sinon on essaie que ce soit un dev back qui teste le boulot de ses collègues dev back, etc). Ça existe, mais c’est pas automatique, et surtout ça doit être planifié (avec le temps prévu pour et tout).

Pour le coup je parle :

• à la fois de tester l’ensemble de l’app en effet,
• mais aussi de tester l’intégration et l’utilisation qu’en fait mon collègue frontend des appels d’API que je lui ai préparés

En tout cas dans ma petite startup actuelle on m’a bien reproché le fait de ne pas avoir fait ces deux trucs (après, comme l’a dit @Jacen sur Discord, je suis le développeur le plus expérimenté côté back (devant moi il y a juste le CTO et le dev frontend freelance senior ; derrière moi : l’alternant). Donc voilà, je pense qu’il faut que j’assume ma faute de ne pas avoir pris le temps de tester le dev de mon collègue front, du moins dans ce contexte (mais ça aurait été bien qu’on = le CTO me dise explicitement de le faire).

@SpaceFox

Des tests eux-mêmes, qui n’ont pas les mocks aux bons endroits, ou bien qui manquent d’outils d’industrialisation .

Nous n’utilisons aucun outil d’industrialisation pour les tests (à part PHPUnit mais il n’en fait pas partie en fait je suppose). A quoi penses-tu ? Les mocks sont OK.

Les autres points sont OK aussi.

Par contre c’est la complexité du système le souci je pense, lequel nécessite de bien comprendre le métier et l’implémentation technique de ce dernier. D’autant qu’en base de données, certaines colonnes ont des noms très génériques du genre "model_type et model_id (polymorphiques), bank_account_id". Mais, selon la table d’appartenance, ou bien, au sein d’une table donnée, selon le contexte d’exécution du script PHP, ces champs ont une signification différente. Il faudrait une documentaion technique à ce sujet. Je découvre ces significations au cas par cas, tâche par tâche, car on ne me donne aucune formation etc (par contre je peux poser mes questions et le CTO y répond quand il a le temps, relativement rapidement malgré le fait qu’il soit débordé).

J’aurais aimé être plus encadré (une ou deux vraies formations, du pairing fréquent ou du moins régulier, et des code reviews, notamment pour les fonctinonalités de paiement, clés - mes demande de code reviews ont généralement été refusées par le CTO car il n’avait pas le temps de les faire).

Ton patron ne peut pas ne rien avoir organisé, ne pas avoir surveillé l’organisation et se pointer tard dans le développement en disant "Hé mais ces tests ni sont pas faits". Parce que s’il avait fait son boulot, il le saurait depuis longtemps que ces tests n’étaient même pas prévus

Exactement. Mais bon ils ne reconnaissent jamais leurs erreurs, ni avec moi, ni avec le dev front freelance actuel, ni avec les deux devs qui ont mis fin à leur période d’essai (dont un s’apprêtait à le faire mais a été pris de court par les patrons qui, eux, ont mis fin à sa PE).

ça marche. Après je pense qu’il ya plusieurs écoles, ceux comme @Jacen qui me diront "oui mais t’es dans une petite startup et tu es l’un des devs les plus expérimentés, tu dois dépasser tes missions de dev back", ceux comme @Nohar qui me disent "specialization is for insects", et @SpaceFox et toi-même @Gabbro qui êtes plutôt d’avis "non mais t’es dev back, le patron doit faire son boulot et te dire en amont si tu dois vraiment tester des trucs de ton collègue front".

En tout cas il est vrai que j’avais dit à mon collègue dev front freelance senior que mon contrôleur lui retournait une URL et donc qu’il fallait faire une redirection. Malgré cela il ne l’a pas fait (attention ça sonne comme un reproche mais pas du tout, il avait 10000 trucs à faire et il a des relations très tendues avec les patrons et le Product Owner, qui roule à 200% pour les patrons).

Merci beaucoup @SpaceFox

En effet cela n’avait pas été planifié, du tout.

Maintenant, à vrai dire, à part rechercher sur Google "offre emploi craft back développer" ou "offre emploi coaching technique back développer", je ne vois malheureusement pas trop comment trouver une boîte qui puisse m’offrir ça , car la plupart chercheront à ce que tous leurs devs soient uniquement placés sur la chaîne de production et non une chaîne mêlant production & enseignement/pairing de conseil/mentoring

Alors oui et non, parce que le terme "craft" ici fait référence au "software craftsmanship", qui est un mouvement, pas un nom de techno ou de méthodo. Autrement dit, si tu fais une recherche pour "offre emploi craft backend developper", tu pourrais remplacer le terme "craft" par "agile" ou "catholic" ou "socialist" que ça aurait le même impact : les boîtes où on a cet état d’esprit sont rarement¹ celles qui mettront le mot clé dans une annonce.

D’autre part, tu n’es pas obligé de te faire embaucher pour un poste qui soit spécifiquement "mentor" ou quoi que ce soit, encore une fois, c’est raisonner avec une idée bien trop rigide de la spécialisation : dans une équipe de dev, n’importe qui peut naturellement assurer un rôle de mentoring ou de conseil ou de formation s’il en a les appétences et que l’occasion se présente, et perso je considère que ça fait totalement partie de mon boulot d’ingé back de faire ce genre de truc quand il y en a besoin dans l’équipe. C’est la réalité du travail au quotidien qui compte, pas l’intitulé de ta position dans la boîte.

@SpaceFox On est tout à fait d’accord. Je trouve simplement que la formule est assez catchy à retenir, et que c’est le genre de chose qui aide pour adopter un état d’esprit donné. En particulier, la pensée "tiens, je viens de réagir comme un bousier, là", est plutôt efficace quand il s’agit de perdre les mauvais réflexes. Mais ça n’a pas de valeur synthétique de mon point de vue, c’est juste une catchphrase.

Attention tout de même avec ça. Prendre des initiatives ça ne veut pas dire imposer ses idées mais les proposer. Ensuite ça se discute et c’est implémenté si l’équipe accepte de le faire (et de le prioriser).

Il serait très mal venu de déployer un service sans prévenir le reste de l’équipe, ou alors suite à un refus de leur part. Ou encore après qu’on t’a dit que c’était une bonne idée mais pas le moment de faire ça car il y avait beaucoup de boulot à faire sur XXX (même si tu es personnellement en désaccord avec les priorités énoncées).

Dans le cas de Sentry en plus je pense que tu peux risquer gros puisqu’il s’agirait d’envoyer des données internes de l’application à un service externe, donc ça se fait avec l’accord des personnes en charge de gérer la sécurité de ces données.

Si tu es souvent force de proposition, tu seras reconnu comme un preneur d’initiatives. Surtout si tes propositions sont étayées (avantages & inconvénients), que tu formules facilement un plan de mise en place, etc.
Si tes propositions sont systématiques refusées, tu n’es peut-être pas à la bonne place pour t’épanouir.