Disclaimer

Je vous l'accorde, le titre peut paraître choquant. Certains diront présomptueux, voir même arrogant ! Cependant, il n'en est rien.
Ayant travaillé avec beaucoup de jeunes développeurs (et l'ayant été moi-même, même si certains de mes collègues diraient que cela remonte à l'âge de pierre), l'objectif de ce billet est surtout de partager mon expérience, mon point de vue et quelques bonnes pratiques qui, je l'espère, vous permettront de prendre de bonnes habitudes pour permettre de devenir meilleur, voir même plus "professionnel". A noter que je parle de "jeunes" développeurs mais, dans les faits, tout le monde pourrait être concerné par ce qui va suivre, peu importe le niveau d'expérience.

Un bon développeur, qu'est-ce que c'est ?

Il n'y a pas vraiment de bons ou mauvais chasseurs développeurs mais quand on parle de bon développeur, on pense très vite à quelqu'un capable de réaliser des algorithmes complexes, de déterminer la complexité desdits algorithmes, d'optimiser le code pour gagner quelques millisecondes. Ou bien encore de personnes connaissant par coeur les entrailles d'un Framework, d'expliquer en détails comment fonctionne telle ou telle couche. Ce sont des points forts, en effet, et nous avons besoin de développeurs avec ces compétences. Mais est-ce suffisant ? S'agit-il là des compétences primordiales que chaque développeur doit avoir à son arc pour lui permettre de travailler correctement (et en équipe) ? Ou bien d'être en mesure de comprendre clairement les attentes exprimées ?

En préparant cet article, je suis tombé sur pas mal de billets de blogs ou autre dans la même veine, qui expliquaient qu'il fallait connaître plein de langages (C#, Javascript, C++, Python, etc.), avoir une bonne culture informatique en général, être rigoureux, passionné voir même créatif... Certes, certains des points évoqués dans ces autres articles sont vrais, je suis totalement en phase avec eux (le cas de la passion est un très bon exemple). Cependant, d'autres m'ont surpris, pour ne pas dire choquer ! Quel intérêt de connaitre tous les langages informatiques ? Certes, vous serez peut-être amené à utiliser d'autres langages dans votre carrière mais pensez-vous que les connaitre tous (ou un maximum) soit une bonne chose ? Ne préférez-vous pas vous dire que si vous en connaissez un ou deux, les autres fonctionneront de la même façon : des mots-clés, une syntaxe, un parser, un analyser, etc. ? Et donc, au final, vous dire que si vous en connaissez un ou deux, vous serez en mesure de les comprendre tous ?

OK et toi alors, comment tu vois les choses ?

Il n'y a pas (et je pense qu'il n'y aura jamais) de liste exhaustive de conseils et astuces qui vous permettrait de devenir THE développeur, celui que tout le monde s'arrache car il est à la fois très bon techniquement mais également très professionnel. Je pense que seul l'expérience et le partage vous permettront de vous améliorer au fur et à mesure. Mais j'ai essayé de regrouper ici quelques-uns des points que j'ai rencontrés et qui, je l'espère, vous seront utiles (n'hésitez pas à répondre / débattre dans les commentaires, c'est tout l'intérêt !).

Savoir demander de l'aide

A priori simple comme affirmation mais combien de développeurs n'osent pas demander de l'aide quand ils sont bloqués ? Par peur d'être ridicule ? De passer pour "celui qui ne sait pas" ? Cela n'a pas d'importance ! Vous avez le droit de ne pas savoir quelque chose et d'avoir besoin d'aide, que ce soit pour déterminer le meilleur Framework à utiliser ou pour mettre en place une architecture. Oh, bien sûr, vous pourriez passer un moment à tester, investiguer, vous renseigner, sans jamais demander à personne, mais vous perdriez alors la possibilité d'échanger avec vos collègues sur vos problématiques et donc, potentiellement, d'avoir du feedback intéressant sur la marche à suivre.

Lorsque je fais passer des entretiens pour recruter des consultants ou des stagiaires, une des questions que je pose est : "Tu es bloqué face à un problème, comment réagis-tu ?". Bon nombre de candidats m'expliquent qu'ils essayent de trouver une solution par eux-mêmes puis qu'ensuite, ils cherchent sur Internet (nous y reviendrons dans le point d'après). Cependant, peu d'entre eux m'expliquent, par eux-mêmes, qu'ils demandent autour d'eux. Est-ce que cela vient du fait qu'à l'école, malgré les projets "de groupe", on est habitué à travailler tout seul ? Ou bien que nous estimons, sans même leur demander, que nos collègues n'auront pas la réponse ou qu'ils nous prendront pour des idiots ? Aucune idée... Mais une chose est sûre : personne ne sait tout sur tout donc vous êtes en droit de ne pas avoir la réponse à toutes les questions. 

