Ainsi, vous avez fait le choix de Git, vous avez évité toutes les erreurs initiales dans l’utilisation de Git, et vous voilà en train d’appliquer les bonnes pratiques initiales dans l’utilisation de Git. Bravo ! On s’arrête là ?
Git, une bonne première base
Nous l’avons vu Git est une bonne première base pour travailler ensemble.
Il permet de créer un historique, une histoire du travail réalisé dans le projet que vous développez.
A travers les univers parallèles, ces carrefours de travail, il va permettre aussi :
- d’éviter de publier en production du code non voulu
- de ne pas aller polluer le travail de ses collègues lors de partage (fusion, pull / merge request) de code
C’est comme les fondations d’une maison : en mettant déjà ça en place, on s’assure d’une bonne base, pour assurer la pérennité du projet par la suite.
Aller plus loin dans la cohésion technique
Après cette fondation, nous allons chercher aussi à construire une cohésion technique à travers d’autres moyens, essentiels eux aussi. Ils vont être chacun à leur tour, une pierre dans l’édifice du projet de cohésion que nous souhaitons mettre en place.
Une bonne communication
Reprenons notre image de la maison à construire. OK, je ne suis pas un maçon, ni un architecte de maison, … Cependant le parallèle est bien présent 
Sans bonne communication entre les différents métiers pour construire une maison, comment s’accorder pour s’appuyer sur la fondation que l’on a construite ?
En développement logiciel, ce sont les mêmes principes : réussir à bien communiquer est essentiel. Et c’est tout un art qui s’apprend, qui se construit avec le temps.
Cette communication va permettre de renforcer la cohésion technique, tout comme la cohésion humaine (sujet dont nous parlerons dans un prochain cycle d’articles) :
- A travers les Pull / Merge requests : vous allez pouvoir proposer, partager vos idées, les patterns choisis, et donc apporter critique, amélioration, et donc communication
- Via les revues de code : vous allez pouvoir apprendre, mieux communiquer ensemble
- En utilisant liveshare : avant même la PR/MR, vous allez pouvoir partager du code, et apprendre à communiquer ensemble
Mettre en place une écriture commune
Pour bien communiquer techniquement, il est important d’avoir une même écriture. Sans aller jusqu’à écrire le même code partout (ce qu’il ne faut surtout pas faire selon moi : le développement c’est un art créatif, chacun a sa façon de développer), il est nécessaire / essentiel d’avoir un cadre technique commun.
Cela va passer par :
- La mise en place de règles d’écriture communes, à travers par exemple des linter (jslint, tslint, editorconfig, …),
- L’utilisation d’une architecture du projet permettant le cadre de développement
- La mise en place d’automatisations de génération de code commun (à travers une CLI (commande line interface), des schematics, …)
- L’ajout de scripts automatisés pour cadrer le code, la vérification, les commits, … (via npm scripts, des batches exécutés via maven, csproj, msbuild, …)
Un socle technique commun
OK tout ça fonctionne bien si l’équipe a un socle technique identique. Comment alors faire quand les équipes sont hétérogènes ? Ne doit -on travailler qu’avec des séniors qui ont un CV plus long que la distance Terre-Lune ?
Se former
Nous allons pouvoir acquérir un socle technique technique commun en se formant.
Oui, en se formant. Et pas uniquement à travers des formations officielles (financées ou non).
Il existe tout un panel de possibilités de formation, faisant émerger une culture de la formation :
- Des formations de 2 à 5 jours, ou plus (les fameuses officielles)
- Des formations en ligne, en mode e-learning
- Grâce à vos collègues : en échange informel
- Via stackoverflow (quand le code ne sert pas qu’à faire un vulgaire copier-coller)
- A travers une veille continue,
- …
Une culture de l’apprentissage
Ainsi, pour améliorer la cohésion technique, l’apprentissage est essentiel. Non pas cet apprentissage frénétique où l’on change tout le socle technique dès que l’on découvre une nouveauté : un apprentissage cadré, organisé, et progressif.
Cette culture d’apprentissage peut aussi être crystalliser à travers la mise en place d’un système de mentoring. (nous en reparlons dans un prochain article)
L’intégration et l’apprentissage continue
Lorsque l’on souhaite créer une cohésion technique, la recherche de l’automatisation va aider à se focaliser sur l’essentiel de ce que l’on doit réaliser, suivant son métier (développement, graphisme, tests, ux design, …).
Et quand on pousse l’automatisation assez loin, nous allons arriver à la mise en place d’un socle appelé : intégration / livraison continue, cher à la culture DevOps.
Qu’apprend-on à travers l’intégration continue ?
Intégration continue de son travail
Nous allons chercher à incorposer notre travail continuellement dans un cadre qui va construire petit à petit le logiciel, l’application que l’on souhaite créer, livrer.
A travers différentes techniques, et un cadre mise en place, nous allons pouvoir nous assurer que nous intégrons continuellement un code qui sera testé et vérifié, automatiquement.
Garantissant ainsi la cohésion technique in fine de notre projet.
Culture de l’erreur
En code : oui, on peut faire des erreurs et on va s’améliorer avec le temps, pas à pas.
En équipe : on peut se tromper, ne pas réussir du premier coup, l’équipe est là, chacun est là pour s’entraider, pour aider l’autre, les autres à grandir.
Dans le management : personne n’est parfait, et surtout pas le/la manager. Créer le climat d’objectif à atteindre, sans y mettre une épée de Damoclès.
Dans la direction : donner un objectif, une direction qui accepte de se tromper, de corriger, de se faire corriger.
Et surtout, accepter, vraiment accepter de se tromper en mettant en place ce droit à l’erreur : ce droit à l’apprentissage !
Leave a reply