12 trucs et astuces pour apprendre à coder (parce que 10 c’était trop court)

1 – Prendre le langage qui vous branche, pas celui qui est la hype du moment

C’est la règle d’or : apprendre en s’amusant ou tout au moins aimer ce que l’on fait. Ne vous focalisez pas sur le langage du moment. S’il vous rebute, vous n’arriverez à rien. De plus, ce domaine évolue tellement vite que vous n’êtes pas à une surprise près. Le Javascript était par exemple particulièrement déconsidéré avant que l’on parle de HTML5 et qu’il devienne l’un des piliers du web. L’important est que le langage que vous choisissez attise votre curiosité et votre envie d’apprendre. Il est plus intéressant d’avoir des développeurs avec de multiples facettes que des profils tous exactement similaires. Qui plus est, vous trouverez toujours une solution pour aboutir à vos fins. Par exemple, le couple PHP – MySQL m’a toujours rebuté dans le domaine des bases de données. Cela ne m’a pas empêché d’y pallier en m’éclatant avec des langages et méta-langages comme Rebol (désormais Red), Python et XML.

2 – Trouver un projet qui vous passionne et le mener à bien

Le grand défaut de certains manuels ou formations au code est le manque de cas concrets. On vous apprend les commandes les unes après les autres mais le liant est quasi-absent. C’est comme apprendre des mots, des phrases sans jamais avoir de conversation. Je me suis ainsi pris une claque la première fois que je suis venu passer véritablement quelques temps en Angleterre. Rien à voir avec l’anglais de l’école. Il m’a heureusement fallu peu de temps pour m’adapter et plonger dans le grand bain linguistique. Le grand bain, c’est donc un projet qui vous passionne, pour lequel vous trouverez le temps et l’énergie de réfléchir, de développer, de vous casser peut-être et même sûrement les dents. Peu importe si ce type de logiciel existe déjà. C’est toujours plus intéressant de le faire soi-même. Répondez à un besoin, une envie. Construisez par exemple un outil pour compléter une autre de vos passions. Soyez créatifs et créateurs.

3 – Dédramatiser

Vous apprenez une nouvelle langue. Imaginez-vous dans un pays étranger où vous ne maîtrisez que quelques mots et où l’ordinateur est votre seul interlocuteur. Vous lui demandez le sel. Il vous répond qu’il ne comprend pas. Vous lui demandez de nouveau autrement. Il vous apporte le sucre. Rien de grave. Juste un problème de compréhension. Votre vie ne se joue pas à cet instant et l’ordinateur ne va pas barrer votre copie numérique d’un grand trait de crayon rouge ni exploser après avoir affiché un grand « syntax error » clignotant.

4 – Avancer pas à pas et en faire un peu tous les jours

Ce n’est pas 10 minutes par jour ou 5 heures tous les quinze jours qui feront de vous un développeur. Il vaut mieux apprendre et s’exercer un peu tous les jours. Une bonne régularité vous permet de mémoriser plus facilement. Ne visez pas non plus trop haut dès le départ. Vous risqueriez de déchanter. Dans le domaine de la programmation informatique, on s’imagine facilement devenir bilingue du jour au lendemain. Cela nécessite un peu plus de patience mais vos efforts seront toujours récompensés.

5 – Savoir lâcher du lest

Il faut parfois savoir abandonner provisoirement ce que l’on fait pour mieux y revenir. Ce n’est pas en restant bloqué devant l’ordinateur que l’inspiration vous viendra. Il est même fort probable que vous serez encore plus perdu. Quand je ne comprends plus rien, très souvent je m’éloigne de l’ordinateur, prends une feuille de papier et essaie d’exprimer ma pensée de manière simple. Cela me permet d’y voir plus clair et de repérer l’endroit où je me suis égaré dans le code. N’hésitez pas à passer à autre chose, carrément autre chose. La solution d’un bout de code qui me torturait l’esprit m’est apparue récemment en faisant mes courses, un paquet de nouilles à la main… Lorsque l’on se détache d’une activité, on libère le cerveau qui peut alors « à l’insu de notre plein gré » explorer de multiples voies alternatives. Bougez, marchez, aérez-vous l’esprit, détendez-vous devant un bon livre, une BD ou un jeu vidéo et il y a de fortes chances que tout s’éclaire et que vous vous écriiez tel le commissaire Bougret de Rubrique à Brac « Bon sang mais c’est bien sûr ! ».