Attention, cependant : ce n'est pas parce que vous demandez conseil à quelqu'un que cette personne aura la solution. Mais, à minima, il pourra vous éclairez, vous aiguiller vers une nouvelle piste, vous donner l'inspiration... Ou vous rediriger vers quelqu'un qui pourra peut-être vous aider un peu plus.

Savoir chercher sur Internet

Ah, là encore, un sujet qui peut sembler simple de prime abord. Mais au final, un très grand nombre de développeurs ne savent pas (ou ne veulent pas) utiliser les moteurs de recherche, c'est un fait !

Je vais vous prendre un exemple simple, basé sur une expérience qui m'est arrivée en travaillant avec un collègue. En implémentant une fonctionnalité sur une application Windows 10, ce développeur a rencontré une exception qui survenait à l'exécution, dès le lancement de l'application. Après l'avoir laissé chercher pendant quelques temps, nous avons décidé de faire du pair-programming pour tenter d'identifier la source du problème. Ne sachant pas moi-même pourquoi cette erreur survenait, je lui ai demandé s'il avait recherché sur Internet et sa réponse a été directe :

"Ouais, mais j'ai rien trouvé"

Ce genre de réponse a toujours tendance à me surprendre. En effet, nous sommes dans un monde où les demandes de nos clients/responsables/managers n'ont rien d'extraordinaires: pour 99% des développeurs que nous ne sommes, nous ne sommes pas en train d'envoyer une fusée en orbite ou sur la lune et, par conséquent, j'ai le sentiment qu'il y a toujours au moins 90% de chances que quelqu'un ait déjà rencontré le même problème que vous et se soit occupé d'en parler sur Internet (merci le partage communautaire, nous y reviendrons par la suite).

Cette "théorie", j'ai été en mesure de la vérifier maintes et maintes fois, y compris lors de la séance de pair-programming que j'ai faite avec mon collègue. Je lui ai demandé de refaire sa recherche devant moi et j'ai en effet constaté qu'il n'y avait pas de résultats probants. J'ai ensuite fait l'exercice de faire moi-même la recherche en question et il s'avère que le 1er résultat trouvé contenait la réponse !

On pourrait alors se demander pourquoi lui n'a pas été en mesure de trouver de réponses alors que j'ai été en mesure de le faire. Pour répondre à cette question, je vais surtout vous donner quelques astuces, simples mais que l'on peut vite oublier :

• Faîtes vos recherches en anglais : vous aurez toujours beaucoup plus de résultats qu'en Français. 
• Ne copiez/collez pas tout votre message d'erreur, contentez-vous de mettre des mots-clés (vous pouvez omettre les numéros de lignes, chemin d'accès aux fichiers, etc.)
• Si vous n'avez pas trouvé votre réponse au bout de 2 pages de résultats, il y a de fortes chances que vous deviez revoir/affiner votre recherche

Ne pas copier/coller bêtement

Ah, les forums, Stackoverflow, les blogs... Ils sont tous sources de réponses, de résultats potentiels. Qui n'a jamais copié/collé du code trouvé sur Internet, même si c'est juste "pour tester" ? Mais, au final, sait-on ce que l'on copie/colle ? Prend-on la peine de regarder le code ?

