Développeur web professionnel : Qu'est-ce que cela signifie ?

Block title
Block content
Développeur web professionnel : Qu'est-ce que cela signifie ?

Comment pouvez-vous devenir un développeur professionnel et satisfait de votre travail ? Au début, nous étions épuisés et irrités mais heureusement nous avons réussis à changer. Se créer une liste de règles pour sois-même est le mécanisme de base pour sortir de ce cercle vicieux de la production à outrance. Je partage avec vous donc ces quelques lignes. 

Profiter de la période estivale pour se poser ce genre de question est le bon moment, surtout qu'à l'ére du Post-Covid beaucoup de choses changent en même temps, et il faut savoir comment d'adapter à ces changements... 

Misérables et sans vie

Quand j'ai commencé à travailler en tant que développeur web, j'étais heureux. Cela dit, c’était seulement au début. Après un certain temps, j'étais épuisé et irrité. Malheureusement, je m'y suis habitué, et quand on gère avec soi une équipe de personnes on entraîne avec nous toute l’équipe.

Je me suis habitué à rentrer tard,
Je me suis habitué à tout faire pour respecter les délais,
Je me suis habitué à corriger beaucoup de bugs et à déboguer tout le temps,
Je me suis habitué aux clients en colère,
Je me suis habitué à programmer rapidement et à laisser des trucs pour plus tard,
Je me suis habitué à mon mauvais code et à mes mauvaises pratiques,
Je me suis habitué à l'espoir qu'un autre projet sera différent,
Je me suis habitué à toutes ces choses. Je pensais que nous tous, ingénieurs logiciels, nous y étions habitués et que cela faisait partie de la vie de chaque développeur. Pourtant, je ne pouvais pas me tromper davantage.

Devenez plus professionnel

Je voulais un changement. Je voulais faire les choses différemment, changer le statu quo. Ensuite, j'ai trouvé le livre « Software Craftsman » de Sandro Mancuso et c'est devenu mon point de départ.

J'ai lu quelques lignes et je ne pouvais pas y croire. Ce mec écrivait sur moi et sur ma propre situation. J'étais tellement excité que j'ai lu tout le livre en quelques jours. Depuis lors, tout est devenu totalement différent.

J'ai fait beaucoup de changements dans mon approche du client et du projet et je me suis presque débarrassé de toutes les mauvaises habitudes auxquelles je m'étais habitué. J'ai créé une nouvelle mentalité et une sorte de liste de règles pour moi-même que je souhaite partager avec vous. Si vous avez les mêmes problèmes que moi, vous trouverez peut-être ces réflexions utiles.

« Je ne suis pas un programmeur génial. Je suis juste un bon programmeur avec de bonnes habitudes » Kent Beck

0. Il ne s'agit pas de vous

C'est la chose la plus importante et la plus facile à oublier. Pourquoi faisons-nous ce que nous faisons ? Parce que quelqu'un a besoin d'un logiciel et veut le payer.

Très souvent, nous nous considérons comme la personne la plus importante parmis toutes les personnes qui sont autour du projet et nous considérons chaque personne comme une personne qui nous dérange y compris le client.

Pourquoi ? Je suppose que c'est parce que nous nous soucions souvent le plus de nous-mêmes et de notre propre confort. C'est idiot ! Nous devons comprendre que notre travail ne nous concerne pas, il concerne notre client.

Nous devons faire tout notre possible pour les aider à gagner de l'argent via les applications que nous créons pour eux. Nous devons nous soucier du projet. Nous devons prendre nos responsabilités et nous rappeler que nous sommes là pour les clients et non pas l'inverse.

La création d'une application est un service comme tout autre service. Mettons-nous à la place du client.

Qu'attendons-nous quand nous allons au cinéma ? Ou lorsque nous allons au restaurant ? Tout ce que nous voulons, c'est être bien traité, obtenir de bons conseils et recevoir de l'aide. Nous voulons ressentir que quelqu'un se soucie de nos problèmes et de nos besoins plutôt que de simplement gaspiller notre argent. Alors, faisons de même pour nos clients.

