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

Étiquettes

apprentissage, auto-apprentissage, éducation, code, formation, méthode

 

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.

Scratch : utiliser les boucles

Étiquettes

boucles, code, scratch

Les boucles sont au code ce que l’huile d’olive est à la cuisine italienne : indispensables. On finit lors des ateliers et formations par s’en amuser, tellement je donne l’impression de me répéter (c’est le cas de la dire) lorsque j’évoque les boucles. Une par ci, une par là. Impossible de faire sans… Scratch n’en manque pas avec des particularités que l’on ne retrouve dans aucun autre langage. Petit passage en revue.

Répéter indéfiniment

La boucle la plus célèbre de Scratch et celle qui revient le plus souvent. Proche d’un des premiers codes que j’ai tapé en BASIC.


10 Print "Bonjour"
20 Goto 10


Ou comment rendre l’ordinateur fou en lui faisant sans cesse répéter la même chose sans moyen d’en sortir. Dans Scratch, la boucle « répéter indéfiniment » est essentiellement utilisée pour vérifier des états et des conditions. Ainsi, dans l’exemple ci-dessous (1er script), elle permet de suivre l’évolution du volume sonore et de déclencher un événement si celui-ci dépasse la valeur 70. La boucle est souvent oubliée et renvoie à une erreur classique. Le deuxième script en effet ne vérifie le volume sonore qu’une seule fois au déclenchement du programme en cliquant sur le drapeau vert.

Il est possible d’arrêter une telle boucle en utilisant l’instruction « stop ». Par exemple :

Répéter x fois

La boucle la plus simple à comprendre. À utiliser quand vous savez exactement de combien de répétitions vous avez besoin. Par exemple :

Cette boucle peut aussi s’utiliser avec des variables quand on ne connaît pas le nombre de répétitions à la base. Par exemple pour épeler un prénom :

C’est un peu dans ce cas l’équivalent d’une boucle « for … next » qui permet d’utiliser une boucle en faisant évoluer une ou plusieurs valeurs. Cela m’a toujours étonné que Scratch ne possède pas de boucle de ce type mais on peut la simuler avec la boucle « répéter jusqu’à ».

Répéter jusqu’à

Cette boucle est particulièrement utile car elle permet des choses que peu de langages offriraient aussi facilement. Par exemple :

Mais je l’utilise principalement pour les boucles « for … next ». Une boucle de ce type possède une condition de départ, une condition de fin et une variation de la valeur suivant un « pas ». Ainsi, par exemple, la variable x vaut 0 en condition de départ ; on arrête la boucle lorsque x vaut 250 en condition de fin et on la fait varier de 10 en 10.

En Basic, cela ressemblerait à ceci :


FOR x = 0 TO 250 STEP 10
PRINT x
NEXT


Et avec Scratch :

Ces boucles sont fort utiles notamment dans le traitement des chaînes de caractère ou dans la génération de graphismes.

Bon amusement !

ParcourSup et algorithmes : le principe de diabolisation

Crédit : Viewminder (Flickr)

Dire que ParcourSup rencontre quelques petits problèmes est un euphémisme… Cela semble malheureusement être le plantage total. Et, comme de coutume, je vois fleurir les commentaires façon « c’était mieux avant ». La technologie a bon dos.

Pourtant une machine ne fait que ce qu’on lui demande de faire. Elle ne va pas plus loin. Quand un programme est codé avec des moufles, il y a bien une paire de mains dans ces dernières.

Se planter n’est pas grave mais il y a un moment pour se planter. Comme pour les artistes, ce n’est pas sur scène qu’il faut se planter mais lors des répétitions. C’est à ce moment que le plantage est salvateur car il révèle des failles et des erreurs de conception que l’on peut alors corriger.

On peut appliquer ce que j’appelle le principe de diabolisation. Concevoir, coder un algorithme est plus ou moins complexe et, dans la majorité des cas, on l’imagine dans des conditions idéales. C’est le moteur de base qui est loin d’être fini et qui ne fonctionnerait tel quel que dans un paradis comme la planète Beatituda que les Simpson sont censés atteindre un jour dans un épisode consacré aux sectes. Mais je m’égare… Les conditions idéales n’existent pas et on va alors viser des conditions de M… Je vous laisse compléter.

Se faire l’avocat du diable, c’est en effet se poser la question de savoir qu’est-ce qui va bien pouvoir « merder » dans la solution que l’on a mise en place. Passez moi le terme car c’est celui qui convient. C’est un principe « hacker » que de chercher la petite bête, que d’imaginer des conditions diverses parfois complètement folles dans lesquelles la solution va planter lamentablement. Un développeur qui a pour adage « bon, ça ira comme ça » est soit un incompétent, soit un inconscient tout droit sorti des Télétubbies, soit enfin un adepte des mises à jour plus que fréquentes. Diaboliser, c’est prévoir et prévoir, c’est jouer la carte de la sécurité pour laquelle il ne faut pas hésiter à aller très loin dans le délire.

Par exemple :

« Affluence record : on n’a pas assez de serveurs pour répondre. » -> « Ok, mise en place d’une autre série de serveurs en cas de débordement. »

« Le circuit électrique tombe en panne. » -> « Ok, on prévoit des générateurs indépendants. »

« Batman ne trouve pas sa voie. » -> « Ok, on ouvre une section supplémentaire. »

« La Russie, la Corée du Nord et les États-Unis prévoient une attaque de grande ampleur pour déstabiliser le site . -> « Ok, on a une équipe sur le coup et un bon rempart en place. »

« Une météorite menace de s’écraser sur le data center ou un peu plus loin dans l’océan. » -> « Ok, on reporte à la semaine prochaine et, en attendant, on va boire un coup. »

« Rien ne va. C’est l’apocalypse. » -> « Ok, on a une belle page 404 avec les indications à suivre et des messages rassurants. »

Je plaisante avec ces exemples. Le problème est qu’aujourd’hui nous sommes face à un enjeu extrêmement important et un fiasco qui risque de mettre sur le carreau nombre de jeunes étudiants. On ne sait déjà pas trop ce que l’on veut faire à 18 ans alors si en plus on nous met des bâtons dans les roues… Personnellement je bénis le fait de n’avoir pas connu ce casse-tête. Je ne sais pas dans quelle section je me serais retrouvé. Je n’aurais en tous cas sûrement jamais pu faire les études que j’ai effectuées.

Alors, innovons aujourd’hui, innovons demain mais testons, testons encore, testons encore plus loin, cassons la machine, une fois, deux fois, trois fois mais, j’insiste : comme au théâtre, lors des répétitions pas lors de la première…