Beaucoup (trop) de développeurs (moi y compris, je l'avoue) ont tendance à prendre le code qu'ils récupèrent sur Internet, sans en comprendre le sens. Attention, je ne dis pas que c'est mal, il n'y a aucune raison de vouloir réinventer la roue. Cependant, il est important de prendre le temps d'étudier le code que l'on trouve pour le comprendre, identifier les impacts qu'il pourrait avoir, etc.

En effet, même si le code que vous allez trouver va fonctionner, êtes-vous sûr de savoir ce qu'il fait ? De le comprendre ? Savez-vous lequel est le plus optimisé, entre 2 versions disponibles ? Êtes-vous sûr qu'il est conforme à vos guidelines de développement ?

Gardez en tête qu'il est important de valider tout ce que vous trouvez sur Internet. Si vous n'êtes pas en mesure de le faire vous-même, reportez-vous au premier point de cet article : demandez un coup de main !

Respecter ses délais

Alors là, on aborde un point qui n'est pas simple du tout à appréhender pour les jeunes développeurs (et parfois même pour des développeurs plus expérimentés).

A chaque fonctionnalité que vous allez implémenter, on commencera (normalement) par vous demander votre estimation du temps nécessaire au développement (si ce n'est pas le cas, interrogez-vous sur le fonctionnement de votre organisation).

Il est important de respecter, au mieux, les délais que vous donnez. L'idée n'est absolument pas de vous forcer à finir plus tôt, au détriment de la qualité de votre réalisation. Cependant, tenir les délais permet de piloter le projet, d'un point de vue planning et budget, et donc d'éviter les mauvaises surprises. Quand vous travaillez, vous êtes souvent en équipe donc il est important de penser à vos collègues, comme le chef de projets qui devra justifier du retard qui a été pris (et, mettez-vous à sa place, dire à un client que le projet est en retard simplement parce que "on a juste mis plus de temps que prévu" n'est pas une chose aisée).

Attention, ce genre d'exercice n'est pas simple ! Personnellement, je suis quelqu'un de plutôt prudent et, quand je donne une estimation, je prends une petite marge de sécurité (voir, par moment, "ceinture, bretelles et parachute" © Pascal LAFOREST). La raison est simple, je pars du principe qu'il y aura TOUJOURS un imprévu dans la réalisation d'un développement : des spécifications qui ne sont pas complètement claires, un problème matériel sur la machine d'un développeur, un manque d'expérience, une tâche sous-estimée, etc. Ainsi, en prenant une sécurité, je m'assure de finir, au mieux en avance et, au pire, dans les délais que j'avais indiqué.

Bien sûr, malgré toutes vos précautions, il y a des moments où vous ne pouvez rien changer : vous avez pris plus de temps que ce que vous aviez estimé. Ce n'est pas grave ! L'important, dans ce cas, est simplement de pouvoir le justifier de manière claire.

Attendre la fin des builds

Nous sommes à une époque où les techniques de Pull Requests, Code Reviews, Intégration et Déploiement Continus, Builds font parti de nos vies. On le sait bien, les Builds, ça peut prendre du temps :)

Mais elles sont nécessaires pour valider la bonne réalisation et qualité des développements qui sont réalisés. Cependant, ce n'est pas parce que cela fonctionne sur votre machine que cela fonctionnera sur le serveur de Build ! Donc si votre équipe met en place de l'intégration continue, attendez la fin de la Build, voir le déploiement automatiquement, pour dire que vous avez fini votre tâche et que vous pouvez partir en vacances. Il n'y a rien de plus gênant pour vos collègues que de se retrouver bloqués, parce que votre code ne compile pas et que vous n'êtes pas en mesure de les aider pendant votre absence.

Alors oui, cela va prendre plus de temps, cela oblige (parfois) à rester plus tard pour valider que tout est OK. Mais, au final, cela évitera de la frustration à l'ensemble des membres de votre équipe, voir même cela ne les bloquera pas alors que vous ne serez pas en mesure de les dépanner.

De la bonne utilisation des commentaires

On a souvent tendance à penser que les commentaires sont inutiles car, au final, c'est nous qui écrivons notre code : on sait ce que l'on a voulu faire quand on a écrit notre algorithme récursif de 150 lignes. Mais là encore, il ne faut pas oublier que vous ne serez pas forcément seul sur votre projet, vous serez peut être amené à travailler avec d'autres développeurs dont certains comprendront très vite ce que vous avez voulu faire et d'autres qui, moins expérimentés, auront plus de difficultés à saisir vos intentions.

A moins d'ouvrir votre API ou votre SDK à des développeurs tiers, je ne pense pas qu'il soit intéressant de tout documenter (les propriétés, les méthodes, etc.). En effet, là, on est dans un cas particulier où il est important pour des développeurs de comprendre les tenants et aboutissants de votre code, que ce soit avec des noms correctement choisis ou des commentaires bien écrits. Dans le cas contraire, la documentation de TOUT le code me parait superflue (une propriété nommée "LastName" est suffisamment parlante pour savoir ce qu'elle représente) mais cela ne veut pas dire qu'il ne faut rien documenter ! Si vous écrivez un algorithme complexe, vous devez documenter les parties intéressantes du code qui le compose (en plus de le nommer correctement). On se moque d'avoir les balises de description en entête si, quand on doit le relire, on ne comprend pas la logique que vous avez voulu mettre en place.

Entendons-nous bien: quand je dis que l'on s'en moque, ce n'est pas quelque chose à prendre au pied de la lettre. Mais, à choisir, je préfère avoir un code dont le corps d'une méthode est explicité et clair (ce qui facilite la reprise ou la maintenance) plutôt que d'avoir un code dont les complexités ne sont pas expliquées et pour lequel l'intelliSense m'affiche correctement la valeur des paramètres (bon, dans un mode idée, je préfère avoir tout mais il ne faut pas trop en demander). Car, ce qu'il faut garder en tête, c'est que peu importe la simplicité ou la précision de votre code, il ne se suffira pas lui-même pour s'auto-documenter !

Ce point de vue est d'ailleurs partagé par Jeff Atwood dans deux billets de blog :

• When Good Comments Go Bad
• Code Tells You How, Comments Tell You Why

Et je pense que sa citation est assez parlante :

The best kind of comments are the ones you don't need. Allow me to clarify that point. You should first strive to make your code as simple as possible to understand without relying on comments as a crutch. Only at the point where the code cannot be made easier to understand should you begin to add comments.

Dernier point : quand vous écrivez des commentaires (utiles), vous le faîtes aussi pour vous. En effet, si vous devez repasser sur votre code 4 ou 5 ans plus tard, vous serez bien content de vous remémorer ce que vous aviez voulu faire (et pourquoi) à l'époque.
Afin d'illustrer mon propos, voici une petite anecdote qui m'est arrivée aux oreilles : plusieurs développeurs intervenaient sur un projet chez un client et l'un d'entre eux a écrit une requête LINQ qui faisait une dizaine de lignes. La requête était la plus optimisée possible, avec des temps de réponse idéaux. Quelques temps plus tard, le client a remonté un souci dans l'application et il s'est avéré que le bug venait de cette requête. Le développeur en charge de son écriture est donc intervenu pour corriger le souci. Seul problème, même lui n'arrivait pas à relire et comprendre le code qu'il avait écrit... Alors peut être que des commentaires auraient été utiles pour comprendre la logique mise en place, ou peut-être pas, c'est possible. Mais, dans un cas comme celui-là, cela ne coûte rien d'en rajouter et, croyez-moi, vous les apprécierez en temps et en heure.

La mise en place de tests

Ah, les tests ! Ce sujet (qui comme les commentaires) a déjà fait couler beaucoup d'encre et animé pas mal de débats.

Tests unitaires, test d'intégration, tests d'interfaces : on en entend de plus en plus parler et, bien souvent, la réaction est la même : "c'est long à faire et ça coûte cher pour pas grand-chose".

Alors oui, c'est un fait : écrire (et maintenir) des tests prend du temps (et donc, implicitement, coûte de l'argent). Mais cela permet de s'assurer de la bonne qualité des développements, c'est pourquoi il est important d'en écrire quelques-uns. Je dis bien quelques-uns car il me semble inutile (et laborieux) de chercher à avoir 100% de couverture de code (certains estiment que 80% est largement suffisant). Mon avis, concernant ce pourcentage, est que cela n'a pas d'importance, le point clé étant de tester les fonctionnalités principales de votre code / algorithme. Vous pouvez avoir un taux de couverture de code (global) de 20%, mais 90% de couverture de code sur votre algorithme principal : le résultat peut sembler dérisoire mais si, au final, le point clé de votre programme est cet algorithme, alors c'est bien lui que vous devez tester.

Certains développeurs ne jurent que par cela. A titre personnel, j'ai longtemps été partagé quant aux bienfaits des tests : comme beaucoup, je les trouvais superflus, je ne comprenais pas leur intérêt. Mais plus je développais, seul ou avec des collègues plus expérimentés, plus je me rendais compte des avantages et impacts que cela pouvait avoir :

• Détection de bugs qui pouvaient, parfois, ne survenir que dans des cas bien précis
• Amélioration de la qualité du code
• Simplicité pour la validation de cas fonctionnels
• Aide au debug
• Démonstration de l'avancement d'un projet
• Etc.

Quant à savoir s'il est mieux de faire des tests unitaires, ou des tests d'intégration ou bien les deux, je pense qu'il n'y a pas de bonnes réponses et que tout dépend de ce que vous voulez tester et du temps que vous voulez y consacrer. Mais, dans tous les cas, peu importe : à minima, vous aurez déjà franchi un premier palier et, là encore, vous risquez de ne pas être déçu du résultat.

Apprendre, partager et échanger

Lorsque vous faîtes une recherche sur Internet et que vous trouvez la réponse, ce n'est pas par magie : c'est parce que quelqu'un, avant vous, à rencontré le problème et à décidé de poster sa solution sur un blog, dans un forum, etc. Le partage, qu'il soit communautaire ou juste au sein de votre entreprise, est un élément clé dans l'apprentissage et la formation des développeurs.

Si c'est quelque chose qui vous intéresse, lancez-vous ! Vous n'avez rien à perdre et, quoi que vous en pensiez, vous avez toujours des choses à raconter : l'architecture que vous avez mise en place sur un projet, le Framework ou pattern que vous avez utilisé pour gérer tel ou tel cas, etc. Ecrivez des posts de blogs ou des articles, participez à des conférences, en un mot : contribuez. Dîtes-vous que si vous avez rencontré un problème, d'autres le rencontreront peut-être et, comme vous, ils seront bien heureux de trouver une réponse sur Internet.

Alors oui, c'est vrai, tout le monde n'est pas suffisamment à l'aise pour écrire des articles ou parler en public, et c'est compréhensible : on se dit toujours que l'on n'aura rien d'intéressant à dire, que cela a déjà été publié ou, tout simplement, que cela ne nous intéresse pas. Et c'est quelque chose de normal : le partage, quand il est communautaire, est surtout une question de passion, d'envie de faire plaisir aux autres (même si vous aurez toujours des râleurs pour critiquer votre travail).
Qu'à cela ne tienne : vous pouvez toujours partager avec vos collègues. Que ce soit autour de la machine à café ou lors de la pause déjeuner, vous avez énormément d'occasions de discuter avec eux, d'apprendre grâce à eux et, inversement, de leur permettre d'apprendre grâce à vous.

Et si vraiment vous souhaitez vous lancez dans l'écriture en ligne, mais que vous ne vous sentez pas assez en confiance, faîtes-vous aider en demandant des conseils, des astuces. Ecrivez votre premier article conjointement avec quelqu'un qui a plus d'expérience afin de vous faire aider ou demandez-lui simplement son avis sur votre plan. Cela vous permettra de mettre le pied à l'étrier pour, au final, être en mesure de le faire tout seul par la suite.

Être pragmatique

Quand on développe, on cherche toujours à faire de notre mieux, à implémenter le meilleur algorithme ou la meilleure architecture. Seulement parfois, on finit par oublier l'objectif que l'on s'est fixé et on met en place une usine à gaz. Est-ce vraiment utile ? N'y a-t-il pas de solutions plus simples mais, potentiellement, un peu moins performantes ou moins "jolies" d'un point de vue "code" ?

Si le code (et sa qualité) sont importants, le respect des délais et des engagements pris envers les clients le sont aussi. Ne cherchez pas à faire trop bien dès le départ, quitte à mettre votre projet en péril (NB : j'ai bien dit "trop bien", pas juste "bien").
Le code d'une application, c'est un peu comme un organisme vivant : ça vit, ça bouge, ça évolue ! Et tout cela, grâce à vous. Donc rien ne vous empêche d'implémenter une fonctionnalité sans être à 100% dans les règles de l'art (mais sans le faire à la va vite non plus) et d'y revenir plus tard pour le peaufiner ou pour l'améliorer.

Être pragmatique, c'est savoir faire les bons choix tout en sachant quand on va trop loin, quand c'est un peu "too much" pour le besoin exprimé.

Conclusion

Il y aurait sans doute plein de choses à dire ou à rajouter mais cela donne déjà une bonne petite liste d'axes d'amélioration pour quiconque se poserait des questions.

Je le répète, les points abordés ci-dessous ne représentent que ma vision des choses. Tout le monde ne sera pas d'accord avec cela, je le conçois et je trouve cela normal (les opinions différentes, c'est d'ailleurs ce qui permet d'alimenter les débats). Si c'est le cas, n'hésitez pas à échanger dans les commentaires, je suis curieux d'avoir le point de vue d'autres personnes à ce sujet.

Et, dans tous les cas, j'espère que cela donnera matière à réfléchir aux lecteurs :)

Et bonne année à tous :)