Travailler sur un projet de développement en informatique est une mission pleine d’aventures. La créativité et la recherche pour la résolution de problèmes techniques sont au cœur du travail à accomplir.

Mais parfois, face à cette montagne à escalader, on se trouve perdu et à hésiter sur le chemin à suivre. Une des solutions qui s’offre à nous est alors de demander à notre guide quel est le meilleur itinéraire pour arriver à notre destination. Mais pourquoi ne pas plutôt regarder la carte qu’on a depuis le début de notre ascension et qui traîne dans notre poche ?

Quand on manque d’expérience, on est facilement tenté de demander de l’aide aux développeurs plus expérimentés. Cela s’explique par plusieurs raisons : évidemment une expérience plus jeune, mais aussi un manque de confiance en ses capacités.

Les expressions du type “On apprend de ses échecs” sont très clichés, mais pourtant, je vous assure qu’elles sont vraies, et qu’on peut d’ailleurs les affiner aussi en “On apprend de ses tentatives”.

L’heure n’est pas aux reproches, mais à la pédagogie, car les solutions, chacun peut en trouver. Peut-être certaines meilleures que d’autres, mais j’ai tendance à dire que rien ne vaut une solution qui fonctionne de manière plutôt satisfaisante à l’absence pure et simple de solution.

Cet article présente quelques pistes de réflexion pour trouver les solutions de soi-même à ces problèmes. Il n’y a évidemment pas toujours de solution miracle, mais les paragraphes suivants peuvent être vus comme une check-list de questions à se poser avant de demander de l’aide à ses collègues.

Quelle est la nature de mon problème ?

J’ai un problème avec le besoin du client, la spécification ou le cahier des charges

Il n’est pas rare que la documentation que nous avons à disposition, quant à la réalisation du projet, ait laissé des trous de manière plus ou moins involontaire. Que ce soit des points qui ont été oubliés initialement ou des éléments laissés en suspens, un cahier des charges reste rarement fixe au cours du développement d’un projet. Et cela implique évidemment des questions qui apparaissent.

Essayer de se mettre à la place du client

Selon son point de vue, quelle serait la meilleure solution à adopter ? Est-ce que celle-ci peut prendre en considération les différents cas d’usage ?

Demander au client directement

Que ce soit par un message direct ou en attendant une prochaine réunion hebdomadaire (dans le cas d’un point non bloquant), la meilleure solution peut être de simplement demander l’avis du client. Parfois, celui-ci n’a pas d’avis tranché sur le sujet, voire pas d’avis du tout. Il peut alors être intéressant de lui proposer 1, 2 ou 3 solutions que vous envisagez avec chacune leurs avantages et inconvénients. Cela permet de ne pas rester bloqué trop longtemps sur le sujet.

J’ai une problématique technique

Le terme “problématique technique” est ici plutôt large, mais recouvre une bonne partie du spectre des éléments touchant à l’écriture de code, allant de savoir comment mettre en place un élément jusqu’à la gestion d'erreurs incongrues.

Faire du code “moche” en priorité

Bien sûr, un projet est maintenable grâce à la qualité de son code et la structure des éléments mis en place. Mais un projet avec une architecture irréprochable aux composants parfaitement structurés ne sert à rien si le code qu’il contient ne fonctionne pas.
Avant de chercher à faire un code bien structuré et qui respecte toutes les règles établies pour le projet, faites plutôt quelque chose de simple, voire abstrait, mais qui fonctionne. Il est parfois bien plus simple de démarrer dans ce sens pour aboutir à un résultat, que de s’embarquer directement dans une architecture superflue et de s’y emmêler. Une fois cela fait, alors, vous pourrez restructurer les éléments.
De plus, c’est bien dans ce sens que vous pourrez vous rendre compte de la forme du découpage qui sera (ou non) nécessaire.

Les erreurs ont du sens

La stack d’une erreur est parfois impressionnante à observer, pourtant, elle renferme des informations très utiles.
Le message d’erreur donne une explication générale sur le problème rencontré, encore faut-il l’observer dans son intégralité. Certains sont plutôt transparents comme des “cannot assign string to number”, “object is possibly undefined” ou encore “cannot read [something] of undefined”. Dans le premier cas, vous avez une erreur sur la gestion du type de vos variables; sur le second, il s’agit de gérer des valeurs particulières de variables; et sur le troisième, il est question du membre de gauche de l’expression qui est non définie.
La stack de l’exception permet quant à elle de voir quelles fonctions ont été appelées lors de l'exécution et donc de remonter la trace de l’erreur si besoin. On peut, par exemple, imaginer un cas où l’erreur ne serait pas de votre faute, mais viendrait d’une des dépendances du projet.
A noter également que des extensions comme yoavbls.pretty-ts-errors permettent d’afficher les erreurs de manière plus visuelle.

La technique du Rubber Duck Debugging

