Il était une fois, dans une petite start-up en plein essor, un jeune développeur nommé Léo. Lors de son premier jour, on lui présenta son compagnon : un petit bout de code, tout mignon, tout simple, destiné à être le cœur de leur nouvelle application. Léo était ravi. Il le nourrissait régulièrement de nouvelles fonctionnalités, et le code grandissait, s’épanouissait.
Continuer la lecture de « Code Legacy : Le mignon compagnon devenu monstre »Si tu es là, c’est que tu as peut-être déjà croisé ce fameux « code mort » qui traîne dans les recoins sombres de ton projet. Et si tu n’as pas encore osé le supprimer, tu n’es pas seul. Beaucoup d’entre nous hésitent, par peur de casser quelque chose. Mais laisse-moi te dire : un bon nettoyage n’a jamais fait de mal à personne ! Alors, comment repérer ce code inutile ? C’est parti !
Salut à toi, jeune padawan du code ! Si tu es ici, c’est que tu as entendu parler du refactoring de code et que tu veux te lancer.
Bravo ! Tu es sur la bonne voie.
Le refactoring, c’est un peu comme apprendre à entretenir ton vélo pour qu’il roule toujours bien. Alors, enfile tes gants de mécano, et plongeons ensemble dans ce guide pratique.
Continuer la lecture de « Refactoring de code : le guide pour bien débuter »5 signes qui indiquent qu’il est temps d’un bon refactoring de code
Si tu es là, c’est que tu te poses des questions sur ton code. Est-il temps d’un bon refactoring de code ? Est-ce que ces petites alertes dans ta tête sont justifiées ? Eh bien, je suis là pour t’aider à y voir plus clair. Voici cinq signaux qui te disent que ton code te supplie d’être revu et corrigé.
Continuer la lecture de « 5 signaux pour un refactoring de code »Tu aimerais embarquer ton équipe dans le software craftsmanship, mais tu sens des réticences ? Cette mini série est faite pour toi.
Je m’inspire du livre de Chris Voss, Ne coupez jamais la poire en deux, pour te proposer des exercices concrets afin d’influencer ton équipe.
Et si tu veux aller plus loin, rejoins moi dans TCaftLab, c’est gratuit : https://systeme.artisandeveloppeur.fr/tcraftlab
Suite aux attaques en règle de Kevin et le drama qui s’en est suivi, j’ai beaucoup réfléchi car j’entendais une petite musique qui me gênait.
Dans mon enthousiasme, et même une forme de ferveur, de défendre une cause noble à mes yeux, le bonheur des développeurs, j’ai eu l’impression de franchir une ligne rouge.
Alors je me suis remis en question.
C’est une bonne question. Intéressant de voir comment les choses dérapent, un peu au début, beaucoup ensuite !
Tout commence avec un post un brin provocateur de Kevin sur linkedin :
https://www.linkedin.com/feed/update/urn:li:activity:6943520332855054336/
Aujourd’hui, j’ai du écrire un code affreux. 😭
Alors j’ai besoin d’écrire cet article pour m’excuser.
Non en fait j’assume. Et je pense que c’est important de t’expliquer ce qui s’est passé.
Continuer la lecture de « Software craftsmanship : une question de compromis »Cet article est rédigé en paire avec Hadrien. On s’est dit que c’était bien d’illustrer le concept par la pratique !
Photo de Tudor Baciu sur Unsplash
Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.
En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.
Tu trouveras ici un article assez complet sur le pair-programming dans lequel tu verras comment le pratiquer et le mettre en oeuvre. Si tu n’est pas au clair avec cette pratique, je te conseille de commencer par là !
“Un mob, c’est réunir toutes les personnes qui sont nécessaires au succès d’une tâche autour d’un seul poste de travail.”
Piqué par Hadrien à Woody Zuill
Bon, dit comme ça, c’est abstrait, mais concrètement, ça donne quoi ?
Si tu as connu les tasks forces, ça y ressemble !
Tu sais, le moment où c’est la m$#§e sur le projet, que la deadline arrive et qu’on met tout le monde dans une ‘war room’ pour sauver le monde (et le projet).
Ben c’est la même chose, mais avant que ce soit le bordel.
Concrètement, tu mets les développeurs du projet, et tous ceux qui sont utiles dans une même salle, en même temps, devant un seul écran.
La différence avec le pair-programming: ben c’est juste le nombre.
Au lieu d’être 2, tu peux être 3, 4, 5 ou plus si affinité.
Bon en vrai, au-delà de 6, ça va être compliqué à tenir dans le temps. Si tu as besoin de plus d’une pizza (format américain) pour nourrir ton équipe c’est qu’il est temps de la diviser.
Et finalement cette toute petite différence, tel un battement d’aile de papillon, engendre de grandes différences.
C’est ce qu’on va voir maintenant.
Continuer la lecture de « Pair Programming VS Mob Programming »Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.
En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.
Photo de Alvaro Reyes sur Unsplash
Cet article est encore en cours de rédaction. Si tu as des suggestions sur ce qui manque, te semble erroné ou si tu te poses encore des questions après avoir lu l’article, tu peux me contacter ici : https://www.linkedin.com/in/benoitgantaume/
Quelle drôle d’idée après tout : mettre deux personnes au travail sur une tâche, alors qu’une seule pourrait suffire.
Pourquoi diable y mettre autant d’énergie ?
Si on reste dans une logique productiviste fordienne, cela ne fait aucun sens.
Mais si on prend conscience qu’on est sur une activité complexe, développer un logiciel, qui nécessite des interactions hautement complexes, des humains qui bossent ensemble, on se rend compte que ce n’est pas si stupide.
Deux paires de bras qui travaillent ensemble vont apporter un gain linéaire : 1 + 1 = 2.
Hors, développer demande d’utiliser principalement son cerveau. Et quand deux cerveaux réfléchissent ensemble, le gain n’est plus linéaire.
Parfois 1 + 1 = 11.
Par moments 1 + 1 = 0.
Donc la première raison de travailler en pair programming est que les solutions apportées vont être beaucoup plus riches et le code de bien meilleure qualité.
La deuxième raison est de faire circuler la connaissance.
N’as-tu jamais été stressé à l’idée de partir, toi ou un collègue en vacances ?
Si tu veux pouvoir partir tranquille, il vaut mieux éviter d’être le seul détenteur d’une connaissance. Ça tombe bien, le pair programming est un formidable circulateur de connaissance.
Enfin, d’un point de vue humain, cela permet d’aller à la rencontre de ses collègues d’une manière plus profonde. Mais ce point peut être à double tranchant. On en parle plus bas.
Dans le pair programming des origines, les ordinateurs étaient encombrants, onéreux, et les outils de communication peu répandus. Donc on bossait à deux, l’un à côté de l’autre, sur le même ordinateur. Il n’y avait qu’un clavier/souris et une seule personne touchait le clavier pendant que l’autre réfléchissait avec lui.
Aujourd’hui, les ordinateurs portables sont répandus et les outils de communication beaucoup plus développés grâce aux connexions fibrées.
On peut donc élaborer d’autres manières de binômer.
Continuer la lecture de « Pair programming : le guide ultime »