Vous avez donc déjà réussi à atteindre vos premiers objectifs de programmation, peut-être même à développer une application d’exemple pour deux. Génial ! Cependant, c’était un peu lent, et un développeur professionnel serait certainement beaucoup plus efficace. Votre question est donc maintenant la suivante : comment devenir plus rapide en programmation ?
Essayez d’obtenir un retour d’information le plus tôt possible
Si vous êtes un débutant, on peut supposer qu’il y aura de nombreuses façons d’améliorer votre code. Si l’application fonctionne comme prévu, il se peut que votre solution ait été un peu bricolée. Si l’approche est correcte, vous avez peut-être oublié d’appliquer un style de code (eslint, prettier, etc.) avant de vous engager. Ou peut-être avez-vous commis l’une des nombreuses petites erreurs lors de l’utilisation de Git, qui peut être aussi subtile que l’utilisation du mauvais temps dans votre message de validation.
Du point de vue de votre collègue senior ou de votre mentor, il est impossible de prévoir ce qui pourrait mal tourner. Vous devez soumettre votre production à un examen (Pull-Request), et c’est là qu’il est possible de corriger la direction dans laquelle vous vous engagez. Plus tôt vous solliciterez le retour d’information, plus rapide sera le processus. Par exemple :
- écrivez comment vous pensez que le problème peut être résolu avant de commencer à modifier le code
- dessinez les maquettes de l’interface avant de commencer à la construire
- créez une demande de fusion pour l’implémentation avant de mettre à jour tous les tests unitaires et e2e.
Il n’est pas nécessaire qu’une tâche soit entièrement terminée avant de demander une révision. La révision des choses est rapide, et si vous avez de la chance, vos collègues pourront réviser avant que vous ne passiez trop de temps à suivre le mauvais chemin. C’est une différence entre l’écriture et la lecture – je passe environ 3 ou 4 heures à écrire des articles, et c’est probablement 10 minutes de lecture pour vous.
Écrire vite ?
Ou plutôt écrire peu ? Votre travail consiste à résoudre des problèmes, pas à écrire du code. Si vous pouvez résoudre des problèmes rapidement (ou plus rapidement que vous n’en créez de nouveaux), alors vous faites bien votre travail. Le code que vous produisez fait partie du problème – il devra être revu, testé et entretenu pendant longtemps.
Les ressources d’apprentissage ont pour but de vous exposer aux concepts qu’elles tentent de vous enseigner. Dans le cas de la programmation, elles vous montreront un projet d’exercice ou une tâche et vous feront programmer pour le résoudre, sans vous demander si cela a du sens. Pour être performant dans votre travail, vous devez écrire du code uniquement s’il n’existe pas de meilleure solution.
Remettre en question toutes les demandes
Première étape : s’assurer que « ce qui est nécessaire » l’est effectivement. Parfois, vous recevez une demande d’ajout d’une fonctionnalité qui ne devrait pas faire partie du système ou du sprint. Ou bien il existe déjà une fonctionnalité dont l’utilisateur ou le collègue qui a rédigé le ticket n’a pas connaissance. Ou encore, la demande porte sur un élément « agréable à avoir », au lieu d’un élément vraiment important.
En bref, essayez de comprendre les exigences suffisamment bien pour être en mesure d’évaluer si elles sont vraiment nécessaires.
Les fournisseurs externes
En fin de compte, il n’y a aucun moyen d’éviter d’ajouter des fonctionnalités au système. La meilleure solution consiste à trouver un fournisseur externe qui fera le gros du travail à votre place. Par exemple
- un fournisseur de services infonuagique (cloud) pour transformer une adresse saisie en texte libre en un emplacement sur une carte
- une solution de paiement complète – pour les magasins en ligne ou physiques
- un service d’infolettre qui vous permet d’envoyer des courriels sans vous soucier des filtres antispam.
Les intégrations sont souvent un casse-tête, mais si vous trouvez un fournisseur avec une bonne API, vous pouvez gagner beaucoup de temps sur l’écriture et la maintenance de votre propre code.
Utiliser des bibliothèques tierces (NPM, Composer, Nuget, etc.)
Certaines tâches sont trop petites pour les abstraire de votre application et les obtenir d’un outil externe. Pour de nombreux besoins typiques et moins typiques, vous pouvez trouver une bibliothèque tierce qui vous aidera à les réaliser. Les bibliothèques s’accompagnent d’un compromis :
- elles apportent une solution à certains problèmes
- mais vous obligent à apprendre leur API
- et apportent parfois leurs propres problèmes
Si vous choisissez la mauvaise bibliothèque, vous risquez de souffrir énormément. Vous pouvez évaluer certains aspects d’une bibliothèque avant de décider de l’utiliser : la documentation, l’aspect du projet sur GitHub, les comparaisons avec d’autres options en ligne. D’autres aspects de la bibliothèque ne le sont pas autant : quel sera l’avenir de la bibliothèque et si elle est maintenue aussi longtemps que votre projet en aura besoin.
Le genre de choses que les bibliothèques nous fournissent :
- des méthodes pour opérer sur les dates
- des fonctions liées à l’argent – vous n’avez donc pas à vous soucier du résultat de
0,1+0,2 - la génération de graphiques
Réutiliser votre propre code
Vous commencez à manquer d’options. Mais avant d’écrire quoi que ce soit de nouveau, assurez-vous que cela n’a pas déjà été implémenté dans votre projet. Déterminez également si un cas très similaire dont le code existe déjà peut être réutilisé ici.
La réutilisation du code est délicate – elle vous fait gagner du temps lorsque vous utilisez le même code dans des cas d’utilisation connexes, mais elle crée des problèmes si vous réutilisez le code pour des cas sans rapport. Par exemple, l’addition et la soustraction fonctionnent de la même manière pour la température et l’argent, jusqu’à ce que quelqu’un introduise le support du zéro absolu. Vous ne voudriez pas que votre application plante dès que le compte passe en dessous de -273,15.
Écrivez du bon code
Lorsque tout cela échoue, écrivez aussi peu que nécessaire pour répondre au besoin, mais écrivez-le aussi bien que possible. Nommez les classes, les méthodes, les arguments et les variables de manière significative. Documentez le code. Écrivez des tests unitaires et quelques tests d’intégration. Ajoutez un message de validation qui explique ce qui se passe dans le code et pourquoi.
En bref :
Codez toujours comme si la personne qui finit par maintenir votre code sera un psychopathe violent qui sait où vous vivez.
Répétez l’ensemble du processus
Une fois que vous avez terminé la fonction sur laquelle vous avez travaillé, vous êtes prêt à aller au premier point et à recommencer.
Ne vous précipitez pas
Ne vous inquiétez pas, personne ne programme vite. Avez-vous entendu parler du mythe du développeur 10x ? Certains développeurs sont censés être 10 fois plus rapides que leurs pairs. Il existe peut-être quelques génies, mais je crains que dans la plupart des cas, les gens n’aillent plus vite en prenant des raccourcis. Prendre des raccourcis peut être nécessaire à court terme, mais cela crée une dette technique qui doit être traitée pour la santé à long terme du projet. D’où la réponse à ce mythe : les développeurs 10x sont ceux qui ont besoin de 10 développeurs pour nettoyer après eux.
La vie réelle
Le travail quotidien est rempli de situations qui peuvent déclencher la sensation de lenteur. L’autre jour, j’ai passé deux heures à essayer de connecter une imprimante réseau – et ma solution a nécessité de la déplacer dans un salon. De temps en temps, je passe des heures à résoudre un problème qui a été causé par un problème mineur – une faute de frappe, la recherche d’un bogue au mauvais endroit, ou toute autre erreur stupide.
Suis-je dur envers moi-même pour ces « échecs » ? Non. Pourquoi ? Cela fait partie du travail : parfois, vous apporter une solution rapidement, parfois cela prend plus de temps.
Conclusion
En tant que programmeur, votre travail consiste à apprendre des choses et à trouver des moyens d’aider le projet. Toute personne raisonnable comprend que l’apprentissage demande du temps. Dans un bon lieu de travail, vous recevrez le soutien dont vous avez besoin pour progresser et vous ne serez pas poussé à vous développer plus rapidement.
Pour moi, les programmeurs rapides me font peur que ce soit jeune ou moins jeunes surtout au début. Je préfère avoir un collègue junior lent qui finit par réussir. Des personnes qui apprennent vite, qui réagissent aux commentaires, c’est très bien. Mais un collègue qui ne fait que produire des changements rapidement, pas vraiment.
Et vous qu’en pensez-vous?
