Aphorismes des développeurs : Sagesse des stand-ups et des revues de code
Au fil des ans en développement embarqué, une collection de phrases s'accumule qui accèdent au rang d'aphorismes. Elles capturent les réalités du codage pour microcontrôleurs, de la conception de circuits et de la gestion de projets. Voici une sélection issue de 12 ans d'expérience pratique : des principes de code aux périphériques MCU.
Aphorismes sur le code et l'architecture
Les programmeurs se divisent en deux camps : ceux qui écrivent du code de zéro, et ceux qui portent des bibliothèques open-source. L'universalité d'un ordinateur en tant que dispositif de calcul est la définition du manuel — bien que pas tous les diplômés en physique et technologie l'acceptent.
Principes clés :
- Il y a une config pour tout : le meilleur code n'est que de la configuration.
- Coder séparément, configs séparément.
- Un bon code cristallise au fil des ans.
- Principe de moindre étonnement à l'écriture.
- Le meilleur algorithme est un tableau (une machine à états finis se réduit à un graphe et un tableau).
« La programmation est un marathon, pas un sprint. » (Robert Martin)
L'uniformité du code prime sur la beauté : « Écrivez du code uniformément — moche, c'est bien. » Les tableaux sont la base de tout. Chaque setter a besoin d'un getter : xxx_write() exige xxx_read(). Le nom d'une fonction est son commentaire. Moins de commentaires textuels, plus propre le git diff.
En C : si une fonction ne tient pas sur un écran, elle ne marche probablement pas. Toute tâche se résout en une ligne — un appel de fonction. Le meilleur commentaire est le nom du fichier.
Tests et CI/CD
Un repo sans CI n'est que du papier brouillon. Le système de build doit être uniforme, quel que soit l'éditeur. Du code sans tests unitaires ? Même histoire.
« Un programme qui n'a pas été testé ne fonctionne pas. » (Bjarne Stroustrup) « Le TDD est le choix des professionnels. » (Robert Martin)
La connaissance se transmet par écrit, pour des passations en douceur. Un codebase portable est la pierre angulaire des projets futurs. Tous les protocoles se réduisent à un memcpy entre appareils.
Conception de circuits et matériel
Les hardwareux lancent : soyez comme un CPU — refusez la surtension. L'ingénierie électrique est la science des connexions manquantes. Le développement commence par les outils de debug.
Tous les capteurs mesurent la température, chacun à sa manière. Au-delà de 100 MHz, les signaux deviennent analogiques. Tout en électronique est un ADC ou un DAC : codecs, transceivers, même GPIO comme DAC 1 bit.
Choix d'interfaces : SPI l'emporte sur I2C. Les Russes conçoivent des cartes pour du code européen, les Européens codent pour des cartes chinoises. La meilleure pièce est l'absence de pièce.
Microcontrôleurs et firmware
Le hardware d'abord, le software ensuite. Plus le schéma est simple, plus le firmware est retors — et inversement. Firmware sans hardware, c'est sculpter d'après une photo.
Les périphériques se synchronisent sur l'horloge du core. Le firmware commence par un bootloader. Un reset guérit sept maux. La fonctionnalité tueuse ? Les mises à jour de firmware.
Les protocoles universels se multiplient : de 12 à 13. L'assembleur, c'est manger du sarrasin avec des pincettes. NVRAM upgrade tout. UART-CLI est indispensable : sans, c'est branche et prie.
Les logs UART sont la boîte noire du firmware. Un MCU est un pilon pour broyer des nombres ; x86 est un mixeur. CLI stimule la créativité, GUI vous enferme. Les machines à états finis sont le marteau d'or des MCU.
Un vrai MCU a besoin : timer de uptime, LED heartbeat, UART-CLI, NVRAM, tests unitaires. Sinon, c'est une chaîne inutile. Le firmware ne s'écrira pas tout seul.
La modularité, c'est construire pour plusieurs plateformes à la fois.
Gestion et projets
On le construit pas parce que c'est simple, mais parce qu'on le croyait simple. La moitié de ce qu'on enseigne est du charlatanisme — le truc est de repérer lequel (Loi de Larrabee).
Développer à la spec : pas de dorure superflue. Négocier, c'est le boulot. « Ne rien faire » sur demande ? Tâche terminée.
« Un résultat négatif est toujours un résultat. » (Niels Bohr)
Une mauvaise solution avec un bon rapport finit par sauter ; une bonne avec un mauvais rapport est tuée net (Loi d'Akin). Gérer, c'est ne pas être dans les pattes.
Les compromis sur la qualité s'équilibrent à la hausse. Ne pas boulonner un réservoir d'essence sur un chien. Mieux vaut trouver le bug maintenant que sur l'étagère. Brainstorming ? Rôtissage d'idées.
Construire non ce qu'ils demandent, mais ce dont ils ont besoin. Le parfait est l'ennemi du bien. Les mauvaises choses arrivent d'elles-mêmes. Rapide et bâclé reste dans les mémoires comme bâclé ; lent et solide comme solide (Korolev).
Ce qui compte vraiment
- Le code doit être portable et testable : TDD, tests unitaires, CI unifiée.
- En embarqué : UART-CLI, logs, machines à états finis — les essentiels du debug.
- Hardware en premier : des cartes simples facilitent le software.
- Projets à la spec, docs par écrit.
- Planification successorale : connaissance figée, repo impeccable.
— Editorial Team
Aucun commentaire pour le moment.