Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Point de vue : Le développement de Rave (quatrième partie)
(Article écrit par Daniel Jedlicka et extrait de Rear Window - juin 2022)
|
|
Note : traduction par David Brunet.
Les cinq derniers pour cent
Dans les milieux du management, il y a une plaisanterie récurrente selon laquelle les cinq derniers pour
cent d'un projet représentent 95% du temps de réalisation total. Si vous êtes un développeur de logiciels,
ce paradoxe amusant peut vous rappeler quelque chose, car vous l'avez sans doute déjà expérimenté.
Votre projet avance rapidement jusqu'à ce qu'il atteigne un point où il est presque terminé, à l'exception
de quelques petites choses qui ne le rendent pas encore diffusable. Ces "quelques petites choses" peuvent
transformer la phase finale du projet en un cauchemar qui s'éternisera pendant des mois, voire des années.
J'ai appris cette leçon lorsque je travaillais sur ma première application AmigaOS 4, le dictionnaire
WordNet,
en 2009. Je venais de redécouvrir la passion de l'Amiga après neuf ans d'utilisation exclusive
d'un PC, et j'étais très enthousiaste à l'idée de développer pour une communauté où chaque nouveau logiciel
semblait faire la différence. J'ai réalisé une version préliminaire du programme en deux semaines environ,
avec l'interface graphique et tout le reste - puis j'ai passé deux mois de plus à peaufiner WordNet
et à l'amener à l'état de version diffusable. L'une des raisons est que j'ai dû apprendre certaines
spécificités d'AmigaOS 4 et revoir des choses que j'avais oubliées. Mais en toute honnêteté, c'est ma
mauvaise planification qui a causé le plus de retard. La notion de
produit minimum viable m'a complètement
échappé à l'époque, et j'ai continué à ajouter fonctionnalité sur fonctionnalité jusqu'à ce que je sois
rattrapé par la fatigue et la frustration.
On pourrait croire que je sois tombé dans un piège similaire avec le projet Rave, surtout si vous
vous souvenez que dans mon précédent
billet, j'espérais pouvoir sortir le programme avant la fin du mois de mars 2022. Mais la raison
était différente cette fois-ci, et je peux dire honnêtement que la sortie aurait eu lieu si seulement
les événements n'avaient pas encore pris le dessus sur moi.
En testant Rave au début du printemps 2022, je me suis rendu compte d'un défaut de conception dans
le système de gestion de projet du programme qui rendait difficile l'interruption fiable et sûre
d'une opération en cours. Comme une nouvelle conception du fonctionnement interne de Rave prendrait
un temps considérable (que je n'avais pas), j'ai pensé publier le programme tel quel et l'améliorer
plus tard. Cependant, vers la fin du mois de mars 2022, l'école pour laquelle je travaille m'a informé
que j'allais superviser un groupe d'étudiants pendant leur stage en Allemagne, qui était censé avoir
lieu en mai 2022. L'idée de passer une semaine entière sans pression parentale m'a tout de suite plu,
car cela sentait l'occasion d'examiner le problème de plus près.
Le stage s'est déroulé à Chemnitz,
une ville de Saxe autrefois connue sous le nom de Karl-Marx-Stadt.
Il est vite devenu évident que la formation de mes étudiants était organisée avec la rigueur et
l'efficacité proverbiales des Allemands, ce qui me rendait pratiquement inutile en tant que superviseur,
car tout avait été pris en charge. J'avais donc encore plus de temps à perdre que prévu et (à l'exception
d'une promenade occasionnelle) j'ai passé la majeure partie de la semaine dans ma chambre à chasser
des bits et des octets sur mon fidèle ordinateur portable.
Je suis la deuxième personne à gauche, avec Karl Marx et mes étudiants
La possibilité de se concentrer sur Rave pendant plusieurs heures par jour a fait toute la différence,
par rapport à mes séances de programmation tardives et fatigantes à la maison. Je me souviens d'un
message sur un forum dans lequel un utilisateur Amiga bien intentionné essayait de motiver les
développeurs en leur disant d'essayer de s'asseoir pour programmer tous les jours, même si ce n'était
que pour cinq minutes. Mais ce n'est pas ainsi que cela fonctionne, malheureusement. En réalité, un
programmeur ne peut faire que peu de travail en une heure, donc laisser tomber les cinq minutes -
surtout lorsqu'il travaille sur un projet de grande envergure. À cet égard, la semaine passée à Chemnitz
s'est révélée être une véritable bénédiction. Le fait de m'y plonger avec toute ma concentration m'a
permis de réécrire entièrement le système de gestion de projet, y compris l'API des greffons et le module
des entrées-sorties, ce qui, autrement, aurait pris des mois. Le résultat est une conception plus simple,
plus fiable et nécessitant moins de communication entre les différents composants du programme.
Entre autres choses, il est maintenant plus facile de créer un greffon car le programme principal et le
module maître du greffon se sont vus confier certaines tâches communes. L'architecture des greffons
doit encore être améliorée : actuellement, seuls les greffons de traitement sont gérés, c'est-à-dire
ceux qui prennent des données audio et les modifient. Cela convient à l'application d'effets, mais j'aimerais
aussi introduire des greffons qui génèrent du son, ou simplement analysent les données et affichent des
informations à leur sujet. Cela va prendre un certain temps avant que l'architecture ne devienne suffisamment
bonne, mais quand ce sera le cas, je l'ouvrirai pour que d'autres personnes puissent développer des greffons
pour Rave si elles en ont envie.
Et bien sûr : le problème qui a tout déclenché a maintenant disparu. Comme je l'ai déjà dit aux
personnes qui me suivent sur Facebook
ou Ko-fi, toute opération en cours - même le chargement,
la sauvegarde et le traitement - peut maintenant être interrompue en toute sécurité en appuyant sur
la touche "Échap". En fait, je pense que Rave gère mieux l'interruption que
SoundForge Audio Studio 16,
qui est mon éditeur préféré sur PC. Lorsque vous interrompez une opération dans SoundForge, le programme
affiche une demande de confirmation mais l'opération se poursuit sans interruption. Donc si vous prenez
votre temps et ne cliquez pas tout de suite sur le bouton "OK", l'opération peut s'être terminée entre-temps.
Pour être honnête, je ne trouve pas cela très utile (ou logique). Dans Rave, l'opération attend que vous
répondiez à la requête, puis elle continue ou s'arrête. C'est, je crois, le comportement attendu, et c'est
l'un des avantages de ma réécriture.
Rave : interruption au milieu d'une opération de changement de niveau
Plus important encore, le programme est maintenant prêt à être diffusé dans le monde. Au cours de
l'année écoulée, il y a eu des moments où j'ai sérieusement douté que je serais un jour capable de
le dire, mais voilà : je suis heureux d'annoncer que les derniers cinq pour cent du projet ont été
achevés, et que la version initiale de l'éditeur Rave peut enfin être téléchargée sur
OS4depot.
C'est tellement bon de le dire que je suis tenté de le redire, ce qui est tout à fait idiot,
mais vous pouvez imaginer à quel point je suis heureux maintenant que ce poids a disparu de ma poitrine.
J'ai l'impression de laisser tomber une pierre de la taille de la tête de Karl Marx à Chemnitz !
|
