Mes pires (ou meilleures) anecdotes en tant que développeur

Aujourd’hui j’ai décidé de partager avec vous mes pires ou meilleures (suivant le point de vue) anecdotes en tant que développeur, histoire de rigoler un peu. Je ne vais pas forcément vous parler de code, mais plutôt de situations dans lesquelles je me suis trouvé. Je vous préviens je vais vous raconter ma vie !

Une histoire de tableau…

Pour cette première anecdote, on va parler code et plus particulièrement d’une erreur que beaucoup de débutants font quand ils commencent le JavaScript. Pour le contexte, je travaillais dans une société spécialisée dans l’IOT qui développait, entre autres, pour le monde agricole, une balise équipée d’un GPS et d’un lecteur RFID.

Pour faire simple, cette balise permettait de scanner des étiquettes RFID associées à un produit phytosanitaire, d’enregistrer des positions GPS à intervalle régulier et d’envoyer toutes ces données sur un serveur qui traitait celles-ci et permettait de savoir sur quels champs les produits phytosanitaires étaient répandus. 

Pour la première version de notre solution, une étiquette ne pouvait pas être réassignée à un autre produit. On se dit donc que cela pourrait être intéressant de permettre cette réassignation tout en gardant un historique des produits assignés à une étiquette. Côté back, on développe cette fonctionnalité et l’on ajoute une route sur notre API REST qui attendait le payload suivant :

On avait donc en clé l’ID de l’étiquette RFID et en valeur l’ID du nouveau produit. Notre back était prêt il fallait maintenant s’attaquer au front. On venait d’embaucher un nouveau développeur front et on décide de le mettre sur cette tâche afin qu’il se familiarise avec le projet. Et par je ne sais quel moyen, il se retrouve à tester son code directement sur la base de données de production. Et là c’est la catastrophe !

Je vous montre à quoi ressemblait son code :

Vous ne voyez pas le problème ? Il a utilisé un tableau au lieu d’un objet. Vous pensez sûrement que ce n’est pas dérangeant et bien détrompez-vous ! Voici ce qu’il a envoyé au serveur de production :

Toutes les étiquettes RFID ayant un ID compris entre 0 et 9999 se sont ainsi retrouvées associées à aucun produit. Par chance, j’investiguais sur un souci de lenteur de notre base de données de production. J’étais en train de vérifier les logs et là je vois un tas de requêtes qui associe le produit null aux étiquettes RFID. Je vais tout de suite voir mon collègue qui s’occupe du front et je remarque qu’il travaille directement sur la base de données de production. Là, c’est la panique à bord ! Il y avait pour couronner le tout une démo importante chez un client et ses étiquettes ont été touchées par cette erreur.

Par le plus grand des miracles, j’avais fait un backup de la base de données de production quelques minutes avant pour investiguer en local sur le problème de lenteur. On a ainsi pu régler cette erreur sans que personne ne s’en rende compte.

Pour info, mon collègue avait eu le mot de passe de production sur le dépôt Git d’un projet utilisé comme POC et pensait que c’était celui du serveur de développement. 

Leçon à tirer de cette histoire :

• Ne confondez pas les tableaux et les objets en JavaScript ;
• Filtrer les données reçues sur vos API ;
• Arrêter de push sur vos dépôts Git des données sensibles telles que les accès à une base de données ;
• Créer un environnement complet de développement sur votre machine. Vous pouvez utiliser Docker pour faciliter cette mise en place.

Cette histoire se termine bien, mais j’ai déjà par mégarde effacé toute une base de données de production en pensant lancer une commande en local. On a perdu une journée de données. J’ai dû parser les logs pour extraire les données et les réinsérer en base.

D’emmerde toi !

Je vais vous raconter cette fois-ci l’histoire d’un projet sur lequel j’ai été amené à travailler qui m’a littéralement fait péter un câble. Le projet en question était le développement d’une application mobile pouvant se connecter en Bluetooth à un petit boîtier GPS destiné au monde du sport. Cette application permettait de récupérer les données présentes sur ce boîtier et de les synchroniser avec un serveur, mais également d’envoyer des données vers ce boîtier.

Il s’agissait d’une évolution du produit, puisqu’une première version existait déjà et permettait d’effectuer ces opérations, mais depuis un ordinateur en branchant le boîtier via un port USB et en utilisant le logiciel qui avait été développé pour cela. Le projet proposait pas mal de challenge et j’étais super motivé pour le commencer. J’étais loin de me douter de ce qui m’attendait.

Je fais l’analyse des différents besoins et je commence à avoir une bonne vision de ce que je dois réaliser. Viens le moment où je dois m’attaquer au protocole de communication et à la structure des données contenue dans les trames. Une trame ressemblait grossièrement à ça :