L’idée est ici d’expliquer votre code étape par étape, ligne après ligne, à un canard en plastique. L’objectif est de se forcer à raisonner sur votre code, d’expliquer dans votre tête ce que vous avez écrit et là où vous voulez aller tout en passant par l’ensemble des étapes intermédiaires. Cette technique répond à plusieurs éléments : l’élaboration d’une solution (ce que vous avez en entrée et ce que vous voulez en sortie) et surtout la compréhension menant à la résolution d’un bug.

Dire clairement à voix haute ce que son code fait, permet parfois de comprendre la faille dans votre logique initiale grâce à cette prise de recul. C’est comme discuter avec quelqu’un, mais sans déranger quelqu’un.

Utilisation du debugger

Observer la valeur des variables à un instant donné est crucial pour comprendre d’où peut venir une erreur. N’hésitez pas à en abuser lorsque vous cherchez à comprendre quelle est la valeur d’une ou plusieurs variables juste avant qu’une erreur ne soit soulevée.
La version rustique de cette technique consiste à placer des console.log à la place, ce qui est moins fiable, mais déjà mieux que rien.

Fouiller la documentation à votre disposition

Documentation en ligne

Il y a plein de possibilités à votre disposition pour résoudre différents types de problèmes. Si vous avez un problème/question à propos d’une bibliothèque, chercher son Git ou son site officiel afin de pouvoir éplucher la documentation. Vous pouvez aussi regarder les "Issues" sur le Git du projet ou encore Stackoverflow afin de voir si quelqu’un a le même problème que vous et si quelqu’un d’autre propose une solution. Tant que vous avez accès au Git, pourquoi ne pas fouiller un peu le code source pour peut-être comprendre plus en détails le contexte d’une fonctionnalité que vous essayerez d’implémenter ?

Dans un contexte plus large, essayez de copier/coller votre erreur, ou de détailler votre problématique (ex: “sort array unique values”) sur Google qui pourrait vous prémâcher le travail de recherche.

Et si vous avez un problème précis avec une bibliothèque (ou autre), pourquoi ne pas ouvrir un post détaillé mais concis sur Stackoverflow ou les Issues d’un Repository Git ?

Documentation du projet

Parfois, il peut y avoir quelques spécificités dans les projets déjà développés. Une bonne pratique consiste à laisser des traces expliquant certaines fonctionnalités ou bugs connus. Il peut s’agir de commentaires directement dans le code ou bien de notes dans les fichiers README. Il peut donc être intéressant de fouiller le projet pour chercher des informations.
Dans le même style, si vous avez un doute sur les commandes en place d’un projet, vous pouvez regarder les fichiers “package.json” qui répertorient l’ensemble des commandes (dans le cas d’un projet NodeJs).

Quelle est la meilleure solution pour mon problème ?

La meilleure solution est celle qui fonctionne ! ;-) Peu importe la qualité du code dans un premier temps, le plus important est de trouver quelque chose qui fonctionne. On peut ensuite se poser la question de comment améliorer ce que l’on a écrit. Pour cela, il faut essayer des choses, et ce n’est pas grave si la solution envisagée initialement n’est finalement pas la bonne.
Un problème n’a généralement pas qu’une seule solution. En revanche, à terme, il faut essayer d’aboutir à la solution la plus stable, lisible et facile à maintenir. Mais pour cela, il faut y aller pas à pas.

Il faut aussi garder à l’esprit que ce n’est pas parce qu’on a moins d'expérience que la solution que nous imaginons sera nécessairement moins bonne que celle d’un développeur plus expérimenté. Chacun a une expérience différente et donc une approche différente. De plus, cela fait partie du processus d’apprentissage et permet de s'améliorer. Je suis sûr que si vous regardez le code que vous avez écrit il y a quelques années, vous seriez choqué de ce que vous avez écrit. Et ceci est tout autant valable pour des personnes expérimentées.

Pour tout type de problèmes

Il y a des solutions qui peuvent s’appliquer pour plusieurs types de problèmes.

Prendre des initiatives

Ne pas rester amorphe face à un problème et prendre des initiatives sont déjà des moyens de chercher à résoudre les problèmes en soi. Mieux vaut essayer et se tromper que de ne rien faire en espérant que la solution tombe du ciel.

Prendre du recul

Il est facile de se perdre dans un projet à force d’avoir "le nez dans le guidon". Prendre du recul et essayer de se déconnecter par moment permet de voir le projet dans un ensemble plus large. En changeant sa vision sur un problème, on peut donc mieux analyser la situation.

De la même manière, prendre des pauses est capital afin d'aérer son cerveau pour pouvoir mieux rebondir sur le projet avec une vision neuve.

Parfois, passer à une autre tâche permet également indirectement de prendre du recul sur la tâche initiale.

Qui peut avoir la réponse ?