Le zéro ici en tant que nombre du point n'est pas juste parce que nous sommes des développeurs et que nous comptons à partir de zéro. Cela signifie que la compréhension de ce point est une règle de base pour appréhender toute autre règle.

1. Dites non et soyez honnête ! 

Imaginons un appel avec un client. C'est juste un appel parmi d’autres que nous faisons une fois par mois. Nous lui disons ce que nous avons fait en lui montrant la démonstration et à la fin il est content. Nous devons maintenant parler de la prochaine fonctionnalité supplémentaire qu'il souhaite que nous implémentons. Le client nous dit « Les gars, je veux avoir la fonctionnalité X et Y dans mon application. Cependant, j'en ai besoin pour dans un mois ».  

Alors que cela n’est faisable que dans au moins deux mois sachant que nous avons implémenté des fonctionnalités similaires dans d’autres projets, nous réfléchissons et nous hésitons à répondre. 

Le client insiste « Allez les gars ! Je sais que vous pouvez y arriver ! J'aurai une réunion très importante ce jour-là et beaucoup d'argent en dépend. Je compte sur vous ».  

C'est alors que nous disons la pire chose que les développeurs peuvent dire « Nous pouvons essayer... »

Au cours de ce mois, vous serez de plus en plus épuisé. Vous resterez au travail tard et consommerez beaucoup de café. Après un mois, assis dans cette même pièce, vous serez gêné parce que vous enverrez à votre client une m***e et que vous devrez agir comme si c'était un bon logiciel qui représente le mieux que vous puissiez faire. Votre client apportera ce « logiciel » à sa réunion et la démonstration ne se passera pas bien. Ce client reviendra et il sera furieux. Tout le monde, y compris votre patron, vous regardera en pensant « Pourquoi a-t-il proposé une telle foutaise au client ? Est-ce un bon développeur ? » et vous serez déprimé.

Malheureusement, le contenu de cet engagement est écrit à l'aide d'encre invisible. Donc, tout ce que nous voyons, c'est un papier vierge. Nous les examinons et nous le signons : « Oui, nous pouvons essayer ». 

Que signifie exactement « essayer » ? Si vous ne perdez pas votre temps au travail et que vos responsabilités sont principalement liées à ce projet particulier, cela signifie juste deux possibilités :

  • Vous ferez beaucoup d'heures supplémentaires. 
  • Vous coderez rapidement.

À cause du premier, nous cesserons d'être productifs après un certain temps. Cela signifie que nous ne pouvons pas faire des heures supplémentaires tout le temps. Ensuite, nous arrivons au deuxième point concernant le fait de coder à la hâte. Le « codage » est un grand mot surtout si nous allons essayer de corriger bogue après bogue. Le « codage » est un grand mot car nous essayons souvent de restreindre les codes non lisibles. 

Nous allons sûrement manquer de temps donc les risques d’erreurs vont s’accumuler dans notre code. Puis, nous découvrirons que ces erreurs vont se multiplier. Ainsi, les heures supplémentaires et le codage fait à hâte deviendront notre lot quotidien jusqu'à ce que nous atteignons la date limite.

Puisque nous savons toutes ces choses, pourquoi faisons-nous les mêmes erreurs encore et encore ? Je suppose que c'est parce que, à chaque fois, nous commençons à croire à cette estimation irréelle en se disant « Ça va être difficile. Nous n'avons jamais implémenté ces fonctionnalités en un mois mais cette fois sera différent »

Nous sortons de la pièce et nous commençons à travailler. Après environ deux semaines, nous commençons à réaliser que quelque chose ne va pas parce que nous sommes toujours au milieu de la première fonctionnalité et nous accélérons donc le rythme en restant de plus en plus tard au travail et en codant de plus en plus vite. 

Que pouvons-nous faire pour que cela ne se reproduise plus ? Dire tout simplement non ! 

« Non ! N'essayez pas ! Faites le ou ne le faites pas. Il n'y a pas d'essai. » Yoda 