Ce n’est pas le sujet mais pour les plus curieux d’entre vous, voilà à quoi correspond chaque partie :

• Délimiteur de début : Il s’agit d’un flag permettant de détecter le début d’une trame ;
• Commande : Il s’agit du type de commande de la trame (par exemple récupération des données, ou suppression des données, etc.) ;
• Taille de données : La taille des données exprimée en bits ;
• Données : Les données en question (il pouvait y avoir plusieurs informations contenues dans ce bloc qui devaient souvent être extraites via des opérations de masquage) ;
• CRC : Le contrôle de redondance cyclique permettant de vérifier s’il y a eu des erreurs de transmission.

Je demande donc qu’on me fournisse le document décrivant les différentes commandes pour que je puisse avancer et commencer le développement. Et là malheur ! Le document était incomplet, la personne qui avait travaillé sur la première version avait quitté la société sans documenter correctement son travail. Il me manquait donc certaines informations notamment la trame concernant l’initialisation de la connexion autant dire la plus importante.

Je décide donc d’aller voir le code source de la première version pour récupérer l’implémentation du protocole de communication et comprendre comment fonctionne la trame d’initialisation. Ah si seulement c’était aussi simple… Je vous le dis ou pas ? Impossible de trouver le code source !

La société n’utilisait pas encore GIT ni SVN tout était stocké sur un NAS, mais aucune trace du code source. J’explique donc tout ça à mon responsable, que ça ne va pas être possible que je travaille dans ses conditions et qu’il faut retrouver le code source. Sa réponse ? Tu vas y arriver, je te rappelle qu’on doit livrer à tout prix dans un mois et demi. En gros d’emmerde toi !

Là je ne vous cache pas que je suis en panique. Je suis vraiment mal, je ne vois pas comment je vais faire et toujours impossible de mettre la main sur ce fichu code source. Et puis j’ai une idée, je décide d’installer le logiciel de la première version sur ma machine et je me dis que je vais utiliser un analyseur USB et voir les trames qui passent. C’est ce que je fais, j’arrive à voir les données qui transitent via mon port USB. Je suis super content, mais je déchante très vite, c’est d’une complexité ! Les mecs qui ont inventé le protocole USB sont des malades. J’essaie tout de même de comprendre le protocole USB pour extraire la donnée qui m’intéresse et au bout de plusieurs jours BINGO ! J’ai enfin compris et trouvé la trame concernant l’initialisation de la connexion.

Je la documente et je commence enfin à coder. Je fais mes tests unitaires, j’avance bien et je décide de tester avec un smartphone la connexion. Et là rien ! Ça ne fonctionne pas. Je vérifie mon code plusieurs fois, tout semble OK. Je deviens fou et je fais n’importe quoi dans l’espoir que ça fonctionne, mais rien n’y fait.

Je commence sérieusement à baisser les bras et j’ai qu’une envie c’est de tout abandonner. Mais le projet m’obsède j’ai vraiment envie de réussir. J’essaye donc de changer mon état d’esprit et je prends le projet comme un défi. Je me pose calmement et j’investigue méthodiquement pour voir d’où vient le problème. Lors de l’envoi de la commande d’initialisation de connexion, le boîtier GPS renvoie une réponse correspondant à une trame une erreur. En l’analysant, je remarque un détail, les bits de certaines parties de la trame semblent être inversés. Je commence à me renseigner sur ce « phénomène » et je finis par trouver la cause : le boutisme (endianness).

Pour faire simple, le boutisme désigne l’ordre dans lequel les octets sont placés. Il existe plusieurs conventions, dont deux qui sont les plus communes à savoir le gros-boutisme (big endian) et le petit-boutisme (little endian).

Le boîtier GPS attendait des trames stockées au format big-endian alors que j’envoyais celle-ci au format little-endian et inversement. J’applique donc la correction et cette fois-ci tout fonctionne ! Je ne vous raconte pas la satisfaction que j’ai éprouvée à ce moment et j’ai pu terminer à temps le projet. C’était sûrement l’un des projets les plus compliqués sur lequel j’ai été amené à travailler du fait que je n’avais aucune information, mais aussi l’un des plus enrichissants techniquement parlant.

Et pour la petite information, on a fini par trouver, par hasard, plusieurs mois après le code source de la première version. Il se trouvait sur une machine virtuel (virtualBox) présent sur un ancien PC perdu au fin fond d’un carton. Après cette histoire on a mis en place un serveur GIT et bien documenter tous nos développements.

Fakeman

