Thierry De Pauw - Non-Blocking Continuous Code Reviews, a Case Study

[00:00:05] Alors, je suis Thierry, de Belgique. Terre de chocolats.
[00:00:13] Et euh, je suis un orateur assez timide et un introverti. Donc, c'est un peu horrible.
[00:00:24] Oui, hourra.
[00:00:32] Euh, avant que j'oublie, euh, Je suis francophone. Ben, euh, c'est ma langue maternelle. Ah le con, il fait sa présentation en anglais.
[00:00:48] Ben oui, voilà. Euh, ben voilà, parce que je je je fais la plupart du temps mes présentations en anglais et voilà, ça ça je l'ai fait quelques fois en français, mais bon, ça prend un temps énorme à traduire. Euh, donc voilà, désolé. Mais, vous pouvez poser vos questions en français à la fin si vous voulez. Moi, je vais essayer de faire la traduction.
[00:01:14] Ça marche pas toujours très bien, mais soit. D'accord. Alors, je viens de dire que les gens peuvent poser des questions en français et j'essaierai de traduire. Ce qui ne fonctionne pas toujours très bien. Alors maintenant, allons-y. Euh, donc je veux plaider en faveur des revues de code continues non bloquantes par opposition aux requêtes de tirage classiques, communément acceptées et omniprésentes. C'est une chose que nous avons faite en 2012 avec une équipe assez novice. Euh, je n'en ai pas beaucoup parlé. C'est seulement la quatrième fois que je présente ceci depuis l'année dernière. C'est seulement l'année dernière que j'ai commencé. Euh, j'en ai occasionnellement parlé sur les réseaux sociaux. Mais à part ça, je n'ai pas fait grand-chose, parce que, eh bien, je n'avais pas réalisé que cette chose était en fait une chose. Ce n'est que euh, lorsque Martin Mortensen du Danemark a écrit son expérience dans un article en 2020 que j'ai commencé à réaliser, oh, cela semble être quelque chose. Et il a également inventé le terme de revues de code non bloquantes. Donc, et en fait, il n'y a que Martin et moi qui en parlons. Donc, ça commence à prendre de l'ampleur. Euh, j'ai donc vu Ken le mentionner parfois.
[00:02:39] Et puis, un jour en 2023, un dimanche matin, je cuisinais.
[00:02:46] Soudain, un message est apparu sur mon téléphone et vous vous dites, eh bien, oh, le monde a quelque chose à me dire. Ça doit être très important. Eh bien, en fait, c'était important parce que oui, Dave Farley nous contactait. Waouh, flatteur. Euh, me disant, oh oui, vous avez mentionné ces revues de code non bloquantes et et j'aime vraiment le son de cela et je pourrais faire une vidéo à ce sujet. Pouvez-vous me diriger vers un article ? D'accord. Euh, je n'avais pas d'article à ce moment-là, alors je me suis dit, oui. Attendez une minute. Donnez-moi cinq. Eh bien, cinq sont devenus quatre heures cette nuit-là. Mais finalement, j'ai écrit ça et donc me voici. Maintenant, d'accord, j'allume. Maintenant, avant de continuer, euh, j'aimerais explorer pourquoi nous effectuons des revues de code. Quel est son but ? Que voulons-nous accomplir ? Et c'est souvent là que réside le premier problème auquel les équipes sont souvent confrontées, à savoir qu'elles prennent une décision consciente sur ce qu'elles veulent accomplir avec les revues de code. Et si elles l'ont fait, euh, ont-elles clairement défini ce que signifie un bon ou un mauvais design et à quoi ressemble un bon ou un mauvais code ? Donc, avant même de commencer les revues de code, eh bien, cela devrait être clarifié dès le départ afin que nous puissions avoir des revues de code de valeur. À l'époque, avec cette équipe, nous avions plusieurs raisons d'introduire les revues de code. Et la première était, eh bien, c'est un outil de mentorat. C'est une opportunité d'apprentissage. J'espérais donc qu'en quelque sorte, les membres de l'équipe apprendraient quelque chose en lisant le code des autres membres de l'équipe. Cela nous permet également de partager des connaissances, car l'équipe était responsable d'une vingtaine d'applications et de services, et tout le monde n'était pas impliqué dans toutes les applications et tous les services. Ainsi, cela a permis à l'équipe d'avoir une certaine conscience de cette partie différente de la base de code. Et bien, cela crée une appropriation collective et une compréhension partagée, quelque chose que la programmation extrême a identifié comme très important pour atteindre une meilleure qualité. Cela nous permet également de vérifier la lisibilité et la maintenabilité. Il ne s'agit donc pas d'imposer une norme de codage et des directives de codage. Donc maintenant, pour cela, nous avons des outils. Nous avons des linters et de l'analyse de code statique. Cela évite donc les conversations inutiles lors des revues de code concernant les espaces manquants. J'ai vu cela dans des équipes, vraiment. Alors maintenant, toutes les discussions concernant les espaces ou les tabulations, eh bien, ce sont des espaces, n'est-ce pas ? Ou des accolades à la fin de la ligne ou sur une nouvelle ligne. Eh bien, c'est sur une nouvelle ligne. Vous êtes d'accord, n'est-ce pas ? Donc, ces choses devraient être définies dès le départ. Et ensuite, nous avons des outils qui vont appliquer cela. Nous avons donc une machine qui va contrôler cela et ensuite elle interrompt la construction si des violations sont trouvées. L'ordinateur dit non. Alors maintenant, ici, la lisibilité et la maintenabilité consistent vraiment à savoir si nous pouvons lire le code comme un roman. Avons-nous les bonnes abstractions aux bons niveaux ? Et enfin, eh bien, je pensais que cela aidait à maintenir une certaine cohérence dans la conception. Maintenant, avec le recul, j'ai réalisé que c'était une erreur. Euh, repérer les problèmes de conception lors d'une revue de code est bien trop tard.
[00:06:27] Euh, nous devrions détecter cela beaucoup plus tôt. Et donc, eh bien, une meilleure approche serait d'adopter des ateliers de conception avant de commencer le travail afin de réduire les chances de retravailler.
[00:06:42] Mais encore une fois, ce n'était pas vraiment un gros problème pour l'équipe, car cela n'a jamais, le remaniement n'a jamais vraiment introduit de retards parce que nous avons pratiqué des revues de code non bloquantes et nous y reviendrons. Donc, c'étaient nos raisons d'avoir des revues de code en place. Maintenant, il y a d'autres raisons que les gens mentionnent, et la principale raison mentionnée principalement dans les industries réglementées est, eh bien, le principe des quatre yeux. Nous avons besoin de cela pour mettre en œuvre le principe des quatre yeux. Maintenant, d'après ce que je vois, c'est l'excuse ultime pour tout ralentir et stopper une équipe avec une valeur assez faible, autre que de rassurer les auditeurs que les cases de conformité sont cochées. Euh, donc pas très utile.
[00:07:33] Ainsi, la recherche est assez claire à ce sujet. Euh, les barrières de processus réduisent la qualité. Donc, la chose exacte que nous introduisons et qui est censée augmenter la qualité fait exactement le contraire. Cela réduira la qualité. De plus, cela introduit un énorme problème de confiance qui est bien plus, bien plus important. Souvent, les organisations confondent leur approche de la réglementation avec la réglementation elle-même.
[00:08:07] Pas du tout la même chose. La plupart des réglementations portent donc sur le fait de savoir si nous faisons ce que nous disons faire. Et les réglementations les plus rigoureuses disent, eh bien, nous devons avoir deux personnes pour l'examiner et nous devons avoir une piste d'audit de ce qui s'est passé. Ainsi, une meilleure approche pour mettre en œuvre les principes des quatre yeux est d'adopter la programmation en binôme ou le travail en équipe logicielle. Et Dave Farley a rapporté que même dans les industries hautement réglementées comme la santé, la finance ou les jeux de hasard, cela est suffisant pour mettre en œuvre le principe des quatre yeux.
[00:08:44] L'autre raison que j'entends à maintes reprises est : je ne fais pas confiance à mon code. Ainsi, nous voulons avoir un sentiment de sécurité, pas une vraie sécurité, un sentiment de sécurité, une illusion de contrôle.
[00:08:58] Or, il y a souvent des raisons très valables pour que les ingénieurs diluent cette responsabilité. Et cela se produit le plus souvent dans des environnements avec beaucoup de code hérité. Les ingénieurs ne comprennent pas le code et ont donc très peu confiance en leurs modifications quant à savoir si elles ont cassé l'application ou non. Ou cela s'est produit dans des organisations dysfonctionnelles avec beaucoup de reproches. Euh, et puis, alors que les ingénieurs veulent se protéger, ils se tournent vers d'autres ingénieurs pour gagner un peu plus de confiance en leur code. Maintenant, je ne pense pas qu'un processus puisse résoudre cela. Euh, et certainement pas une revue de code.
[00:09:44] C'est un problème culturel. C'est un problème de système et les problèmes de système ne peuvent être résolus que par la direction. Deming est assez clair à ce sujet. Donc si vous voulez en savoir plus à ce sujet, sur la relation entre la gestion et les problèmes de système, eh bien, je vous invite à lire « Hors de la crise » de Deming, euh, où il vous claquera au visage pendant 400 pages. Euh, maintenant, ce que le code ce que les revues de code ne devraient absolument pas être, eh bien, ce ne devrait pas être un exercice de pouvoir, ce qui arrive facilement lorsque les revues de code sont effectuées via des outils de manière asynchrone,
[00:10:24] par opposition à la réalisation de revues de code en face à face de manière synchrone. Et c'est pourquoi ce n'est pas une bonne idée d'introduire une hiérarchie dans les revues de code où seul le chef d'équipe ou seulement l'architecte ou les seniors peuvent effectuer des revues de code. Maintenant, nous devrions avoir de véritables revues de code par les pairs en place où tout le monde peut revoir le code de tout le monde. Nous ne devrions pas non plus assigner les revues de code à des ingénieurs seniors non formés qui manquent de compétences en mentorat ou qui manquent de compétences en mentorat ou de la capacité de communiquer clairement et de communiquer de manière constructive. J'ai vécu cela euh dans une organisation. Et j'étais j'étais assez senior à l'époque. J'avais donc assez de bagage pour me protéger. Néanmoins, c'est une expérience horrible. Donc, il y avait un composant central qui relevait de la responsabilité d'un chef quelque chose. Euh, et chaque fois que nous touchions au code, eh bien, il fallait qu'il soit revu par le chef quelque chose. Or, cette personne était particulièrement mauvaise en communication écrite, vraiment horrible. Et les gens n'arrêtaient pas de me dire, oui, mais c'est une personne gentille, vous savez. Oui, eh bien, ça peut être, mais je n'ai jamais rencontré la personne. Je ne les connais que par la communication via l'outil de discussion. Je n'aimais fondamentalement pas la personne, et à la fin, je ne suis pas resté très longtemps dans l'organisation. C'est l'une de mes missions les plus courtes et je suis presque sûr qu'ils ont perdu pas mal d'ingénieurs à cause de ce comportement. La revue de code ne devrait pas non plus varier en contenu en fonction de qui a écrit le code. Il y a un problème de partialité ici qui peut nuire de manière disproportionnée. Euh, donc il ne devrait pas y avoir de blâme et de nuisance. Donc, s'il n'y a pas de mécanisme en place pour organiser et former des revues de code efficaces, il est peu probable que le processus soit exempt d'abus et de préjugés. Ainsi, les relecteurs devraient écouter et réfléchir au code sans jugement et sans blâmer. Nous devrions offrir une oreille attentive afin que d'autres puissent mieux résoudre un problème. Et donc quiconque ne peut pas faire cela ne devrait pas effectuer de revues de code. Donc, en fin de compte, cela ne devrait pas être une expérience misérable. Et donc, si nous évitons l'exercice du pouvoir, les ingénieurs seniors non formés et le blâme et le préjudice, eh bien, nous progressons déjà beaucoup. Cela ne devrait pas non plus être un gardien.
[00:13:13] Les étapes de processus introduisent des retards et sont négativement corrélées à la qualité. Et enfin, ce ne devrait pas être une obligation.
[00:13:24] C'est une option. C'est un sacré choix de l'équipe de faire ou non des revues de code. Et nous ne sommes pas une équipe plus mature si nous effectuons des revues de code. J'ai vu tant d'équipes qui effectuent des revues de code et qui ne sont absolument pas matures et qui manquent des compétences d'ingénierie appropriées. Et vous n'êtes pas non plus une bande de vauriens si nous ne faisons pas de revues de code. Nous ne sommes pas des professionnels. J'ai vu des ingénieurs hautement qualifiés, des équipes très performantes, ne pas faire de revues de code. Ainsi, en 2010, j'ai travaillé dans une organisation de produits où nous avons décidé de n'effectuer des revues de code que sur les corrections de bogues, et non sur les fonctionnalités, car nous pensions que les corrections de bogues étaient les activités les plus risquées. Maintenant, les bogues étaient également assez délicats dans cette organisation car la plupart du temps ils étaient liés à des conditions de concurrence. Le genre de problème qui vous prend une journée pour reproduire le problème. Et puis vous êtes super content parce que vous avez passé une journée ennuyeuse à essayer de reproduire le problème et puis, eh bien, vous savez, oh, demain je pourrai le réparer. Chouette.
[00:14:35] Donc, en 2012, J'ai eu l'opportunité de démarrer une mission de coaching technique avec un collègue coach, nous étions donc tous les deux, dans le but d'améliorer les compétences d'ingénierie d'une équipe plutôt novice au sein d'une organisation assez conservatrice de l'industrie financière. Un acteur central majeur dans l'industrie financière. Euh, c'est assez drôle ce que nous avons accompli là-bas parce que, eh bien, cela a créé comme cette contradiction entre l'équipe et puis l'organisation conservatrice. Donc, j'ai déjà mentionné cette équipe auparavant et je suis assez fier de tout ce que nous avons fait avec cette équipe et cela a été possible parce que nous avions ce manager d'équipe incroyable, Stefan De Moorloze, qui était ouvert à toutes les idées que mon collègue coach et moi lui proposions. Il était comme, oh oui, oui, oui, bonne idée, vas-y, vas-y, vas-y, fais, fais, fais. Et euh, donc son approche pour son équipe était du genre, regardez, voici la mission de l'équipe. Faites ce que vous voulez. Je m'en fiche tant que cela correspond à la mission de l'équipe. Je vais m'occuper du marketing de l'équipe, ce pour quoi il était plutôt doué. Euh, maintenant, pour certains membres de l'équipe, c'était difficile. Cette façon de gérer était difficile, car ils étaient habitués au micromanagement. Et vous voilà, vous avez une direction qui ne vous dit pas quoi faire. Vous devez le découvrir. Donc, avec cette équipe, nous avons utilisé Subversion, parce que nous pensions que Git était un pont trop loin. Trop complexe, trop compliqué, trop de concepts à assimiler pour une équipe novice. Et parce qu'il était dit que le branching est douloureux avec Subversion, eh bien, nous avons aussi opté pour pas de branches du tout. Aussi parce que, eh bien, à l'époque, je ne comprenais pas grand-chose aux stratégies de branchement. Euh, et donc, cela a plutôt bien fonctionné. Tout le monde s'engageait directement dans la ligne principale et cela a plutôt bien fonctionné, car, eh bien, nous avons également introduit dès le départ la pratique de l'intégration continue et l'engagement de l'équipe selon lequel toute modification devait être couverte par un test automatisé, de préférence un test unitaire.
[00:16:47] Maintenant, comme l'équipe était novice, nous voulions mettre en place un certain mentorat. Mais,
[00:16:54] la programmation en binôme était difficile. L'équipe n'était pas particulièrement ouverte à l'idée. Et bien, dire à l'équipe, oh, nous allons commencer le pair programming, ça ne marche pas. Ils n'ont pas signé pour ça. Bien que nous ayons fait du pair programming d'un point de vue coaching, donc nous étions assis, mon collègue coach et moi, à côté des membres de l'équipe pour leur montrer comment les choses pouvaient fonctionner. Cela ne faisait pas partie de la culture de l'équipe, ce n'était donc pas une pratique instituée. Donc, la meilleure chose suivante que nous avons trouvée était, euh, euh, c'était les revues de code. Et à l'époque, j'étais un fervent défenseur des revues de code. Cela a changé maintenant, mais, J'étais donc un fervent partisan des revues de code, influencé par des livres comme « Code Complete » et « Facts and Fallacies of Software Engineering », ainsi que par les articles de Joel Spolsky. Quelqu'un connaît Joe Joe Spolsky ?
[00:17:50] D'accord. Alors, euh, dites quelque chose sur notre âge, peu importe.
[00:17:56] Ainsi, au début des années 2000, il était un entrepreneur à New York. Il est toujours un entrepreneur, mais il a également créé Trello et Stack Overflow avec la personne de Coding Horror,
[00:18:12] euh, l'autre blog. Maintenant, parce que l'équipe était euh novice, euh nous avons également décidé que chaque commit devait être révisé.
[00:18:25] Et comme nous n'avions pas de branches en place, eh bien, nous avons fini par effectuer des revues de code non bloquantes, ce qui était le résultat de l'application des principes lean et de la simplicité des choses. Maintenant, nous n'avions pas réalisé que cette façon de travailler était en fait une manière performante de faire des revues de code. Et et et pour être honnête, à l'époque, j'étais assez gêné par notre façon de travailler, parce que, eh bien, le reste du monde semblait très professionnel en utilisant des pull requests et nous ne l'avons pas fait, nous ne l'avons pas fait. Eh bien, avec le recul, il semble que, eh bien, nous n'étions pas si peu professionnels en fait. Nous étions en fait assez professionnels. Parce que l'équipe était novice, euh nous avons aussi décidé que chaque commit devait être révisé. Et comme nous n'avions pas de branches en place, nous avons fini par effectuer des revues de code non bloquantes, ce qui était le résultat de l'application des principes Lean et du maintien de la simplicité. Or, nous ne nous rendions pas compte que cette façon de travailler était en fait une manière performante d'effectuer des revues de code. Et et et pour être honnête, à l'époque, j'étais assez embarrassé par notre façon de travailler. Parce que, eh bien, le reste du monde semblait très professionnel en utilisant les pull requests et nous non, nous ne le faisions pas. Eh bien, avec le recul, il semble que, eh bien, nous n'étions pas si peu professionnels en fait. Nous étions en fait assez professionnels. Maintenant, le processus de révision était basé sur deux idées clés. Et la première idée clé était d'établir un processus de révision continue qui consiste en des révisions régulières dans le cadre du flux de développement. Ainsi, l'équipe a pratiqué Kanban et avait un tableau Kanban pour suivre le travail. Et donc chaque ticket sur le tableau Kanban était une fonctionnalité ou était un bug, mais pas une tâche. C'étaient des fonctionnalités complètes. Et cela a l'avantage de contraindre la taille de la fonctionnalité, car nous voulons déplacer ces tickets rapidement de gauche à droite. Et donc, eh bien, nous étions forcés de garder ces fonctionnalités petites. Maintenant, l'unité de travail sur le tableau Kanban était la fonctionnalité. Mais la fonctionnalité n'était pas l'unité d'intégration, comme c'est le cas avec les branches de fonctionnalités et les pull requests. Maintenant, l'unité d'intégration était le commit. Et l'unité de release était un commit ou une série de commits. Parce que, eh bien, nous faisions encore, euh, nous décidions encore manuellement de livrer ou non. Euh, nous pratiquions donc la livraison continue et non le déploiement continu.
[00:20:08] Maintenant, afin de s'assurer que les revues aient lieu, nous avons introduit la colonne 'À réviser' pour suivre les revues. Ce qui signifie, eh bien, que cette fonctionnalité est prête, elle est terminée et elle est prête à être révisée. Maintenant, Dave Farley rapporte qu'il a vu cela auparavant dans d'autres équipes, mais cela n'a jamais vraiment fonctionné car c'était perçu comme une porte. Et, eh bien, les portes de processus introduisent des retards et toutes sortes de problèmes et de dysfonctionnements et réduisent la qualité. Mais dans notre cas, ce n'était pas, c'était différent. Ce n'était pas vécu comme une barrière. La fonctionnalité croissait, commit par commit, sur la branche principale, mais les revues portaient sur l'ensemble de la fonctionnalité sur la branche principale. Et donc, quand une fonctionnalité était terminée et prête à être révisée, eh bien, elle était déplacée dans la colonne 'À réviser'. Maintenant, pour éviter le changement de contexte, eh bien, nous avons décidé que quiconque terminait un travail avant d'en commencer un nouveau ou au début de la journée, eh bien, il regarderait d'abord la colonne 'À réviser' pour voir si quelque chose attendait d'être révisé, et si c'était le cas, eh bien, il le réviserait. Et donc cela garantissait que nous avions une revue continue en place, et donc nous avions une revue de code continue.
[00:21:29] Nous n'avions qu'une seule règle. Personne ne devrait réviser une fonctionnalité à la rédaction de laquelle il a participé. Mais il n'y avait pas de règles concernant les hiérarchies et qui peut réviser le code de qui. N'importe qui pouvait réviser le code de n'importe qui. Donc les seniors révisaient le code des seniors et des juniors, nous avions des juniors révisant le code des juniors et des seniors. Maintenant, je ne m'attendais pas à beaucoup de commentaires venant des juniors. J'espérais qu'ils apprendraient quelque chose en lisant le code d'ingénieurs plus expérimentés. Cependant, j'ai vu des revues de code assez intéressantes venant de juniors car ils posaient des questions différentes, ils posaient des questions plus externes. Plus des questions 'pourquoi', qui sont des déclencheurs nécessaires pour, euh,
[00:22:17] les les les pour les améliorations nécessaires. Donc, si nous ne pratiquons pas les pull requests ou si nous ne pratiquons pas la programmation en binôme ou le software teaming, eh bien, nous nous retrouvons avec du code non révisé dans la branche principale distante. Et donc nous avons à la fois du code révisé et du code non révisé côte à côte sur la branche principale. Et donc ce code est publiable. Et ce code n'est pas publiable en même temps. Comment les séparer ? Et que signifie réellement 'publiable' dans ce cas ? Et c'est la deuxième idée clé de ce processus de revue : eh bien, arrêter que la revue soit définitive pour la publication. Arrêter d'utiliser la revue de code pour décider si une base de code est publiable ou non. Donc, la revue de code n'est plus une barrière, ce n'est plus une décision d'aller ou non, elle ne bloque plus la livraison. Ainsi, l'équipe a pratiqué une véritable intégration continue avec un développement en espace, qui a ensuite évolué vers la livraison continue avec un pipeline de déploiement. Et chaque commit qui passait avec succès toutes les étapes du pipeline de déploiement et qui avait été minutieusement testé avait le potentiel d'arriver en production si nous décidions de le publier. Ainsi, le tableau Kanban et les revues se déroulaient au niveau de la fonctionnalité, mais le logiciel évoluait petit commit par petit commit sur la branche principale. Et tout commit qui passait par le pipeline pouvait arriver en production.
[00:23:47] Donc cela signifie que du code non révisé peut arriver en production, que la fonctionnalité soit terminée ou non, et que la fonctionnalité ait été révisée ou non. Maintenant, nous pouvons soutenir que, eh bien, nous courons le risque d'avoir du code de faible qualité en production. Oui, c'est vrai, et cela est arrivé de nombreuses fois.
[00:24:07] Mais ce n'était pas vraiment un problème car, eh bien, une mauvaise qualité ne signifie pas un bug, et les revues de code ne sont pas là pour attraper les bugs. Pour cela, nous avions des tests automatisés en place et des tests exploratoires manuels en place. Nous avions donc l'engagement de l'équipe que toute modification devait être couverte par un test automatisé, de préférence des tests unitaires. Nous avions des tests d'acceptation automatisés en place et, de plus, nous avons également appliqué ce que j'appelle les tests manuels par les pairs. Donc, nous n'avions pas d'ingénieurs dans l'équipe qui s'identifiaient comme ingénieurs de test, malheureusement, et cela arrive assez souvent avec les équipes avec lesquelles je travaille. Et donc la meilleure chose suivante que nous avons trouvée était, eh bien, le test par les pairs. Donc quelqu'un qui n'était pas impliqué dans l'implémentation de la fonctionnalité effectuait des tests exploratoires sur cette fonctionnalité. Et puis nous avions une quantité décente d'analyse de code statique qui cassait la construction en cas de violation de règle. Donc, le risque de travailler de cette manière n'est pas tant que le code soit plus buggé ou non, mais que nous pourrions livrer du code de moindre qualité en production. Mais la qualité du code n'a pas beaucoup d'impact sur la livraison du produit et encore moins sur la, euh, la fonctionnalité. Mais la qualité du code a un impact sur la vitesse de changement. Et c'est la raison pour laquelle nous voulons avoir une haute qualité de code. Parce que cela nous permet d'introduire des changements et d'ajouter de nouvelles fonctionnalités plus rapidement et plus facilement, ce qui réduit les délais et le temps de mise sur le marché. Au final, c'est du code qui fonctionne. Parce que le test le dit. Il a passé tous les tests. Mais cela pourrait être mieux. Mais, eh bien, d'une certaine manière, c'est toujours vrai. Les revues de code ne font que réduire les chances de livrer du code de faible qualité. Mais cela dépend de la qualité de la revue de code, mais cela n'élimine pas complètement la mauvaise qualité. Maintenant, cela a fonctionné parce que, alors que nous étions d'accord en équipe pour que chaque commit soit révisé à un moment donné. Et nous étions sûrs que cela allait arriver car nous avions cette colonne 'À réviser', et et et tant que la revue n'avait pas eu lieu, eh bien, la fonctionnalité n'était pas terminée, bien qu'elle puisse déjà être en production. Selon notre tableau Kanban, ce n'était pas fait. Et chaque fois qu'un problème était soulevé, donc un problème de qualité était soulevé, il devait être traité avec la plus haute priorité. Et cela aussi nous étions sûrs que cela arriverait parce que le ticket restait dans la colonne 'À réviser' tant que ces problèmes n'étaient pas résolus. Alors, quels sont les avantages ? Maintenant, pour comprendre les avantages, nous devons comprendre le coût de transaction de la fabrication Lean. Le coût de transaction est donc le coût de déplacement d'un lot de travail à l'étape suivante. Maintenant, c'est important car plus le coût de transaction est élevé, plus l'inventaire est créé devant l'étape suivante pour compenser le coût de transaction. Alors disons que nous voulons commander des marchandises en ligne, et le coût de transaction pour livrer les marchandises est de 3 euros.
[00:27:13] Alors, pour que les marchandises soient livrées, cela nous coûtera 3 euros. Eh bien, dans ce cas, nous n'allons pas commander une seule marchandise à 1 euro. Non, nous allons commander un ensemble de marchandises pour obtenir un coût total qui est un multiple du coût de transaction afin de pouvoir compenser le coût de transaction. Et donc nous allons créer un plus grand lot d'articles à livrer.
[00:27:38] Alors, s'il nous faut 10 minutes pour faire un changement et que le changement est bloqué jusqu'à ce qu'une révision ait lieu. Et il faut deux heures pour obtenir une révision, eh bien, cela signifie que le changement attend pendant 92% de son temps de cycle total. Maintenant, c'est un processus assez coûteux. Cela nous indique donc que la revue de code est assez coûteuse. Et dans ce cas, pour compenser le coût de transaction, eh bien, nous sommes incités à demander moins souvent des revues de code. Maintenant, que se passe-t-il si nous demandons moins souvent des revues de code ? Exactement, nous allons faire plus de changements. Et et et ajouter plus de changements dans un plus grand lot avant même de demander une revue de code. Ainsi, le processus nous décourage de travailler par petites étapes incrémentales et nous décourage d'adopter le refactoring. Et si nous ne refactorisons pas, eh bien, nous ne remboursons pas la dette technique. Et donc, si nous ne remboursons pas la dette technique, cela impacte la qualité de la base de code et donc cela impacte la vitesse de changement. Et donc cela introduit des retards et augmente le coût des retards.
[00:28:48] Donc, parce que nous attendons que quelqu'un termine un travail, parce que nous attendons une révision, eh bien, nous sommes également incités à créer plus de travail en cours. Les ingénieurs veulent donc se sentir productifs et il est assez inconfortable de simplement attendre et ne rien faire. Je vous invite à faire cela et ensuite à regarder les réactions de vos dirigeants.
[00:29:11] Alors, que se passe-t-il ?
[00:29:14] Eh bien, nous restons occupés et nous commençons de nouveaux travaux. Et voici le début de nombreux changements de contexte et nous savons où cela mène et ce n'est pas joli. Maintenant, à cause de la loi de Little, plus de travail en cours signifie des délais plus longs, des retards plus importants. Et donc nous nous retrouvons avec une livraison retardée, un feedback retardé. L'apprentissage ralentira, nous deviendrons averses au risque et l'innovation s'effondrera, et nous retournerons à des solutions conservatrices. Et nous voyons cela avec les organisations qui pratiquent les pull requests. Ils sont incapables d'adopter les pratiques d'ingénierie performantes qui permettraient de débloquer une myriade de possibilités, ils ne sont même pas conscients que cela serait possible. Et donc ils sont bloqués dans ce qu'ils connaissent et donc ils sont bloqués dans une vision en tunnel et ils retournent à les choses aux solutions conservatrices. Donc, pour sortir les choses plus tôt, eh bien, nous devons réduire le coût de transaction. Nous devons donc minimiser euh nous devons minimiser le coût des revues de code afin de réduire le travail en cours. Et à cause de la loi de Little, cela réduira les délais de production, réduira les retards et raccourcira notre temps de mise sur le marché et accélérera le feedback. Et par conséquent, cela conduira à une meilleure qualité. Alors, quels sont les avantages ? Deuxième fois. Eh bien, parce que le coût de transaction est presque nul, la revue de code n'a eu presque aucun impact sur le délai de livraison total. Les commits passaient déjà par le pipeline de déploiement et si cela se passait avec succès, il pouvait déjà être en production avant même le début de la revue de code. Et donc il n'y a aucune raison de faire plus de changements dans des lots plus importants avant de demander une révision. Et donc nous sommes incités à travailler par petites étapes incrémentales, et naturellement, le refactoring aura lieu. Ce qui améliorera la qualité du code et augmentera la vitesse de changement, et par conséquent, nous optimisons le temps d'ingénierie. Pour introduire des changements et ajouter de nouvelles fonctionnalités à la base de code, ce qui, encore une fois, réduit notre temps de mise sur le marché.
[00:31:31] Nous ne sommes donc plus jamais ralentis. Nous n'avons aucune barrière. Nous n'avons jamais à attendre que quelqu'un termine un travail. Les changements ne sont donc jamais bloqués. Et donc nous commitons et nous commitons et nous commitons, et chaque commit qui passe par le pipeline de déploiement arrive en production si nous décidons de le publier. Et c'est ce qui permet un feedback rapide et précoce, ce qui nous permet de prendre de nouvelles décisions et de réaliser de nouvelles expériences en production afin de trouver de nouvelles façons de ravir nos utilisateurs. Ainsi, le fait que du code non révisé puisse déjà être testé ou était déjà déployé en production avant même qu'une revue ne se produise était étonnamment un avantage significatif. Parce que nous avions déjà reçu des commentaires de l'utilisateur, nous pouvions voir comment l'utilisateur utilisait la fonctionnalité. Ou peut-être qu'il n'utilisait pas la fonctionnalité. Et dans ce cas, nous n'avons même pas eu besoin d'effectuer la revue de code. Eh bien, nous devrions retirer le code dans ce cas. Avec les pull requests, nous n'avons pas ce feedback. Tant que la revue n'a pas eu lieu, la fonctionnalité est toujours bloquée. Et nous n'avons aucun retour de production. Nous ne savons donc pas si la chose que nous avons implémentée est la bonne chose. Nous pourrions avoir complètement tort, mais nous ne le savons pas.
[00:32:47] Nous pouvons donc maintenant travailler sur une fonctionnalité du début à la fin. Et donc nous n'avons jamais à commencer un nouveau travail avant de terminer le travail en cours parce que nous voulons nous sentir productifs et nous attendons que quelqu'un continue. Donc cela n'arrivait plus. Et donc, en conséquence, les gens pouvaient se concentrer sur une chose à la fois et travailler sur la fonctionnalité du début à la fin. Et donc il n'y avait plus de changement de contexte, plus de multitâche, donc plus de tueurs de productivité. Et donc, parce que nous ne commençons pas de nouveau travail, eh bien, nous avons beaucoup moins de travail en cours. Et donc, grâce à la loi de Little, nous avons réduit les délais de production, les retards, le temps de mise sur le marché et accéléré le feedback. Ce qui nous permet de prendre plus de décisions et de réaliser plus d'expériences en production pour trouver plus de besoins non satisfaits de nos clients et, en conséquence, eh bien, gagner plus d'argent.
[00:33:48] Maintenant, parfois, il arrivait que nous remarquions que la conception était complètement erronée lors d'une revue de code. La conception était complètement à côté.
[00:33:57] Ce furent des moments où j'aurais aimé que nous pratiquions la programmation en binôme afin de détecter ces choses plus tôt.
[00:34:04] Mais encore une fois, ce n'était pas vraiment un gros problème car, eh bien, la fonctionnalité s'est avérée fonctionner. Il a passé tous les tests. Il a été livré en production, il était entre les mains des utilisateurs, les utilisateurs avaient déjà la valeur de la fonctionnalité. Nous avons déjà reçu des retours sur la pertinence de la fonctionnalité. Et donc nous avions tout le temps de refaire le design. Il n'y avait aucune pression de livraison car il était déjà livré. Et de plus, nous pouvions même intégrer les retours que nous recevions de la production afin de réaliser une meilleure refonte. Maintenant, avec les pull requests, nous avons deux options si nous constatons que le design est erroné. Soit nous imposons un correctif et pendant que ce correctif est mis en œuvre, la fonctionnalité n'est toujours pas livrée. Nous n'avons toujours pas de feedback de production, nous ne savons toujours pas si ce qui attend là est la bonne chose. Il se peut que nous investissions dans un correctif qui n'est pas nécessaire parce que ce n'est peut-être pas la bonne chose. Ou parce qu'il y a une pression de livraison, eh bien, nous décidons de couper les coins ronds et nous disons, oh, nous le réparerons plus tard. Et nous savons où cela mène. Et ici commence la dette technique et l'impact sur la vitesse de changement. Donc dans notre cas, pas de pression. Pas de stress, pas de fatigue, pas d'épuisement.
[00:35:29] Maintenant, parce que du code non révisé pourrait arriver en production, si le code passait avec succès le pipeline de déploiement, cela place beaucoup de confiance entre les mains de l'équipe, et donc nous attendons de l'équipe qu'elle fasse la bonne chose.
[00:35:46] Au lieu de penser qu'ils sont stupides et que nous avons besoin d'un processus pour y remédier. Donc maintenant, nous nous attendions à ce que l'équipe ajoute des tests automatisés, ajoute suffisamment de tests automatisés et qu'elle ajoute les bons tests automatisés et des tests automatisés de haute qualité. Ceci applique donc la théorie de la gestion, euh, la théorie de la gestion Y par rapport à la théorie de la gestion X. Et même quand quelque chose tournait mal en production, ce n'était pas vraiment un gros problème car nous avions un processus qui nous permettait de récupérer rapidement. La livraison continue, eh bien, nous a permis de livrer en quelques minutes. J'aime donc dire que je me fiche des bugs en production. Ils se produiront de toute façon, peu importe le nombre de tests que nous effectuons, à cause de toutes les inconnues que nous ne connaissons pas. Euh, oh, les utilisateurs l'utilisent de cette façon. Nous ne nous attendions pas à cela. Ce genre de choses.
[00:36:45] Il est donc plus important d'avoir un processus en place qui nous permette de récupérer rapidement, de résoudre ces problèmes rapidement.
[00:36:56] Maintenant, en toute honnêteté, il y a un piège.
[00:36:59] Avec les revues de code non bloquantes.
[00:37:02] Cela pourrait être difficile à implémenter dans les industries réglementées. De nombreuses industries réglementées exigent une étape de validation avant de déployer en production. Et cette étape est souvent implémentée en utilisant des revues de code. Donc, dans ce cas, cela pourrait être difficile. Cependant, je peux imaginer certaines façons d'implémenter une partie de ces revues de code non bloquantes. Mais je ne l'ai jamais testé. Donc je n'ai jamais travaillé dans le domaine de la santé, par exemple. Donc, je ne mentionnerai rien de cela. Donc je pourrais me tromper.
[00:37:35] Mais quand même, pour les industries réglementées, la programmation en binôme et le travail d'équipe logiciel sont une bien meilleure approche. Si nous faisons de la programmation en binôme, eh bien, la paire pourrait valider la revue de code au moment où elle commite le changement et taguer le changement avec les identifiants des deux ingénieurs impliqués dans la paire. Donc, en conclusion,
[00:38:01] Je pense toujours que la programmation en binôme et le travail d'équipe logiciel sont des options de livraison supérieures. Mais, dans de nombreuses organisations, c'est un défi culturel pour de nombreuses raisons valables. Euh, vous ne pouvez pas simplement changer une culture parce que, pendant que vous êtes le coach et que vous arrivez là. Vous devez être attentif. Les gens n'ont pas nécessairement signé pour cela et ils ne sont pas nécessairement ouverts à l'idée.
[00:38:32] Dans cette situation, les stratégies de revue non bloquantes sont significativement meilleures que n'importe quelle autre alternative parce que, eh bien, il n'y a pas de filtrage. Cela permet donc une livraison rapide sans retards. Euh, donc cela permet un flux de travail rapide à travers notre chaîne de valeur, ce qui est une pratique essentielle à adopter pour atteindre une meilleure qualité car cela accélère le feedback. Parce que nous n'attendons jamais, alors que nous n'avons pas besoin de commencer un nouveau travail juste pour nous sentir productifs. Nous avons donc beaucoup moins de travail en cours, et grâce à la loi de Little, nous réduisons les retards, les délais de production, le temps de mise sur le marché, et le coût des retards. Et naturellement, nous accélérons le feedback et nous atteignons une meilleure qualité.
[00:39:19] Euh, parce que nous pouvons terminer un travail du début à la fin en une seule fois, eh bien, nous n'avons plus de changement de contexte, il n'y a plus de multitâche, plus de tueur de productivité. le flux rapide de travail à travers notre chaîne de valeur, ce qui est une pratique essentielle à adopter pour obtenir une meilleure qualité car cela accélère le feedback. Parce que nous n'attendons jamais pendant que nous n'avons pas besoin de commencer un nouveau travail juste pour nous sentir productifs. Nous avons donc beaucoup moins de travail en cours et grâce à la loi de Little, nous réduisons les retards, nous réduisons les délais, nous réduisons le temps de mise sur le marché, nous réduisons le coût des retards. Et naturellement, pendant que nous accélérons les retours, nous obtenons une meilleure qualité.
[00:39:19] Hum, parce que nous pouvons terminer le travail du début à la fin en une seule fois, alors que nous n'avons plus de changement de contexte, il n'y a plus de multitâche, plus de tueur de productivité.
[00:39:35] Il n'y a aucune urgence à corriger les problèmes de qualité lorsqu'ils sont découverts. Nous avons tout le temps parce que, eh bien, la fonctionnalité a été trouvée fonctionnelle, les tests automatisés l'ont dit. Hum, c'est, c'est livré en production, c'est entre les mains des utilisateurs. Hum, donc, eh bien, nous avons tout le temps pour le corriger, donc pas de pression, pas de stress, pas de fatigue, pas d'épuisement professionnel.
[00:39:56] Naturellement, cela nous permet de faire évoluer le logiciel de manière incrémentielle, petit commit par petit commit, et, le refactoring se produit naturellement. nous permettant d'obtenir de meilleures qualités de code et d'accélérer le changement. Merci pour votre temps.
[00:40:24] Des questions?
[00:40:34] Bonjour.
[00:40:35] Bonjour. Je te laisserai traduire.
[00:40:38] J'ai plusieurs questions. C'est bien.
[00:40:41] Ouais.
[00:40:42] L'usage des feature flags dans votre contexte. À quel, est-ce que vous en, enfin est-ce que c'est rendu nécessaire, est-ce que c'est utile? Enfin, j'aimerais savoir comment vous les utilisez.
[00:40:52] Pendant longtemps, Donc, la question était,
[00:40:57] Qu'en est-il des feature flags? que nous l'utilisons, était-ce utile?
[00:41:02] Hum, eh bien, pendant longtemps, nous n'avons pas utilisé de feature flags, euh, et puis à un certain moment, nous avons commencé à utiliser des feature flags et oui, c'était utile.
[00:41:12] Euh, pour parce que, eh bien, nous devions activer des fonctionnalités à un certain moment ou quelque chose d'autre, euh, devait être déployé avant que nous puissions activer la fonctionnalité, enfin, ce genre de choses. Donc, pour découpler les déploiements de différentes applications afin que nous n'ayons pas un déploiement coordonné.
[00:41:33] And so, my question was more about, well, thank you for this answer. Regarding the test part, where the product team would want to test, so, do you have a staging environment, was it the same, how do you deploy if you have one and where do we test?
[00:41:48] D'accord, donc, la question concerne, oui, hum, que nous l'utilisons pour les tests, et si nous l'avons utilisé pour faciliter les équipes produit à tester l'application. Maintenant, je dois, je dois admettre, c'est loin, donc je ne me souviens plus de tout. Hum, j'ai un vague souvenir que nous l'avons fait, euh, comme activer une fonctionnalité dans l'environnement de test. Mais cela n'était pas activé dans l'environnement de production, de sorte que, euh, euh, les équipes produit puissent, puissent voir l'effet.
[00:42:23] Thank you.
[00:42:28] ici.
[00:42:29] Euh, merci, ici. Euh, votre explication était très claire, euh, à la fois sur les, euh, impacts et la logique et les principes derrière votre pratique. Euh, avez-vous une mesure de n'importe quel type d'efficacité, que ce soit le délai de commercialisation avant, après, euh, le délai d'exécution, la qualité en quoi que ce soit?
[00:42:51] Oh, c'est, c'est une mesure plus subjective, c'est une observation. Donc, quand nous sommes arrivés, donc mon, mon, mon, mon, eh bien, collègue coach, maintenant ami, euh, Martin et moi, quand nous sommes arrivés, hum, l'équipe était vraiment en mode opérationnel, comme s'assurer que les choses ne cassaient pas. Donc, je pense que 80% de leur temps était consacré aux opérations et 20% aux fonctionnalités. Et nous avons juste inversé cela, comme 80% euh, de création de valeur et seulement 20% d'opérations. Parce que, eh bien, il y avait beaucoup d'automatisation, mais aussi beaucoup de tests automatisés. Et, et nous étions plutôt sûrs que lorsque quelque chose était mis en production, ça, ça, ça, ça, ça allait bien se passer.
[00:43:38] Et, euh, une courte, peut-être deuxième question. Euh, vous avez mentionné, euh, les tests automatisés et les tests unitaires. Pensez-vous qu'ils sont un prérequis pour que cette pratique fonctionne ou était-ce le cas dans votre expérience?
[00:43:53] Alors, nous avons eu de la chance parce que nous avions un manager fou qui a dit dès le début, nous allons faire du greenfield. Tout ce qui existe, hum, va être remplacé. Donc, cela nous a permis de développer le logiciel avec des tests automatisés dès le début.
[00:44:15] Est-ce nécessaire? Eh bien, ça aide, bien sûr.
[00:44:19] Je pense que cela dépend de votre, hum, appétit pour le risque en tant qu'équipe.
[00:44:25] Hum, parce que, eh bien, dire, oui, nous devons avoir un certain niveau de test avant d'adopter le développement basé sur le tronc, oui, eh bien, bien sûr, vous pouvez le faire, mais quand aurez-vous le bon niveau de test et ferez-vous le changement? Hum, je suis, je suis un peu, hum, hum, effrayé que parce que vous avez des branches de fonctionnalité et des pull requests derrière lesquelles vous pouvez vous cacher et, et continuer à faire les mauvaises pratiques. Donc, si j'étais un, un, un leader, je dirais juste, oui, eh bien, peu importe, nous faisons du développement basé sur le tronc et nous corrigerons les choses au fur et à mesure.
[00:45:01] Mais cela met pas mal de pression sur l'équipe, donc cela nécessite un certain état d'esprit.
[00:45:08] Merci.
[00:45:10] Thanks for the talk. I have a small question, from a practical point of view, how did you manage, well, in terms of tools and in terms of how to choose what to review, by whom? Is it the person who writes the code who asks certain other people to review it, or is it people who read the trunk little by little?
[00:45:33] Donc, la question porte sur, eh bien, les outils et comment nous organisions les revues de code, comme est-ce que la personne qui a implémenté la fonctionnalité demandait spécifiquement une revue ou est-ce que les gens lisaient simplement le code sur le tronc? et parcourant les commits. Donc, oui.
[00:45:51] La toute première version de ce, de ce diaporama contenait également des diapositives sur les outils. Hum, donc à l'époque, il y avait des outils en place pour faire cela. La plupart ont été abandonnés par les fournisseurs d'outils au profit des pull requests. Donc à l'époque, Atlassian avait, euh, euh, Jira avec, euh, quelque chose avec un C. J'ai oublié le nom. Hum, qui permettait de, hum, donc ça se connecte sur le système de contrôle de version, collecte tous les commits et ensuite vous pouvez commencer à filtrer les commits basés sur des mots-clés. Et donc nous utilisions des numéros de ticket. Donc le numéro de ticket de la fonctionnalité et ensuite nous avons regroupé tous les commits, ce sont les commits pour la fonctionnalité, voici la revue de code. Hum, Jet Brains avait aussi un, un outil comme ça, il s'appelait Upsource. Et puis nous avions, euh, Facebook qui avait Fabricator, je suppose, euh, mais ils ont aussi abandonné ça. Hum, donc oui, hum, de nos jours, il y a une entreprise, Axion it, qui pratique le développement basé sur le tronc depuis 10 ans, confrontée au même problème, nous voulons faire des revues de code, il n'y a pas d'outils. Alors ils, ils, ils ont implémenté leur propre outil de révision de code, il s'appelle X-Reme, et il est disponible sur GitHub, je ne l'ai jamais utilisé, donc je ne peux pas dire s'il est bon ou non. Hum, donc c'est, c'est pour l'outillage.
[00:47:24] Hum, nous, nous n'avons jamais explicitement demandé de revues de code. C'était vraiment genre, la fonctionnalité est terminée, déplacée dans la colonne à revoir et ensuite quelqu'un la prendra, la première personne disponible qui a fini le travail la prendrait. Hum, et donc nous évitons d'avoir, oui, à solliciter les gens, genre, oh, s'il vous plaît, s'il vous plaît, pouvez-vous revoir quelque chose que je vois dans, dans les organisations où sur Slack, ils sont genre, oh oui, oui, pouvez-vous rapidement revoir cette pull request car elle bloque un correctif pour la production, par exemple? C'est fou. Donc, alors que le fait de harceler ne rendra pas vos équipes plus rapides, le problème est le travail en cours.
[00:48:06] Il y avait une question ici, devant.
[00:48:17] Bonjour, Jory.
[00:48:21] Tout d'abord, je voudrais vous remercier pour cette présentation. Je l'ai trouvée très perspicace. C'est la présentation dont j'ai le plus appris aujourd'hui.
[00:48:29] Merci.
[00:48:31] Et, euh, ma question concerne l'utilisation, euh, des grands modèles linguistiques dans la revue de code. J'ai eu l'occasion de travailler sur une solution qui peut, qui réalise des audits de code sur des dépôts GitHub.
[00:48:46] Donc, il, il utilise un LLM pour revoir le non-respect, par exemple, des bonnes pratiques de codage, les fuites de données, la sécurité, euh, les problèmes de sécurité, euh. Alors, comment voyez-vous l'utilisation des LLM dans la revue de code et cela pourrait-il, par exemple, résoudre certains problèmes, certains des défauts de la revue de code humaine?
[00:49:08] Oui, donc, hum,
[00:49:11] Je suis, je suis un peu sceptique.
[00:49:14] surtout connaissant les développements récents dans les LLM, surtout dans les LLM de génération de code comme
[00:49:22] Oui, donc je suis un peu sceptique. Donc je suis, je suis assez impressionné par la façon dont le co-pilote complète le code dans mon éditeur et j'en suis vraiment reconnaissant. Mais encore une fois, je connais la programmation et je sais à quoi ressemble un bon et un mauvais code, donc je peux prendre une décision, euh, consciente, euh, à propos de nous.
[00:49:48] Je ne suis pas sûr que nous puissions simplement confier les revues aux machines. Parce qu'il y a aussi, je, je, enfin, il y a aussi beaucoup de contexte qu'ils, qu'ils manquent, hum, pour faire une revue de code appropriée, euh, je suppose. Mais, eh bien, appelez ça être de la vieille école, probablement, je ne suis pas particulièrement jeune. Donc, il se peut que ça fonctionne. Nous verrons ce que l'avenir nous réservera, mais je suis un peu sceptique quant à tout le battage médiatique autour des LLM, c'est tout. Et je ne suis pas le seul à être sceptique, donc.
[00:50:30] Merci.
[00:50:31] Merci.
[00:50:34] Oui, je, oh.
[00:50:37] I have a question, but it's perhaps more about trunk-based development. Uh, how do you— I may not have understood correctly. You had a feature one to three, feature three four five, uh, and you decide at some point to go to production. How do you do with feature three four five which is not finished?
[00:50:59] Alors, la question porte sur le développement basé sur le tronc parce qu'il y a une diapositive qui montre plusieurs commits. avec différents identifiants de fonctionnalités et ils sont comme mélangés entre eux, ce qui s'est réellement produit, donc nous avions plusieurs personnes travaillant sur des fonctionnalités et donc nous avions des commits qui arrivaient pour différentes fonctionnalités. Et donc la question est, oui, mais que se passe-t-il lorsque vous décidez de livrer et, et la fonctionnalité un, donc vous voulez livrer la fonctionnalité un, deux, trois, mais la quatre, cinq, six n'est pas terminée.
[00:51:28] Eh bien, oui, nous avons livré et nous nous sommes assurés que ça ne cassait pas. C'est, c'est, hum, c'est, oui, c'est, c'est une idée que les gens ont, oui, vous ne pouvez livrer que des fonctionnalités terminées, ce n'est pas vrai. Il est acceptable d'avoir des fonctionnalités inachevées en production, euh, même derrière des URL accessibles au public, il suffit de s'assurer de masquer la fonctionnalité afin que les utilisateurs ne la découvrent pas et qu'elle ne crée aucun impact, comme des bogues ou certaines choses. Mais cela nécessite des tests pour s'assurer que cela n'arrive pas. D'accord.
[00:52:11] Bonjour. Euh, je veux dire, je voulais parler, vous savez, de la qualité du code de conception et de l'absence de pression pour finaliser la qualité avant de livrer aux utilisateurs.
[00:52:18] Euh, pas de pression pour finir la qualité avant de l'envoyer aux utilisateurs. Je vois donc comment cela pourrait être un avantage de mettre la fonctionnalité à la disposition des utilisateurs le plus rapidement possible. Euh, mais alors je peux voir des cas où nous ne revenons jamais en arrière même après la révision, ne revenons jamais en arrière pour corriger la qualité interne du code parce que nous avons d'autres fonctionnalités à livrer et nous voulons qu'elles soient devant les utilisateurs aussi vite que possible également. Alors, comment, la question est, hum, comment allons-nous transformer l'absence de pression pour corriger la qualité avant de la livrer en une certaine pression pour réellement aborder le problème de qualité du code?
[00:52:55] Ah oui, mais, mais le, Le fait est que nous n'avions pas besoin de ne pas avoir de pression. Oui, donc le fait est que nous n'avions pas à corriger la qualité du code avant de le livrer. Nous pouvions livrer.
[00:53:06] Et nous savions que la correction viendrait plus tard, parce que, eh bien, nous, nous suivions que la correction était, était, était en cours. La fonctionnalité n'était pas terminée selon nous, bien qu'elle soit déjà en production et livrée, mais selon notre, notre outil de suivi, notre tableau Kanban, la fonctionnalité n'était pas terminée, donc cela allait se produire. Maintenant, d'un autre côté, eh bien, parfois il est aussi acceptable d'avoir un code de qualité un peu inférieure parce que d'autres choses sont plus importantes à se produire. Ce que j'ai, ce que j'ai commencé à faire, c'est juste ajouter des commentaires, comme oui, cette chose doit être améliorée un jour, et puis un jour nous revenons parce que quelque chose doit être changé dans ce domaine et nous le faisons simplement.
[00:53:55] Et donc vous avez aussi une amélioration naturelle, naturelle. Donc, euh, j'ai un ami qui, qui dit, oui, nous, je fais du refactoring pour préparer le code à ajouter la nouvelle fonctionnalité. C'est donc une chose nécessaire qui doit se produire dans le cadre du développement.
[00:54:16] Merci. De rien.
[00:54:21] D'accord, nous n'avons le temps que pour une dernière question.
[00:54:25] Merci. J'ai, j'ai vraiment apprécié l'approche, euh, stimulante et l'idée stimulante. Surtout pour, euh, les gens qui vivent dans des industries où il y a une énorme préoccupation pour la qualité d'avoir le sentiment de contrôle sur la qualité. ce qui pourrait être deux choses différentes. Hum, je ne suis pas sûr si c'est une question ou plus une réaction et c'est tout à fait, euh, lié à la question précédente. Là où quand vous avez un produit qui semble être plus ou moins disponible pour l'utilisateur, plus ou moins fini, euh, vous pouvez avoir des situations où vous avez un product owner qui a l'impression de dire, bon, passons à la suite, la revue de code, on n'a pas vraiment besoin de se concentrer là-dessus. C'est bon, ça marche. Passons au suivant, vous savez. Et j'avais l'impression que cela pourrait être très utile dans une telle situation de considérer le travail comme terminé non pas lorsqu'il est réellement disponible pour les utilisateurs, mais après avoir eu un certain temps pour mesurer réellement l'impact de la valeur dont vous pourriez bénéficier de votre, euh, livrable.
[00:55:32] Eh bien,
[00:55:34] Nous avons eu de la chance car le product owner était en fait l'équipe. Donc, nous avons géré le produit parce que nous, donc nous avions quelques ingénieurs. qui venaient des départements pour lesquels nous développions le logiciel et donc ils comprenaient très bien ce dont ils avaient besoin. Hum, donc c'était une chose.
[00:55:59] Hum, et nous, nous avons mis, enfin, nous, nous pensions que la qualité était vraiment importante et donc, eh bien, cette situation ne s'est jamais produite. Encore une fois, parce que selon nous, cela faisait partie de la définition de la tâche terminée, comme, c'est en production, d'accord, mais ce n'est pas fini. Il y a encore du travail à faire et nous devons le terminer avant de commencer un nouveau travail.
[00:56:27] Merci.
[00:56:29] Merci Thierry pour votre session perspicace. Merci. Et nous aimons maintenant une pause.

Transcription (Traduit)