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 »Le software craftsmanship, ou craft, est devenu tendance. Mais qu’est-ce qui se cache derrière ce concept ?
On peut définir l’artisanat logiciel, le software craftsmanship, comme un mouvement porté par des développeurs passionnés par leur métier.
On peut le décrire selon ses valeurs, son état d’esprit ou encore ses pratiques.
Difficile de parler de software craftsmanship sans parler d’agilité tellement les deux sont liés à leur origine, même si les choses ont bien évolué depuis.
On parlera aussi dans cet article de la relation des pratiquants avec les reste du monde et aussi comment s’y former.
C’est aujourd’hui le 18 Mai mon freedom day de freelance.
Qu’est-ce que le freedom day ?
C’est le jour de l’année où je n’ai plus besoin de travailler pour assurer le minimum vital de ma rémunération.
C’est le jour où je suis libre de décliner une affaire que je sens pas, sans me demander si je vais pouvoir mettre de la nourriture sur la table pour les prochains mois, sans me demander si je ne vais pas le regretter dans quelques semaines.
En tant qu’agence, notre freedom day, c’était plutôt vers le 18 Novembre : on faisait notre résultat sur les dernières semaines.
Maintenant que je suis freelance, j’ai raccourci cette date.
Et c’est devenu un objectif pour moi : amener cette date le plus tôt dans l’année.
A partir de ce jour, je peux passer beaucoup plus de temps à me former, renforcer mon expertise, passer du temps sur des projets persos et ainsi développer les outils qui me permettront de raccourcir cette date l’année prochaine.
Tu la sens la boucle vertueuse ?
Mieux je choisis mes clients sur les critères qui me conviennent, et plus je fais avancer mon projet.
Plus je me forme, et plus je peux être pointu et valoriser mon expertise.
Plus j’investis de mon énergie sur des produits et mieux je pourrai faire grandir mon activité sans travailler plus, voire même moins.
Pour y arriver, ça commence souvent par sortir de la logique de régie à temps plein.
D’ailleurs, si tu veux connaître les mécaniques qui te permettent toi aussi d’y arriver, viens voir la conf que j’ai donnée sur youtube à ce sujet.
Cette notion de freedom day, je l’ai empruntée à Pierre Ammeloot, un des experts qui intervient dans le cercle. Concrètement, avec les logiques d’engagement et de facturations d’acompte, j’ai simplifié le calcul en disant que c’est le jour où le facturé dépasse le point d’équilibre de ma structure. C’est -à -dire que je couvre mes frais prévus : mon salaire, mais aussi les factures des partenaires avec qui je travaille.
Remarque bien que j’ai choisi d’investir une partie de ce temps libre, mais c’est à toi de voir.
Certains vont préférer dédier ce temps à leur famille.
D’autres voyager.
D’autres encore faire du pro-bono.
C’est ce que j’aime avec le freelancing : tu as le choix de ton mode de vie.
Ce n’est pas facile.
Certains moments sont franchement désagréables.
Mais tu as le choix de définir tes propres règles du jeu.
Envie de bosser dur : just do it.
Envie de lever le pied : vas-y si tu peux te le permettre.
Et toi, c’est quand ton freedom day ?
Si tu as envie de rejoindre un groupe de développeurs freelance qui ont envie d’aller plus loin, viens jeter un oeil au cercle.
Benoit Gantaume
Artisan Développeur