Un jour, on devait présenter un POC à un futur gros client. Le POC en question était une balise qui remontait tout un tas des données sur un serveur et on avait des algorithmes qui traitaient celles-ci. Mon directeur R&D était sur place et moi au bureau pour vérifier que tout se déroulait comme convenu. Je pense que vous connaissez tous l’effet démo, cela fonctionne parfaitement en temps normal, mais quand vous devez faire une présentation au client plus rien ne fonctionne. Et bien nous… ce n’était pas du tout ça ! Rien ne fonctionnait, mais on fait tout de même une démo. On ne sait jamais sur un mal entendu cela peut se mettre à fonctionner.

Comme vous vous en doutez, la démo commence et comme il fallait s’y attendre rien ne fonctionne. J’appelle donc mon directeur, pour l’informer. Il me répond sereinement : « Ce n’est pas grave, je vais t’envoyer des messages et tu inséreras des données à la main en base de données ». Donc en gros là il voulait que j’insère de fausses données pour faire croire que ça fonctionne. C’est tout je m’exécute, mais c’est un gros merdier, car je dois insérer les données dans un ordre précis sinon ça fausse tous les calculs effectués par les algorithmes.

La démo se termine et mon directeur m’appelle et il me dit : « C’est bon nickel toutes les informations sont remontées ça marche super bien, tout s’est bien passé. J’ai vu avec le client on lui livre la solution dans 15 jours ».

Je lui demande si c’est une blague et s’il se souvient qu’il m’a demandé d’insérer de fausses données. Il ne voulait rien entendre, pour lui c’était bon, le client allait payer donc on devait livrer dans 15 jours. Bien entendu 15 jours après, une seconde démo du « produit final » devait avoir lieu (on n’avait pas du tout retravaillé dessus) et mon directeur m’a demandé de réinsérer de fausses données, j’ai refusé, je ne voulais pas être complice de ça. Et aussi parce que l’on m’appelait Fakeman au bureau !

La passion qui m’anime

Je commençais un peu à m’ennuyer dans le poste où j’étais et j’avais envie de voir d’autres choses. Je décide donc de postuler dans une société spécialisée dans le Cloud et on me propose un entretien. J’y vais et je suis accueilli par le lead developer. Il me fait passer un test technique qui se passe super bien. Il me présente ensuite le projet qui était super intéressant. On discute pas mal et il y a un bon feeling. Il voit que je suis motivé et intéressé par le projet. Il décide donc de me présenter l’équipe. Bref en gros l’entretien parfait !

Il me demande ensuite les raisons qui me poussent à vouloir quitter mon poste actuel et vient ensuite la fameuse question du salaire. À cette période je voulais juste changer de boulot pour travailler sur d’autres projets, je ne cherchais pas forcément à gagner plus. Donc je lui explique que je suis vraiment intéressé par le poste et que niveau salaire je souhaite au minimum avoir ce que j’ai déjà (pour être transparent, je gagnais 1800€ net par mois).

Là j’ai senti une gêne de sa part et il me dit : « Ok, je prends note, mais après tu sais c’est super ce qu’on fait ici ». Bref, je commençais à sentir le truc venir donc je lui demande directement si ça pose problème le salaire que je demande et là il m’a sorti cette phrase : « Tu sais, nous on ne bosse pas pour l’argent, c’est la passion qui nous anime et on recherche des gens qui ont ce profil. On ne pourra pas te payer plus que le SMIC, mais comme tu as l’air motivé et passionné, je pense que ça ne te posera pas de problème ». Sur le moment, je n’ai pas réagi, je suis resté pro et l’entretien s’est terminé.

Quelques jours après, je reçois un e-mail de la part du lead developer, m’informant de la chance que j’ai eue d’être pris et qu’une promesse d’embauche me sera envoyée dans quelques jours. Je lui ai répondu que malgré que l’entretien se soit bien déroulé et que le projet soit intéressant, le fait d’être payé au SMIC me posait problème, mais qu’on pouvait éventuellement en discuter. Et vous savez quoi ? Je n’ai jamais eu de nouvelle !

Avec du recul je suis bien content de ne pas avoir accepté. La passion est certes importante, mais on ne travaille pas non plus uniquement pour le plaisir et beaucoup trop d’employeurs jouent sur notre « passion ».

Pour finir…

J’avais envie de partager avec vous ces petites anecdotes et je vous invite à faire de même en commentaires. Cet article est différent de ce qui se fait d’habitude, mais ne vous inquiétez pas, on se retrouve bientôt pour un article un peu plus classique.

Mes formations

Markdown de A à Z : créer du contenu clair et professionnel

Apprends à ecrire de la documentation propre, lisible et professionnelle grâce au Markdown, du niveau débutant à avancé.