Closed dpobel closed 6 months ago
Je suis tombé aujourd'hui sur Quality is +systemic de Jacob +Kaplan-Moss que je trouve particulièrement juste.
+Traduction rapide du premier paragraphe :
+++La qualité logicielle est plus le résultat d'un système conçu pour produire de +la qualité et pas tellement le résultat de performances individuelles. +C'est-à-dire : un groupe de programmeurs médiocres travaillant avec une +structure conçue pour produire de la qualité produira un meilleur logiciel +qu'un groupe de programmeurs fantastiques travaillant dans un système conçu +pour d'autres objectifs.
+
En d'autres termes pour obtenir de la qualité il faut une organisation +construite pour la produire. L'auteur donne quelques exemples de +caractéristiques systémiques permettant de produire de la qualité :
+Je trouve ce dernier point particulièrement important. À titre personnel c'est +quelque chose que je m'attache à toujours faire mais j'ai vu relativement peu +d'organisations où c'était une démarche systématique.
+Et il existe probablement des tas d'autres paramètres comme une culture qui +permet une forme d'auto-organisation et offre une certaine liberté, une +organisation où on ne travaille que sur un seul sujet à la fois ou encore une +culture qui célèbre autant voire plus la suppression de code que l'ajout… Tout +ceci fait largement écho à Maximiser l'efficacité des +développeur·ses sous un angle plus… +systémique.
+]]>Pas de grosse activité de ce côté avec seulement 3 billets :
- -Les 3 billets les plus lus de l'année ont été dans l'ordre :
-Bon là, il s'est passé des trucs, trop de trucs… j'ai cumulé 4 employeurs en -2020, ce qui fait 3 changements de travail en une seule année, c'est autant que -dans mes 15 années précédentes… et je peux même pas mettre ça sur le dos de la -crise sanitaire. J'ai aussi subi ma première rupture de période d'essai, eu à -fréquenter activement Pôle Emploi… j'ai connu des jours meilleurs mais bon -heureusement tout ça se termine positivement et rapidement avec un chouette -poste en télétravail (choisi pas subi) sur du Node.js ! Je vais pas me -plaindre, bien au contraire, je trouve cette situation limite indécente. Je -mesure plus que jamais le privilège de pouvoir retrouver du travail aussi -facilement même lorsque le monde semble s'effondrer tout autour.
-Une bonne année de lecture autant en qualité qu'en quantité même si, en prenant -un peu moins le train, la pile de livre de 2020 est un -peu moins conséquente que l'année dernière. Si je devais en retenir cinq :
-Ces 5 livres permettent de découvrir le biomimétisme et les principes du -vivant, d'apprendre plein de choses sur l'évolution des êtres humains, -d'envoyer gentillement paître celles et ceux qui t'expliquent qu'il faut dire -LA covid parce que quelqu'un à l'académie française croit avoir la légitimité -de décider ce genre de chose, de se poser quelques questions sur notre mode de -vie et notre rapport à l'argent et enfin d'imaginer un monde post-effondrement… -Bon OK le dernier est peu être pas le plus adapté à 2020, à ma décharge, je -l'ai lu en janvier 😉
-Encore une année de sécheresse, encore une année très moyenne en terme de -récolte 😑 aggravée par une absence pendant une période de canicule qui a ruiné -des plants qui semblaient bien partis. Adieu les courges, les haricots, les -melons, le maïs et tout ce qui pouvait traîner au jardin mi-août… Finalement, -seules les récoltes de pommes de terre, de tomates et de noix sauvent un peu la -saison. Pour 2021, j'ai investi dans des fraisiers, des framboisiers, de la -vigne, un plant de kiwi et je vais bientôt planter un abricotier avec un peu de -chance je pourrai récolter quelques fruits dès cette année 😋
-Je vais pas reprendre la liste de bonnes résolutions que je traîne d'année en -année, de toute manière elle change pas, mais promis je vais essayer de m'y -mettre !
-Plus sérieusement, on espère toutes et tous une meilleure année 2021 c'est -évident; le et surtout la santé hein des traditionnels vœux prend tout son -sens en ces temps difficiles et c'est bien le moins qu'on puisse tous se -souhaiter.
-]]>Je suis tombé aujourd'hui sur Quality is +systemic de Jacob +Kaplan-Moss que je trouve particulièrement juste.
+Traduction rapide du premier paragraphe :
+++La qualité logicielle est plus le résultat d'un système conçu pour produire de +la qualité et pas tellement le résultat de performances individuelles. +C'est-à-dire : un groupe de programmeurs médiocres travaillant avec une +structure conçue pour produire de la qualité produira un meilleur logiciel +qu'un groupe de programmeurs fantastiques travaillant dans un système conçu +pour d'autres objectifs.
+
En d'autres termes pour obtenir de la qualité il faut une organisation +construite pour la produire. L'auteur donne quelques exemples de +caractéristiques systémiques permettant de produire de la qualité :
+Je trouve ce dernier point particulièrement important. À titre personnel c'est +quelque chose que je m'attache à toujours faire mais j'ai vu relativement peu +d'organisations où c'était une démarche systématique.
+Et il existe probablement des tas d'autres paramètres comme une culture qui +permet une forme d'auto-organisation et offre une certaine liberté, une +organisation où on ne travaille que sur un seul sujet à la fois ou encore une +culture qui célèbre autant voire plus la suppression de code que l'ajout… Tout +ceci fait largement écho à Maximiser l'efficacité des +développeur·ses sous un angle plus… +systémique.
+]]>Vous ne pouvez pas gagner. Vous ne pouvez que retarder la fin de la partie.
-Comme beaucoup de gens qui y ont joué, j'adore Tetris. Je me souviens de ma -première partie sur la Nintendo Game Boy d'un ami. Peut-être avez-vous encore la -musique en tête. Tetris est non seulement l'un des meilleurs jeux de tous les -temps, mais c'est aussi une excellente analogie de la dette technique. Le but de -cette analogie est comprendre la dette technique et ses conséquences.
-Je vais en plus partager une histoire sur comment mon équipe a réduit la dette -technique dans du code lié à la facturation et comment nous avons corrigé un -bug coûtant 1 million de dollars par an.
- - -Chez les éditeurs de logiciels, les chef·fes de produit ou les chef·fes de projet -travaillent avec les développeur·ses pour prioriser les fonctionnalités qui -seront développées et livrées aux clients. Terminer une ligne à Tetris est -comme livrer une fonctionnalité.
- - -Développer et livrer une fonctionnalité complexes nécessite plus de -lignes.
-Souvent, des fonctionnalités nécessitent des compromis dans le code (des hacks -ou des raccourcis) pour être livrées à temps. Parfois, les changements de -stratégie produit sont incompatibles avec des choix techniques précédents ce qui -implique un effort supplémentaire pour soit migrer les clients existants soit -être capable de gérer à la fois la "nouvelle" et "l'ancienne" logique.
- - -Ce genre de scénario crée de la dette -technique dans le code. Un -trou enterré dans une partie de Tetris représente de la dette technique.
-Tout code possède de la dette technique. C'est parfaitement normal. Vous pouvez -continuer à jouer à Tetris même avec quelques trous.
- - -Trop de dette technique ralentira la correction des dysfonctionnements et le développement de nouvelles fonctionnalités.
-Il ne s'agit pas d'un problème qui peut être résolu en ajoutant plus de -développeur·ses ou en remplaçant celles et ceux déjà en poste. Dans dette -technique, il y a dette, à un moment ou un autre, elle devra être remboursée.
-Payer la dette technique permet de rester compétitif et concurrentiel
- - -Une partie de Tetris est semblable à la gestion d'une entreprise, plus la partie -dure, plus c'est difficile. Les pièces bougent plus vite et il est de plus en -plus difficile de suivre.
-Une partie de Tetris est semblable à la gestion d'une entreprise, il n'y a pas de -vraie ligne d'arrivée. Vous ne pouvez que retarder la fin de la partie.
-Une partie de Tetris est semblable à la gestion d'une entreprise, laisser trop de -trous dans la construction causera la perte de la partie.
-Il n'y a pas très longtemps, mon équipe devait mettre à jour la logique de -facturation dans le code de notre produit pour mettre en place un nouveau plan de -tarification, une nouvelle gestion de paiement et pour améliorer les étapes de -facturation. Pendant que l'équipe produit terminait de définir les détails, nous -avons commencé à nous plonger dans le code existant pour améliorer notre -compréhension de cette partie et être capable de fournir de meilleures -estimations pour les changements à venir.
-Le but principal de ce code était pour chaque client de calculer leur facture et -de l'envoyer à une API. Ce code avait été écrit relativement proprement même si -il manquait de flexibilité. Il s'agissait d'un fonction d'un seul bloc sans test, -quasiment sans journaux et sans documentation. Il semblait responsable de rares -problèmes apparaissant de manière aléatoire. Ce morceau de code avait été écrit -5 ans plus tôt par l'un des cofondateurs et n'avait été changé que rarement par un -des premiers employés qui a depuis quitté la société.
-Était-ce réellement un problème ? Les factures partaient. La société -gagnait de l'argent. Il n'y avait a priori aucun problème. Tout cela, aurait pu -nous dissuader de toucher à cette partie, mais en même temps nous savions que de -gros changements étaient en préparation et qu'en simplifiant cette fonction, -nous allions gagner du temps.
-Nous avons refactorisé cette fonction pendant une unique itération et nous avons -ajouté les journaux manquants. C'est à ce moment là que nous avons découvert ce -que nous avions vraiment corrigé. Une personne de la compatibilité est venu -nous voir en demandant pourquoi le nombre de factures émises avait augmenté -dernièrement. Il s'avère que l'ancien code échouait silencieusement et par -conséquent certaines actions de nos clients n'étaient pas facturées. Les rares -problèmes évoqués plus haut cachaient en réalité un problème plus important de -non facturation qui aurait du nous alerter. Il semble que le manque à gagner -s'élève à un peu plus de 1 million de dollars par an.
-Même si cette histoire est totalement vraie, rembourser la dette technique n'a -pas toujours un effet aussi considérable.
- - -J'aimerais pouvoir donner un conseil avisé sur quand il faut rembourser de la -dette technique. Malheureusement, la réponse est : c'est compliqué et il -s'agit toujours de trouver un compromis. Vous pouvez avoir le code le plus -propre et le mieux testé du monde sans aucun client prêt à payer pour. À -l'inverse, votre entreprise peut ravir ses clients et avoir des affaires -fleurissantes en mettant en œuvre du code de mauvaise qualité.
-En guise de conseil, il me semble que les chef·fes de produit et les développeur·ses -devraient connaître et comprendre ce qu'est la dette technique et le fait qu'on -ne peut l'éviter pour toujours. Après tout, comme dans une partie de Tetris, on -ne peut jamais gagner dans le logiciel.
-]]>
URL: https://811.damien.pobel.fr
Stats
Blog Blog | Open | Open | 8277 | 8229 | ❌️ Post | Open | Open | 11291 | 11236 | ❌️ Enhanced tag page (veille) | Open | Open | 8088 | 8055 | ❌️ Tag page pagination (javascript, page 5) | Open | Open | 10123 | 10068 | ❌️ Tag page (lecteur d'écran) | Open | Open | 6205 | 6150 | ❌️ Tags | Open | Open | 27359 | 27378 | ❌️ CV CV fr | Open | Open | 29471 | 29471 | ✅️ CV fr pdf | Open | Open | 112789 | 112789 | ✅️ CV | Open | Open | 28558 | 28558 | ✅️ CV en pdf | Open | Open | 89987 | 89987 | ✅️ Pages Page list | Open | Open | 8255 | 8200 | ❌️ About | Open | Open | 3510 | 3510 | ✅️ Misc Github profile | Open | Open | 2101 | 2046 | ❌️ Github page | Open | Open | 10355 | 10300 | ❌️ Photos Resized Photo (660x) | Open | Open | 32036 | 32036 | ✅️ Resized Photo (200x) | Open | Open | 5438 | 5438 | ✅️ RSS feeds (build date should be updated) RSS | Open | Open | 53689 | 51509 | ❌️ RSS tag | Open | Open | 46502 | 40776 | ❌️ RSS tag fr | Open | Open | 34783 | 34783 | ❌️
Diffs
Homepage
Blog
+ +La qualité est systémique +
++-
+
+veille
+
+-
+
+métier
+
+-
+
+bonnes pratiques
+
+-
+
+qualité
+
+-
+
+code
+
+-
+
+architecture
+
+
+ +