Petite anectode d'une journée de programmation

Voici une petite anecdote pour donner une idée à un non-programmeur de ce à quoi ressemble parfois notre boulot ^^


Pendant les RML17, on a discuté de l’importance de se passer des frais de transaction (cf FAQ V2s : questions & inquiétudes / RML17 puis FAQ - Communication - Forum Monnaie Libre), et on a évoqué plein de possibilités pour résoudre le problème très général du partage de la ressource blockchain (cf le post qui les résume Comment partager équitablement cette ressource commune qu'est la blockchain Ğ1? - #48 by tuxmain).

Après de longues discussions sur la manière d’implémenter l’une de ces solutions (cf Implémentation des quotas pour ceux qui veulent suivre le détail avec beaucoup de vocabulaire technique), on a fini par s’accorder sur un une implémentation du remboursement des frais de transaction en utilisant des quotas pour les identités membre qui nous semblait à la fois simple et élégante. J’ai travaillé dessus à quasi plein temps pendant plusieurs semaines.

Vendredi dernier, j’arrivais presque au bout de la première preuve de concept fonctionnelle : tout compilait et semblait s’exécuter normalement mais les derniers tests effectués le soir montraient que les remboursements n’avaient pas lieu. Un bug, donc, le programme ne se comportait pas comme je l’avais imaginé. Tant pis, c’était le moment de partir en weekend (dans le Lot) pour se changer les idées. Mais tout le weekend ce sentiment d’insatisfaction trottait dans ma tête : échouer si près du but !

Et là de retour après le weekend, je me remets devant le code et mon cerveau avait travaillé en arrière-plan, je savais exactement quoi faire pour aller au bout. Un tout petit fix (6ea902a7) et c’est réglé ! Je lance un test manuel, et victoire, ça marche, toutes les actions en blockchain effectuées par une identité membre sont bien “gratuites”, c’est-à-dire remboursés automatiquement par la blockchain en décomptant des quotas de l’identité membre.

On pourrait croire que c’est bon, je vais pouvoir passer à la tâche suivante, mais non, il s’agit uniquement d’une preuve de concept, il reste encore un long travail de stabilisation, de testage approfondi des cas limites, d’optimisation nécessaire, d’organisation du code avant de passer à la phase de relecture par d’autres développeurs. Et encore là il y aura sûrement des modifications à faire, et probablement importantes.

Sur la route il y aura à chaque fois des petites frustrations de choses qui ne marchent pas et des petites victoires quand un palier supplémentaire sera atteint. C’est un travail dans la durée, avec toujours une petite partie de la tête qui pense au code. Les pauses sont essentielles, sans elles on peut rester longtemps bloqué sur un problème. On met longtemps à obtenir un code qui semble fonctionner et encore aussi longtemps à obtenir un code qui fonctionne en conditions réelles et dans lequel on a confiance qu’il n’y a pas trop de bugs.

Une fonctionnalité en apparence aussi simple que les quotas peut mettre des mois à être intégralement développée, même à plein temps. Mais une fois qu’elle est en place, elle bénéficiera à tout le monde sans effort. Voilà pourquoi on a besoin de développeurs à plein temps pour sortir une Ğ1v2 en un temps raisonnable, sans quoi le travail pourrait s’étendre sur des années. Je reviendrai ici pour faire un retour similaire quand le code sera fusionné à la branche principale, c’est-à-dire relu et validé par les autres développeurs.


Mon travail est actuellement permis par un mécène qui a choisi de me financer pour travailler sur Duniter. Si vous aussi vous avez les moyens, adoptez un développeur : permettez-lui de consacrer du temps pour ce projet libre utile à tous. Et si vous ne pouvez pas le faire à titre individuel, n’hésitez pas à rejoindre l’association Axiom-Team pour participer à la recherche d’autres sources de financements qui permettront à des développeurs de consacrer l’énorme quantité de temps nécessaire pour avancer sur ce logiciel libre.

10 Likes