Écoutez Yoda ! Qu'est-ce que cela signifie dans la pratique ? Revenons à la conversation avec le client. Cette fois, nous dirons non en s’obligeant à être courageux !

  • Le client: « Allez les gars ! Je sais que vous pouvez y arriver ! J'aurai une réunion très importante ce jour-là et beaucoup d'argent en dépend. Je compte sur vous » 
  • Vous: « C'est également très important pour nous. Cependant, si nous vous disons que nous y arriverons d'ici le mois prochain, nous vous mentons. Ces deux fonctionnalités ne peuvent pas être entièrement réalisées mais nous pouvons faire la première ou la seconde entière. Nous pouvons même faire les deux mais sans aucune logique et vous proposer juste la visualisation et les animations tandis que le reste sera codé en dur. De quoi avez-vous le plus besoin pour cette démonstration ? » 

Boom ! Voilà à quoi cette conversation devrait ressembler ! Même si nous ne savons pas combien de temps ces deux fonctionnalités prendront, nous pouvons simplement demander quelques heures pour faire une estimation et rappeler le client avec des suggestions.

Croyez-moi quand je vous dis que les clients vous feront davantage confiance si vous dites non car cela signifie que vous vous souciez du projet. Chaque client veut connaître la vérité et veut connaître chaque obstacle car cela va l’aider à planifier les prochaines étapes et à réagir en conséquence.

Alors, soyez honnête avec vos clients.

2. Gardez le code propre ! 

« Le code est le reflet de votre âme. Réfléchissez dans quel état vous voulez que votre âme soit. » Moi :-)


Disons-le clairement depuis le début : le code propre n'est pas seulement le code que je comprends mais le code que je comprends en un seul coup d'œil ! Il existe une différence subtile entre la compréhension et la lisibilité. Cependant, je ne veux pas écrire sur les règles du code propre car ce n'est pas le sujet de cet article.

La question est la suivante : Pourquoi devrions-nous garder le code propre ? Encore une fois, parce qu'il ne s'agit pas de nous. Il est assez rare que nous travaillions sur un projet seul et c’est justement pour cette raison que nous devons faire tout notre possible pour écrire le code de manière à ce qu'il soit facile à lire pour les autres développeurs de notre équipe. 

Même si nous travaillons seuls, nous devons penser aux développeurs qui maintiendront ce code. Faites-en sorte qu’il n’y ait aucun code illisible car il risque de se multiplier. 

Nous avons tendance à considérer chaque application comme la nôtre mais elles ne le sont pas. Chaque ligne de code que nous écrivons n'est pas la nôtre car en réalité elle appartient à notre client. Nous ne devons pas nous en tenir au code et à nos solutions. Plus encore, nous ne devons pas faire confiance à notre propre code ! C'est pourquoi nous avons besoin de révisions de code et de programmation en binôme. Nous nous plongeons souvent trop profondément dans le problème. Par conséquent, nous ne prenons pas de recul et nous finissons par compliquer le code.

La même chose s'applique à la propreté du code. Nous pouvons penser qu'il est propre mais en vérité nous le comprenons seulement parce que nous l'avons écrit depuis un certain temps et ce n'est pas la même chose. Nous devons être ouverts d'esprit pour voir cela et être prêts à voir si quelqu'un d'autre peut nous donner son avis concernant l’amélioration de la lisibilité du code. 

3. Ne soyez pas une grenouille bouillante et gardez la température au plus bas 

Dans le livre « Pragmatic Programmer », il est dit :

« Nous n'avons jamais vraiment tenté le coup. Cependant, on dit que si vous prenez une grenouille et la jetez dans l'eau bouillante, elle sursautera pour en sortir. Cependant, si vous placez la grenouille dans une casserole d'eau froide, puis la chauffez progressivement, la grenouille ne remarquera pas la lente augmentation de la température et restera en place jusqu'à cuisson ». 

Dans cette métaphore, nous sommes la grenouille, l'eau est notre projet et chauffer la température c’est prendre soin de nous-mêmes et rien d’autre. Permettez-moi de donner quelques exemples :

  • Lorsque nous sommes totalement inactifs lors de nos mises au point quotidiennes et que nous ne sommes pas intéressés par ce que nos collègues disent, ni par les problèmes auxquels ils font car nous pensons que cela ne fait pas partie de nos tâches, alors nous chauffons l'eau.
  • Lorsque nous n'avons pas compris quelque chose lors de l'appel avec notre client et que nous n'avons pas demandé plus de détails en comptant sur les autres membres de l'équipe pour le comprendre, alors nous chauffons l'eau.
  • Lorsque nous faisons tout à notre manière, malgré le reste des priorités ou toute sorte de disposition déjà prise, nous chauffons l'eau.

