Le jour où j'ai compris que je n'étais pas un (bon) développeur
Sur les réseaux sociaux, blog et autres publications, on parle très souvent de nos réussites (moi le premier). Aujourd’hui, j’ai décidé de vous parler d’un de mes "échecs" (notez les guillemets) récents : le jour où j’ai compris que je ne faisais pas du bon code.
Résumé d’un drame en trois actes.
Situation initiale : seul au monde
J’ai commencé chez mon client actuel (le groupe SeLoger) en octobre 2019. À ce moment, je remplace quelqu’un de mon ESN (WeScale) qui quitte ce client.
Ma mission consiste a évaluer la sécurité AWS des comptes, puis de proposer des solutions, voire les mettre en place.
L’un des piliers que je propose et développe (en repartant de ce que mon prédécesseur avait fait) est donc de mettre un IAM (Identity and Access Management) fort sur AWS.
Vu mon passé d’Ops/FinOps/Architecte, l’automatisation, la fiabilité et la vitesse d’exécution sont des critères importants.
De même, je ne veux pas créer un gouffre entre les équipes DevOps et moi et j’ai donc besoin d’un outil que tout le monde (ou presque) puisse prendre en main.
J’ai donc développé plusieurs outils, principalement en python, dont le job principal est de déployer des permissions et de faire des liens avec des utilisateurs, de manière automatisée.
Je commence donc l’onboarding des applications, et de 25 repositories exploitant ces permissions, on arrive au bout d’un an à plusieurs centaines.
C’est là que les choses commencent à se gâter…
L’élément perturbateur : le scaling
Je commence à percevoir les limites de ce que j’ai mis en place :
- Les permissions IAM ne sont pas optimisées, et sont parfois redondantes
- Je tape parfois des limites de tailles de policies AWS suite au point précédent (J'en ai d'ailleurs parlé dans le passé)
- Le déploiement des droits utilisateurs tombe parfois en timeout (et dure plusieurs heures !)
- Je dois ajouter des fonctionnalités, mais mon script est devenu un gros tas de scotch au fur et à mesure des patches
De là, mon constat : un refacto est nécessaire. Si je veux pouvoir continuer d’ajouter des fonctionnalités quand les nouveaux besoins se manifestent, il me faut une base de code remise à plat.
Je défends donc cette idée auprès de mon manager (client) qui comprend effectivement l’intérêt et me donne donc le go pour faire ce travail.
Tout seul, on va vite, ensemble, on va loin
Nous sommes à ce moment en octobre-novembre 2020. Ce refacto est donc dans mon backlog, et il est prévu que je m’attarde dessus fin décembre/début janvier.
Au début de l’année, du renfort qui arrive. Un de mes collègues de WeScale arrive sur la mission pour me prêter main forte. Ce dernier a un bagage plus teinté développeur, là où j’ai un bagage très teinté Ops de mon côté.
Je lui présente donc un peu ce que j’ai fait, et je perçois assez vite qu’il voit des choses complexes ou qui ne sont pas à l’état de l’art.
J’essaie de le rassurer en lui disant que je travaille sur une remise au propre de tout ça pour repartir sur des bases saines.
Je travaille donc sur mon refacto, et assez vite, je lui soumets donc en code review mon code. J’échange avec lui en partageant la PR, et là, je me rends compte que la réaction n’est pas celle que j’attendais.
En effet, en échangeant avec lui, je perçois que ça reste bien trop complexe, et pas vraiment "clean", même sur ma nouvelle version.
Sur le coup, mon ego en prend un coup, et je me braque un peu. C’était en soirée, on arrête là, en se disant qu’on en reparlera au calme le lendemain.
Bien entendu, le soir, je cogite. Je me rends assez vite compte qu’il n’a pas tort : je ne suis pas un développeur. C’est le constat que je fais, jusqu’à présent, j’ai scripté des choses pour répondre à des besoins, mais je n’ai jamais vraiment développé.
Le lendemain, en discutant, je lui explique donc ce point : j’ai besoin d’aide pour savoir ce que je dois (re) voir. S’en suit une (très) longue discussion dans lequel il m’expose certains points qui pour lui ne vont pas :
- Mon code est un seul script, ce qui empêche de l’étendre facilement
- Le code est dans le même repository que la configuration des projets, ce qui ne lui permet pas d’avoir son cycle de vie propre
- En l’état, on ne peut pas tester ce que j’ai fait
- Le découpage de mon code n’est pas clair, certaines fonctions ont une complexité trop élevée
Une fois de plus, grosse claque pour l’ego, bien que les propos soit bienveillants, ce que j’entends c’est "ton code c’est de la merde" (ce qui n’était pas du tout le discours de mon collègue).
Le dénouement : apprendre à développer
Je n’ai pas de honte à le dire, ça a été une période assez violente pour moi, j’ai en effet dû appréhender beaucoup de concepts de développement assez rapidement :
- Structurer physiquement mon code (structure des répertoires)
- Structurer fonctionnellement mon code (logique du code)
- Apprendre à packager proprement
- Apprendre la base des tests unitaires
- Basculer sur une logique d’objet
- Revoir l’algorithmie
Et j’oublie sans doute des sujets. De plus, je suis donc dans une grosse remise en question sur la qualité de mon travail.
L’autre point que j’ai dû apprendre est de faire du développement "partagé", que quelqu’un d’autre doit être en mesure de comprendre/reprendre. Jusqu’à présent, bien que je sois en équipe, je développais souvent pour les besoins de mes projets, en solo.
La semaine suivante, je relivrais une préversion de mon script, qui était devenu entre temps une vraie application python, avec son repository, son pipeline de test, des precommit, et un push sur un Nexus du paquet final.
J’ai senti dès lors que le positionnement de mon collègue avait changé. Déjà, nous avions validé ensemble (dans les grandes lignes) la logique du code, ce qui faisait que l’ensemble était de fait plus lisible. Ensuite, j’avais aussi pris en compte au maximum ses remarques, et j’avais même poussé certains points plus loin que ce qu’il m’avait indiqué.
La structure même du code était, même pour moi, bien plus pertinente, et je pouvais voir facilement comment l’étendre en fonction des besoins.
Après quelques aller-retour sur des points qu’il avait remarqués (wording, algorithme, axes d’amélioration du code, etc.), ma PR était validée, et nous poussions la nouvelle version de l’application (dont 95 % du code avait changé) en production.
En conclusion : ce que j’ai appris
Pour conclure ce billet, je dirais que l’un des points les plus importants que j’ai appris durant ces derniers mois, c’est qu’il n’y a pas de honte à ne pas savoir. Pour ma part, je suis dans une démarche d’amélioration continue, et j’aime apprendre de nouvelles choses. Je considère que c’est une grosse partie de la richesse de nos métiers : nous n’avons jamais fini d’apprendre.
De plus, j’ai aussi compris qu’on ne s’improvise pas développeur, il y a beaucoup de concepts à appréhender :
- Lisibilité du code
- Testing
- Algorihmie
- Complexité
- Documentation
- Développer aujourd’hui, mais préparer demain en ayant un code potentiellement extensible
Ce sont des points sur lesquels je suis encore en train de monter en compétence (notamment la partie test qui est loin d’être simple pour quelqu’un qui débute).
De plus, cela a changé aussi ma manière de développer, je commence à avoir le réflexe de créer quelques tests avant d’écrire le code associé, je découpe beaucoup plus mon code en petites fonctions atomiques qui n’ont qu’un rôle bien défini, j’essaie d’utiliser des structures optimisées en fonction de mon besoin et j’en passe.
Enfin, l’un des points importants est que la critique peut parfois faire mal, mais c’est ce qui permet d’avancer. À ce sujet, je partage d’ailleurs beaucoup de choses remontées sur le blog jesuisundev par Mehdi Zed :
jesuisundev
J’espère que ce billet vous a plu, et n’oubliez pas : l’échec, même temporaire, n’est pas une fatalité, c’est en faisant des erreurs que j’ai le plus appris pour ma part ! En soi, le code que j’avais fourni à l’origine n’était pas catastrophique, il répondait à mon besoin à l’instant T, mais il ne permettait pas de répondre aux besoins futurs.
Aujourd’hui, quand je regarde le code que j’ai fourni ces derniers mois, je sens bien que je ne suis plus au même niveau, et j’avoue que suis fier d’arriver un livrer un code bien plus propre et maintenable.
Comments ()