26 Mai 2025
Y en t’il vraiment ?
mavie
J’ai toujours voulu donner des conseils, c’est une position agréable que celle du donneur de leçons. Ce qui se cache derrière cette expérience évidemment c’est que la réalité nous a rappelé à l’ordre, ces leçons ont parfois été intégrées dans la douleur. Après plus de trente années dans le domaine et de nombreuses lignes de code plus tard, j’espère avec quelquechose à apporter. En particulier que je relis mon ancien code, je mesure l’adage “Faites ce que je dis, pas ce que je fais !”
Je te tutoies, comme je l’aurais fait si je m’adressais à moi-même quand j’avais treizeaquatorze ans.
mavie
Chacun a ses règles, voici celles que d’expérience je devrais suivre même si je ne le fais par toujours et que je m’en mords pratiquement à chaque fois les doigts.
Il existe de nombreux livres sur le sujet.
C’est le conseil n°1, en choisissant des projets dont le source est ouvert et utilisable sans contraintes tu t’autorises la réutilisation de briques logicielles de diverses sources.
Autant de choses que tu n’auras pas à coder, laisse l’ordinateur faire de tout ce qui est répétitif ou existant, et de ton côté créé ce qui n’existe pas.
On semble idiot qu’une seule fois, sinon on le reste.
Profitez de votre jeunesse pour faire accepter vos questions, ignorez les réponses sur la forme et concentrez vous sur le fond. Vous pouvez toujours créer un compte secondaire pseudonyme si vous avez peur pour ‘votre image de marque’ ;-)
Les moteurs de recherche sont tes amis quand tu sais quoi copier/coller ! Je fais partie de la génération ‘StackOverflow’.
Une grande partie de l’activité d’un développeur c’est de travailler sur du code déjà écrit. C’est aussi un bon moyen d’apprendre.
La lingua franca de l’informatique c’est l’anglais, c’est ainsi. C’est avec plaisir que les informaticiens du monde entier massacrent allègrement la langue de shakespear ! Connaître l’anglais permet d’aller chercher les informations sur tous les sites, la documentation la plus a jour est le plus souvent en anglais.
Inutile de préparer du code dans l’optique d’une potentielle évolution future, crois moi, elle n’arrivera pas ! C’est un forte tentation, mais cela complexifie ton code inutilement et ce que le futur te réserve est rarement ce à quoi tu t’attends. Si tu veux préparer une abstraction pour du code futur il faut alors que tu aies au moins déjà deux utilisations de cette abstraction.
A moins que ce soit pour des raisons pédagogiques, n’essaie pas de créer tes propres outils, apprends plutôt à utiliser ceux qui existent déjà. C’est un conseil que je n’ai hélas pas assez pratiqué.
De nombreux professionnels sont passés avant toi et ont laissé des outils très puissants. Ceci s’applique pour tout, mais en particulier pour toute la cryptographie. N’écrit jamais de code de crypto, sauf si tu es un expert dans ce domaine, et même là, ne le fais pas seul.
Concentre toi sur la partie métier, c’est à dire pour le but à atteindre et automatise, réutilise au maximum la partie plomberie informatique.
Mon premier langage de programmation a été le BASIC mais très rapidement j’ai voulu descendre dans l’assembleur. Parce que l’assembleur ça avait vraiment l’air difficile comparé au basic ! Je pense y a voir passé plus de temps que nécessaire, je n’ai jamais beaucoup codé en assembleur, peut-être que cela m’a aidé quand j’ai fait du C, mais j’aurais bien pu m’en passer.
Plutôt que t’enfoncer essaie de t’élever vers des langages de plus haut niveau.
A l’apprentissage d’un langage ne t’arrête pas aux bases, trouve des exemples pratiques mettant en oeuvre des ‘frameworks’, des quadriciels dont je te défies d’avoir déjà entendu ce mot en français.
Les framework permettent de se se contrer sur la partie métier, par contre ils viennent avec de nombreux sous-entendus, des utilisations de formalismes qui vont au delà du langage.
Là encore il y a des modes. Dans le choix d’un framework préfère la dernière version majeure. Les changements peuvent être significatifs avec les version précédentes.
Si ce que tu as à faire existe presque sous une autre forme réutilise-le !
Une façon d’aborder un projet est de commencer par écrire des tests sur ce que le programme doit générer. Cela permet de vérifier que le programme fait bien ce qu’il doit et qu’on est d’accord sur ce qu’il doit faire. Et plus tard cela te permettra de te protéger des régressions, qui auront lieu fait moi confiance ;-)
Tu n’es pas seul, ton code n’est pas à ton usage unique, rend le attrayant. Indente le code et aère le avec des espaces. Sépare les phases différentes.
Le code doit être le plus facile à lire possible.
Ne code jamais avec en tête une optimisation dans le langage que tu utilises, les optimisations viendront dans un second temps à l’usage et uniquement si nécessaire. Par contre réfléchis parmi les algorithmes possible celui qui a la meilleur performance, si c’est trop complexe préfère l’algorithme le plus compréhensible.
N’utilise des appel récursif que lorsque l’équivalent en boucle n’existe pas ou qu’il est trop complexe. Documente absolument le fait que c’est une fonction récursive, n’hésites pas à faire apparaître dans la fonction le fait que c’est récursif par exemple en la préfixant par ’_Recurse’. Comme dans tout fonction récursive assure toi qu’il y ait bien une condition de fin, ce n’est pas toujours simple. D’ailleurs c’est une des limitations théorique et fondamentale de l’informatique qu’un programme ne peux pas toujours déterminer s’il va finir.
Les langages fonctionnels sont de plus en plus répandus et se sont répandus aussi dans les évolutions des langages impératifs. Un exemple frappant a été l’arrivée des lambda dans le langage Java.
Habitue toi à lire et écrire du fonctionnel, en particulier la fonction map(Liste,Fonction) qui applique une fonction à chaque élément d’une liste. Ainsi va le sens de l’histoire.
N’hésite pas à sortir une fonction de son contexte et de la tester avec des valeurs d’appel fixées.
Il y a deux approches possible : créer un faux contexte global de test ou bien simplifier la fonction pour avoir des paramètres listé indépendant d’un contexte plus général.
N’écrit pas des fonctions que tu peux trouver facilement dans des librairies.
Il y a certes des effets de mode, le XML par exemple est aujourd’hui moins apprécié que du json, du yaml. Les formats les plus lisibles sont à conseiller, comme le toml. Le CSV a fait ses preuves même si d’est standard non standard … Pour un nouveau développement choisi les standards les plus récents. Pour un code existant conserve les formats plus anciens, sans t’interdire d’en ajouter de nouveaux s’il restent compatibles.
Le graal pour un codeur, ou du moins celui que je souhaite, c’est d’avoir créé un langage de programmation. Résiste à cette tentation !
Si on dépend d’un libraire en choisir une qui fait juste ce que l’on veut et pas plus, sauf bien-sûr si une libraire plus générale est déjà utilisée dans le projet.
Don’t Fix It if it’s not broken.
Les régressions sont le grand défaut des réécritures de code, il faut vraiment réfléchir avant de se lancer dans du ‘refactoring’.
Ne pas se répéter. DRY Don’t Repeat Yourself
Factorisez le code le plus tôt possible, afin de ne pas tomber dans un grand refactoring
voici un exemple naïf de factorisation par DRY :
poids_kg = batiment[0].cochon[4].poids_kg
taille_m = batiment[0].cochon[4].taille_m
tumalu = batiment[0].cochon[4].tumaluDans ce code a l’impression de rentrer dans le bâtiment de chercher le cinquième cochon, de calculer sa taille, sortir du bâtiment puis recommencer pour avoir le poids et encore pour le tumalu. Si jamais on s’intéresse à un autre cochon il faut repréciser le bâtiment et le numéro du cochon, alors qu’il suffirait de se placer devant le bon cochon …
Voilà ce qui se passe quand on sêche le cochon :
cochon=batiment[0].cochon[4]
poids_kg = cochon.poids_kg
taille_m = cochon.taille_m
tumalu = cochon.tumaluOn évite de répéter batiment[0].cochon[4] , ceci n’est pas pour des raisons d’optimisation car le compilateur sait le faire, mais pour simplifier et faciliter la lecture et la maintenance. Si l’on doit changer le cochon de bâtiment, il n’y aura qu’une ligne à changer. On voit aussi que pour avoir la taille du cochon, il est juste nécessaire d’avoir le cochon, pas de savoir que c’est le cinquième cochon du premier bâtiment. On se rappoche aussi plus du langage naturel dans lequel nous dirions ‘ce cochon’ plutôt que de répèter d’où il vient.
On voit ici qu’avant de se lancer dans le copier/coller il faut d’abord vérifier si une factorisation n’est pas bénéfique.
L’IA apportera ici des avancées notables, cependant rien n’assure que les défauts introduit par du refactoring n’apparaissent pas non plus dans les formes entraînées de l’IA.
Dans les même conseils que DRY, si vous avez à taper de multiple fois une longue ligne de commande, créez un script !
Copie/Colle les noms variables. Utilise un environnement de développement (IDE) adapté
Avant même de documenter comment, il faut documenter ce que le programme fait et pourquoi il a été créé. Ce code se trouvera probablement sur GitHub, combien de projets se trouvent sur cette plate-forme dont on a aucune idée de ce qu’il sont censé résoudre comme problème !
Comment installer le programme. Un programme qui ne s’installe pas c’est un livre dans une vitrine fermée. Le mieux est d’avoir un script d’installation qui fait tout ce qu’il faut. La documentation d’INSTALL doit être réduite, mais si aucun script n’est disponible, la procédure doit être précise et surtout les pré-requis : de quoi dépend ce programme !
Des captures d’écrans si nécessaire et une documentation utilisateur? Sur des projets importants la réalisation d’une documentation est une activité spécialisée qui doit requérir l’aide d’une personne formée et experte dans la rédaction de documentation.
Ton code restera et tu l’oublieras, les commentaires sont là pour ça.
Pour les développeurs rejoignant le projet.
Une variable qui recouvre une valeur métier doit être lisible et compréhensible même pour un non informaticien. Il ne faut pas hésiter s’il elle doit être moyennement longue, les compilateurs gèrent ceci l’impact des noms longs sur le temps d’exécution ne vaut pas de s’en priver.
Même la la NASA en a fait l’expérience :
L’absence de conversion des unités anglo-saxones en unités métriques dans un segment du logiciel de navigation de la sonde Mars Orbiter a provoqué son crash.
Une distance en mètres ou en pieds ce n’est pas la même chose.
Les variables doivent contenir un type cohérent de données et dans une unité définie. Une durée en heure, en secondes ou en milliseconde, ce n’est pas la même chose. N’hésite pas à le préciser dans le nom de la variable ex : temps_de_cuisson_minute.
Il faut s’habituer à ne pas utiliser de variables globales mais définir tous les paramètres nécessaire à la fonction lors de son appel. Plus les variables sont isolées plus il est facile de déplacer et réuitliser le code dans un autre contexte.
Si une variable DureteDuSolide est utilisée dans un code en python, réutilise le même nom dans le code en C. Ceci simplifiera la recherche et la compréhension du cod.
Sauvegarde ton code et conserve ses différentes versions. Git est là pour ton salut, apprends son fonctionnement. Une sauvegarde n’a d’intérêt que si elle peut être restaurée.
Sépare les changements fonctionnels des changement de présentation. En particulier n’inclus pas de nouvelles fonctionnalités si tu améliores la lisibilité du code, par factorisation par exemple. Groupe dans un seul changement l’activité de release, le changement d’année de copyright et liste des nouvelles fonctionnalités. Chaque fonctionnalité doit être couverte par un bloc de changement différent (commit).
Ici aussi il faut faire attention à l’utilisation de l’IA qui peut changer la présentation lors de l’introduction de fonctionnalités.
Il ne faut pas hésiter entre deux versions de supprimer le code mort, c’est à dire le code qui n’est plus utilisé. Commenter un bloc de code que l’on sait ne plus avoir à utiliser n’a plus de sens avec des outils de suivi de version comme git, du code non exécutable doit être retiré. Si on souhaite vraiment indiquer une alternative alors une ligne de commentaire dans le code pour pointer sur la version de git qui propose l’ancienne alternative est un maximum.
Le code mort est une plaie pour les personnes qui reprennent un projet et se perdre dans des fonctions qui n’ont plus lieu d’être et présentent des structures de données ou des foncitons obsolètes.
Dans des version mineures certaines fonctions peuvent être indiquées comme déprecié et obsolète, ceci fera apparaître lors de la compilation ou à l’exécution des avertissements. Retirer le support de ces fonction ne doit pas être réalisé dans une version mineure. Mais surtout quand on modifie une fonction existante ou bien qu’on la remplace il faut impérativement fournir la documentation adéquate pour permettre aux développeurs de passer de faire la mise à jour dans leur code et plusieurs exemples. L’idéal ici est de fournir un outil qui fait la migration tout seul…
Une changement de présentation, d’interface de programmation ou de paradigme ne doit avoir lieu que dans des versions majeures.
Utilise l’IA avec parcimonie, ne lui fait pas plus confiance qu’à toi même.
Une interface de programmation : API est une abstraction.
Pour un développement donné suis scrupuleusement les procédures d’installation.
Ne mélange pas ton environnement de travail quotidien et l’environnement de programmation, ne mélange pas non plus deux projets de programmation différents. Un système dédié au développement est nécessaire avec une isolation particulière pour être aligné avec les dépendances.
L’isolation peut être réalisée par divers moyens, certains propres au langage lui-même, par exemple les virtualenv pour python, ou bien par des solutions de chroot/jail conteneurs ou même virtualisation complète du système.
Coder c’est débugguer !
Ton code ne marchera pas du premier coup. “L’échec est le fondement de la réussite”
N’hésites pas à truffer ton code temporairement d’écriture en console avec les valeurs de variables et des informations sur l’endroit du code. C’est le moyen qui marche partout.
Comme le print, les logs sont cependant conçus pour durer dans la version en production, chaque niveau doit bien être étudier. Trop de logs tuent les logs, trop peu de logs vous laissent perdus.
Sur un projet existant trouver où sont les logs peut être compliqué,
d’une part il faut préciser dans la configuration le niveau de logs mais
aussi souvent la librairie ou le système utilisé. Les logs peuvent être
dans ceux du serveur web ( ex /var/log/nginx/ ), dans ceux de systemd
(journalctl -u
Chaque langage propose des librairies pour les logs.
Ne pas laisser d’exception silencieuse ! Le moins qui puisse être fait est d’avoir un niveau de log TRACE qui les affiche avec la pile d’exécution.
C’est grâce à ces trace que la recherche dans les moteurs de recherche permet de sortir d’une impasse sur un programme que l’on ne connaît pas. Pour rechercher dans un moteur de recherche, conserver uniquement ce qui est générique, les chemin locaux à votre installation, les contenus de variables propres à l’exécution doivent être enlevés, par contre les noms de fonctions, le numéros de lignes, les codes d’erreur et le texte des logs ou des trace doit être conservé.
L’utilisation d’un débogueur est simplifiée si elle est intégrée dans l’environnement de programmation. Il ne faut pas hésiter alors à utiliser des fonctions avancées pour stopper le code quand des variables atteignent certaines conditions. Sinon tu es condamné à parcourir pendant des heures des boucles qui n’en finissent pas.
Parce qu’il faut bien finir, le sujet est sans fin et tout peut être discuté !
Si tu es arrivé jusqu’ici, bravo !
Et si tu te demandes ce que peut bien être le tumalu d’un cochon, et bien puisque tu m’as lu, tu le sais !