Et ainsi de suite… 

Nous pouvons imaginer les conséquences que ce type d'attitude peut engendrer ; un client en colère, une mauvaise ambiance dans l'équipe, des délais inatteignables, un manque de connaissances sur le projet et bien plus encore. Nous ne devons donc pas agir de cette façon.

D'accord, mais comment être sûr de ne pas chauffer l'eau ?

Écoutez

Écoutez ce que les autres disent. C'est aussi simple que ça. Soyez actif pendant les réunions ; posez des questions et faites savoir à l'équipe que vous vous souciez de ce qu'ils font et de leurs problèmes tout en étant prêt à aider. Il en va de même pour les clients. Nous devons savoir ce qui se passe dans d'autres parties de notre projet juste au cas où. A supposer que l'un de nos collègues parte en vacances ou quitte tout simplement le travail, le délai restera le même et le travail devra être fait. Ainsi, écouter et être actif est la bonne approche à adopter si nous voulons rester connectés avec le projet et les éventuels problèmes qui peuvent arriver.

Utilisez des mots simples

N’utilisez pas des termes techniques tout le temps. N'oubliez pas que tous les membres de l'équipe ne sont pas nécessairement des techniciens. Par exemple, les graphistes ou encore les testeurs ou les clients. Chaque fois que nous oublions cela, nous chauffons l'eau pour quelqu'un d'autre dans notre équipe. Bien sûr, nous devrions nous attendre à ce que lorsque quelqu'un n’arrive pas à nous comprendre, il puisse poser une question. Cependant, combien de questions cette personne est-elle capable de poser ? Si nous continuons à parler comme si nous étions entrain de coder, cette personne va surement cesser de demander et elle se sentira mal à l’aise à cause de nous.

Nous devons trouver un fil conducteur et utiliser un langage qui puisse convenir à tout le monde dans la pièce. Sinon, nous chauffons l'eau pour quelqu'un d'autre.

Je suppose que nous utilisons souvent le langage technique parce que nous sommes fatigués et honteux. Habituellement, nous sous-estimons les tâches en pensant que chacune d’elle est assez simple. Combien de fois une tâche a-t-elle été estimée durer plusieurs heures et pourtant nous nous sommes retrouvés à la faire pendant quelques jours ? Ces tâches s'avèrent souvent plus difficiles que prévu. Parfois, le simple débogage prend du temps alors que la solution elle-même est pourtant très simple. Dans ces situations, notre motivation en prends un coup.

Devant le client, le chef de projet ou même l'équipe de développement, nous utilisons des mots compliqués pour éviter de leur faire savoir que cette tâche s'est avérée très simple au final mais qu’elle nous a quand même pris beaucoup de temps. Malheureusement, nous chauffons l'eau en faisant cela. Soyez honnête avec l'équipe ! Cela peut être le déclencheur qui permet à tout le monde de changer d’attitude. 

4. Vous n’allez pas en avoir besoin alors faites seulement ce qui doit être fait

Tu n'en auras pas besoin.

Combien de fois nous faisons des choses dont nous pensons avoir besoin plus tard ? Combien de fois compliquons-nous le code car une solution prend trois lignes de code au lieu de huit lignes ?

Lorsque nous devons effectuer une tâche qui dit : « L’utilisateur voit exactement trois images avec des descriptions en dessous » mais nous lisons la phrase de cette façon : « L'utilisateur voit exactement trois images ». On interprète « exactement » en pensant que cela va probablement changer à l'avenir. La tâche nécessite des photos mais je suis sûr que des vidéos sont en route, nous devons donc nous y préparer. Pour l'instant, l'utilisateur ne fait que « voir » mais qu'en est-il des clics et autres événements ? Soudain, cette tâche semble plus difficile que nous le pensions parce que nous l'avons compliqué !

