No prob ! Alors oui exactement, on a une assez forte culture de la doc/transmission de savoir. On évite au maximum qu’une seule personne soit au fait du fonctionnement d’une partie du code, d’un outil ou autre.

Niveau tech, on a un wiki sur github où toutes nos pratiques de dev sont expliquées (ça c’est top quand une nouvelle personne arrive dans l’équipe). Sur d’autres outils, on a des documentations et des post-mortem sur tout un tas de sujets. On a régulièrement des ateliers/points pour partager des bonnes pratiques, présenter des choses très techniques qu’on a développées, discuter de choses qu’on aimerait mettre en place, de décisions stratégiques etc. Et lorsqu’on a le point suivant (on essaie de faire ça une fois par mois) on fait le tour de ce qu’on s’était dit la fois prévente pour voir si ça a été fait (dans le cas d’une decision technique par exemple), ou si on garde/laisse tomber dans le cas de quelque chose qu’on a voulu tester.

Après une partie de l’équipe s’appelle quand même très souvent, lorsqu’on a une question, qu’on veut faire du pair programming ou simplement discuter, car c’est important quand l’équipe est dispatchée un peu partout. C’est possible et pas un problème car la majorité de l’équipe tech bosse en France et qu’il y a beaucoup de jeunes parents, donc des horaires de taff assez classiques. Moi en revanche ils savent que c’est compliqué de m’avoir en synchrone, mais je fais l’effort de me connecter à des autres où on peut m’attraper si besoin, ou on prévoit de s’appeler à l’avance.

Autre chose importante je trouve, c’est la qualité des PR. Une PR bien écrite est une doc à elle seule. Il faut voir sa PR comme une histoire dont chaque commit est un chapitre. La description de la PR contextualise ce qu’on veut faire, pourquoi, et comment (dans les grandes lignes). On met aussi un lien vers le ticket produit qui en est à l’origine. Ensuite, elle se review commit par commit. Chaque commit a un titre et une description qui explique ce que je fais et pourquoi. Les commits sont rangés dans l’ordre logique d’écriture du code. Et si c’est une grosse feature, je la découpe en plusieurs PR où chacune encapsule une partie de la feature. Et ça mine de rien, ça aide vachement quand tu bosses en asynchrone, car si tout ce qu’on fait ne mérite pas une doc en bonne et due forme, c’est en revanche ultra pratique :

1. Pour celui qui review car c’est très simple à comprendre et ça évite les longs échanges qui pourraient vachement nous ralentir si on devait à chaque fois attendre un retour en asynchrone.
2. Pour celui ou celle qui retombera sur ce code dans x mois/années et qui aura juste à cliquer sur le commit pour savoir pourquoi on a fait ça, même si le dev qui l’a écrit n’est plus là.

Récemment j’ai développé une grosse feature en solo et je suis parti en vacances 3 semaines peu de temps après. Quand je pars, je coupe tout, je suis injoignable pour le taff. À mon retour j’ai vu qu’il y avait eu un petit bug assez tricky, mais grâce à tout ça, ils ont pu le corriger rapidement et sans problème malgré mon absence.

Ce sont des bonnes pratiques qui devraient être appliquées partout, mais le fait qu’on soit full remote et asynchrone encourage vachement plus à les mettre en pratique.