Selon mon problème, quel est le bon interlocuteur ? Internet, le client, un collègue ? En existe-t-il seulement un ?

Pourquoi chercher à rationner les demandes d’aide ?

L’entraide est capitale dans une équipe saine, car elle permet de ne pas rester bloqué trop longtemps sur un point d’un projet, tout en ouvrant le dialogue sur les difficultés rencontrées.

Le problème n’est pas de demander de l’aide, bien au contraire, mais plutôt de savoir gérer la quantité et la fréquence d’aide que l’on cherche à obtenir de ses collègues.

Il y a plusieurs raisons qui peuvent venir supporter cette idée :

1/ La position du collègue qui reçoit une question

Ici, nous pouvons parler de 3 cas :

  • Dans le meilleur des cas, vous et votre collègue travaillez sur le même projet. Ainsi, si vous lui posez une question, son cerveau est déjà axé sur le même sujet que vous. Le temps pour s’adapter au besoin de votre question est plutôt faible. Pourtant, et déjà dans ce contexte, vous ne travaillez probablement pas tous les deux sur exactement la même tâche. Votre collègue qui est donc concentré doit fournir une certaine gymnastique mentale pour se transposer à votre besoin.
  • Dans un second cas, vous et votre collègue ne travaillez pas sur le même projet. Poser la question demandera certainement une remise en contexte (même minime). La gymnastique est alors plus grande pour votre collègue, qui doit se détacher de sa tâche en cours afin de mieux vous comprendre. Le temps de réadaptation (après vous avoir aidé) à son projet initial sera alors plus long.
  • Le moins bon des cas, est celui où votre collègue n’a aucune connaissance de votre projet. Là, la mise en contexte est certainement plus grande et plus difficile à absorber par votre collègue en quelques minutes. La gymnastique à effectuer sera alors la plus forte et certainement la facilité à vous aider encore moins certaine. La réadaptation à son projet initial n’en sera que des moins efficaces.

2/ “On n’est jamais mieux servi que par soi-même”

Ici, il faut l'interpréter dans un sens différent que ce que le dicton signifie d’ordinaire : il est bien plus satisfaisant de résoudre des problèmes par soi-même après avoir cherché, potentiellement avec difficulté, une solution qui nous convient et qui résout efficacement le problème.

3/ La quantité de questions que mon collègue peut recevoir

Si vous avez des questions, vous n’êtes très certainement pas le/la seul(e) à en avoir. Imaginez qu'à chaque moment où vous vous trouvez face à un blocage, vous vous dites que vous devriez demander de l’aide à un collègue, alors que se passerait-il si vous étiez 2, 3 ou plus avec le même raisonnement ?

4/ Personne n’a la science infuse

Votre collègue, dont vous vous dites qu’il aura sûrement la réponse à votre question, ne l’a peut-être finalement pas. Personne ne sait tout sur tout, et s’il vient juste vous dire comment chercher la solution à votre problème, n’auriez-vous pas pu le faire vous-même ?

Finalement, quand est-il le plus pertinent de demander de l’aide ?

Évidemment, il existe tout autant de raisons de demander de l’aide que de raisons de plutôt chercher par soi-même, ou du moins, de demander de l’aide après avoir cherché par soi-même.

1/ Je sais qu’un/une collègue à la réponse à ma question

Il est parfois possible qu’un/une collègue possède purement et simplement la réponse à une question. Peut-être que celui-ci / celle-ci a écrit le code que vous ne comprenez pas, ou encore qu'il/elle était présent(e) lors de la rédaction des spécifications du projet et connaît certains détails qui n’ont pas fini dans ce document, ou même sur des questions d’organisation du projet.

Dans certains cas, il peut aussi être intéressant d’avoir un “débat philosophique” avec quelqu’un pour avoir son avis de manière plutôt macro sur un sujet.

2/ Ne pas rester bloqué trop longtemps

Après avoir cherché une solution en vain, il y a moment où il faut savoir se dire que perdre plus de temps sur le sujet n’en vaut pas la peine. Cette durée dépend évidemment du sujet en question et du temps passé. Mais l’idée reste quand même que les projets doivent avancer, et que parfois, on a donc besoin d’un coup de pouce.

Si vous en êtes rendu à ce stade, n’oubliez pas les bonnes règles de communication pour optimiser l’échange et les réponses de manière asynchrone. Privilégiez les messages écrits (au moins dans un premier temps) en faisant preuve de précision, mais en restant concis.

Finalement, posez-vous la question de quelles informations sont utiles à communiquer pour rendre votre problème le plus explicite possible, quitte à faire abstraction d’éléments superflus au contexte de problème.

On espère que cet article vous aura été utile ! Suivez notre wiki pour d'autres astuces et tutos !

Nos développeurs Next Decision ont les compétences techniques et les environnements de travail parfaits pour répondre à vos besoins, alors pas une seconde à perdre, Contactez-nous !