Faites ce qui doit être fait. Rien de plus et rien de moins. Si le code est propre, vous ou vos collègues n'aurez aucun problème à le modifier plus tard si la fonctionnalité se développe.

J'ai remarqué que nous sommes fiers de nous si nous transformons cinq lignes de code en une seule même si on finit par compliquer le code. Si cette seule ligne de code est complètement illisible, nous devons la réécrire à nouveau sur cinq lignes. Nous ne voulons pas de lignes de code illisibles dans notre projet, n'est-ce pas ? Je ne souhaite à aucun d'entre vous de travailler sur un projet dans lequel les développeurs transforment toutes les cinq lignes de code lisibles en une seule ligne intelligente mais illisible.

5. Employez le refactoring de code mais pas trop 

Le refactoring de code devrait être l'une des choses que nous faisons tout le temps. Je suis sérieux. Avant chaque nouvelle mise en œuvre, nous devons d'abord faire un peu de préparation et de nettoyage. Ça devrait être comme dans la vraie vie. Lorsque nous voyons des ordures sur le sol, nous les ramassons et les jetons dans la poubelle. Il en va de même pour le dîner ; nous faisons un peu de préparation avant de se lancer dans la cuisine y compris un peu de nettoyage.

La même façon de penser devrait nous accompagner lors de notre travail quotidien avec le code. Gardez tout propre et retirez chaque petit bout de saleté. Faites-le immédiatement car chaque « plus tard » est un nouveau problème en perspective. Il est très important de ne pas s'arrêter juste après avoir compris le code mais de le remanier si nous ne l'avons pas compris en un seul coup d'œil. Nous devons le rendre plus lisible pour les autres. Grâce à nous, ils ne perdront pas autant de temps à essayer de le comprendre.

Néanmoins, nous devons être pragmatiques. Nous ne devons pas tout refaçonner à chaque fois. Le refactoring de code dans des endroits qui changent beaucoup ou dans des endroits où nous devrons probablement ajouter quelque chose de nouveau est la bonne approche à adopter. Cela dit, prendre le temps d’améliorer une partie d’un code qui a été modifié pour la dernière fois il y a quelques mois, sans aucun bogue signalé, n'est pas une bonne idée.

Disons que nous avons écrit une fonctionnalité de connexion il y a six mois. Après ce temps, nous avons acquis plus de compétences. Par accident, nous avons regardé ce code et c'était terrible, nous n’arrivons pas croire que nous avons écrit ce code mais pourtant il n'y a aucun bogue signalé à l'écran.

Nous ne pouvons pas laisser ce terrible code dans le projet alors nous commençons à penser à le changer. Non ! Laissez-le ! Même si nous n'avons rien à faire, il ne faut pas toucher au code qui change très rarement surtout s’il marche sans problème. Pourquoi ? Parce que nous n'en avons tout simplement pas besoin. C'est une perte de temps et lorsque nous n'avons pas de tests unitaires, quelque chose peut mal tourner et le fonctionnement du programme peut être endommagé.

Il ne faut changer le code que lorsque nous devons ajouter quelque chose comme par exemple un bouton de connexion Facebook. Ensuite, vous devez préparer le code pour cette modification ou vérifier si cela peut être fait sans refactoring de code. Dans cet exemple, les changements dans la fonctionnalité de connexion se produisent une fois tous les six mois, nous devons donc être pragmatiques en premier lieu.

Conclusion

Devenir plus professionnel n'est pas une chose simple. Nous ne sommes certainement pas encore assez professionnel mais nous “essayons” (Attention Yoda va crier ici) tous les jours de faire de mon mieux. Évidemment, aucun de nous ne deviendra un développeur professionnel en une seule journée. C'est un long chemin à parcourir et de nombreuses erreurs à commettre. Chaque jour, nous pouvons faire quelque chose pour être un peu plus professionnels comme prendre la responsabilité du projet du client, être actif pendant les réunions, prendre en charge le refactoring de code etc. Chaque petite étape franchie est un pas de plus sur notre chemin vers le professionnalisme.

Commençons dès aujourd'hui !

Block title