6 – Commenter, synthétiser

Commenter le code s’avère vite indispensable. D’une part, pour expliquer ce que vous faîtes (particulièrement important quand on débute), d’autre part, comme aide-mémoire. Quand on saute d’un projet à un autre ou que l’on reprend un bout de code six mois plus tard, il est important de pouvoir s’y retrouver rapidement. Ce serait dommage de perdre du temps à s’interroger sur le fonctionnement du programme. De même, il peut vous arriver pour x raisons de ne pas coder de manière naturelle mais d’user d’un subterfuge, d’une porte dérobée. Six mois plus tard, il est fort probable que vous vous demanderez pourquoi vous n’avez pas codé telle ou telle fonction de manière classique. Ce que vous ferez immédiatement avant de vous rendre compte de votre erreur et du « pourquoi du comment » que vous avez agi différemment.

7 – Prendre des notes et synthétiser ses connaissances

Les manuels papier ou numérique, les cours en ligne sont très pratiques mais ne correspondent pas forcément à votre manière d’apprendre. Qui plus est, les explications sont parfois verbeuses et vous ne vous intéressez qu’à un petit bout de texte, à la syntaxe d’une commande par exemple. Faites-vous un document récapitulatif, pourquoi pas sous forme de carte heuristique. Lorsque l’information vous manque, pas besoin de devoir plonger dans le manuel. Un simple coup d’oeil sur votre synthèse vous permettra de retrouver l’information importante. Cela vous permet aussi de compléter l’information manquante ou de donner des exemples qui vous paraissent plus clairs que dans le manuel.

8 – Tester et expérimenter

Les manuels n’ont pas toujours réponse à tout et il se peut fort bien que le problème que vous rencontrez ne soit pas documenté. Je prends souvent en formation l’exemple du labyrinthe. On ne reste pas coincé au bout d’une allée. On revient sur ses pas pour tester la suivante jusqu’à ce que l’on trouve la sortie. Dans le code, idem. Si cela ne marche pas avec la méthode A, peut-être que la méthode B sera la bonne, ou la C ou la D ou la E… Vous ne perdez rien à essayer. Parfois même il vaut mieux isoler une commande, la tester en dehors de votre programme pour vérifier que vous avez bien compris son fonctionnement et qu’elle répond exactement à vos besoins.

Récemment par exemple, j’examinais dans un manuel une commande permettant de supprimer un caractère précis d’une chaîne de caractères, par exemple retirer les virgules d’une phrase. Je voulais cependant retirer toute la ponctuation et le manuel n’indiquait pas comment retirer plusieurs caractères en même temps. J’aurais pu répéter la même commande caractère par caractère mais cela me paraissait un peu fastidieux. J’ai simplement ajouté d’autres caractères entre les guillemets indiquant celui à supprimer et le miracle fût. J’aurais pu perdre mon temps à chercher sur internet ou rester bloqué. Un simple test m’a permis d’avancer.

9 – Sauvegarder régulièrement et utiliser le versioning

Sauvegarder régulièrement devrait être un réflexe naturel. Personne n’est à l’abri d’un souci technique ou d’une erreur de manipulation. Et zou, adieu le code tapé pendant de longues minutes fiévreuses… Sauvegardez régulièrement et n’hésitez pas à créer de multiples fichiers portant chacun un numéro de version. Cela vous permet de conserver un historique de votre progression et de repérer plus facilement les erreurs. Si la version 0.43 de votre code fonctionnait parfaitement, nul doute que les erreurs proviennent de ce que vous avez ajouté à la version 0.44.

