Mon calendrier de l’avent – Jour 7
Maintenant que j’ai établi mon rythme, un sujet techniquement facile, mais toujours « politiquement » sensible : le formatage de code. Je dis politiquement au sens noble du terme, c’est-à-dire au sens de créer un cadre collectif qui permette à l’ensemble des membres de l’équipe de s’épanouir. Et il faut bien l’avouer, le formatage du code est encore aujourd’hui un sujet qui cristalise : est-ce qu’il faut mettre des espaces ou des tabulations ? Et combien ? Est-ce qu’il faut trier les méthodes par ordre alphabétique ou par visibilité ? Et puisqu’on parle de trier du code, pourquoi s’arrêter au code Java ? Pourquoi ne pas se poser la question aussi pour le code Javascript ? Les fichiers de propriétés ? Les fichiers yaml ? Le pom maven ?
Personnellement, je crois comme Lawrence Lesig (mais dans un autre contexte) que le code, c’est la loi. C’est-à-dire que les règles de l’équipe doivent être portées r des outils automatiques. Et concernant l’écriture du code, l’outil idéal pour porter cette politique n’est sûrement pas la revue de code faite manuellement après coup, mais plutôt l’outil de build, dans mon cas, le bien-aimé (non, personne ne devrait l’aimer) maven.
Donc il faut utiliser maven. Heureusement, cet outil existe depuis longtemps, a un écosystème riche, et certains plugins d’aggrégation. En l’occurrence, spotless-maven-plugin agrège tout un tas d’outils de formatage. Personnellement, quand je l’utilise – dans chaque projet maven sur lequel je travaille – je commence toujours par mettre en place les règles de formattage de pom maven. Ca clarifie les choses, et ça permet aussi de montrer aux développeurs que le formattage au build, c’est une bonne chose. Et il est facile d’être progressif et de rauter de plus en plus de règles, en fonction des envies de l’équipe.
Cerise sur le gateau, spotless est également disponible pour gradle !
#format #maven #noel #plugin