Par convention, les versions comportant des chiffres après la virgule sont dites « mineures », c’est-à-dire que les modifications qui y ont été apportées ne sont pas importantes. Les versions avec un chiffre entier sont dites majeures car elles sont considérées comme fonctionnelles et apportant une réelle innovation dans la progression. Si je comparais avec la randonnée, les versions 0.43 et 0.76 indiquent que vous avancez sur le chemin, la version 1.0 que vous êtes arrivés à votre première étape, le refuge de la Chouette chantante sur le Mont Técarlo. La version 1.0 est un peu particulière car c’est la première version véritablement fonctionnelle.

Par exemple, je code actuellement pour le plaisir un analyseur de textes en Red et je suis à la version 0.56, ce qui signifie que mon programme tourne correctement mais qu’il est pas encore assez fonctionnel pour le public et qu’il reste des améliorations majeures à y apporter.

On peut utiliser des services en ligne comme Framagit pour sauvegarder son code et pouvoir suivre plus facilement l’historique mais, pour démarrer, ce n’est pas forcément nécessaire.

10 – Simplifier, optimiser votre code

Votre code fonctionne parfaitement ? Magnifique ! Mais le travail n’est pas fini. C’est le moment de simplifier, d’optimiser le programme. Simplifier en vérifiant s’il n’y a pas possibilité d’avoir un code plus concis ou d’user de méthodes plus rapides. Certaines commandes peuvent par exemple être réunies et combinées en une seule. Un code simplifié et optimisé est plus élégant, plus facile à lire et surtout fonctionne plus vite. C’est alors moins de temps machine utilisé, moins de dépense énergétique.

Optimiser, gagner en rapidité et en ressources, c’est aussi se soucier du matériel plus ancien. Quel intérêt a votre programme s’il faut systématiquement le dernier ordinateur en date pour le faire tourner ? Les utilisateurs se tournent plus facilement vers des solutions économes et votre souci d’optimisation montrera votre habileté et votre sérieux dans le code.

Optimiser, c’est aussi se soucier de l’utilisateur et des erreurs possibles. On tente alors de se mettre à la place de ce dernier et de lister les problèmes qu’il ou elle peut rencontrer. N’hésitez pas à tester votre programme auprès d’autres personnes. Quand on a le nez dans le guidon, il est souvent difficile de repérer ses erreurs.

Un exemple d’erreur ? De nombreux formulaires en ligne examinent la saisie au cours de la frappe et affiche un message d’erreur en rouge de manière un peu trop systématique. Lorsque vous entrez une adresse mail et que vous voyez apparaître le message « adresse mail non valide », il y a de quoi se poser des questions. En fait, tant que l’adresse entière n’est pas tapée, elle est forcément non valide. Un utilisateur averti saura de quoi il retourne. D’autres seront bloqués. La solution toute bête est de vérifier la saisie lorsque l’utilisateur valide le formulaire et non lors de la frappe. Erreur de design, erreur de développeurs qui ne se sont pas mis à la place de l’usager…

11 – Comparer, examiner le code des autres

On apprend en observant. Observer n’est pas copier, reprendre des bouts de code sans trop savoir à quoi cela sert. Observer, c’est examiner, analyser, essayer de comprendre la méthode de tel ou tel développeur et ensuite trouver sa propre méthode. Chaque fois que cela est possible, n’hésitez pas à examiner le travail des autres et à en tirer vos propres solutions.

12 – Poser des questions

Il existe des forums spécialisés, des sites regorgeant d’articles. Le problème sur lequel vous planchez ne trouvera pas forcément sa réponse immédiatement mais il y a de fortes chances que vous ne soyez pas le seul dans votre cas ou qu’un autre problème s’en rapproche. Après avoir fait quelques recherches, avoir documenté votre problème, n’hésitez pas à poser la question sur un forum non sans avoir clairement expliqué la situation qui vous bloque. Un « Ca marche pas » ne résout jamais rien.