Je ne suis pas d'Helm (je trouve que c'est rajouter une couche de complexité inutile à la complexité inutile de K8s). Heureusement, on peut tester les descripteurs qu'on génère grâce à ce plugin. Et en plus il semble exister une convention permettant d'avoir de la validation dans le YAML avec VSCode.

Un bon article sur les attributs de qualité d'un système logiciel

Un article en français qui présente bien ce protocole d'écriture de tests

A priori, ce plugin permet de configurer dynamiquement tout un tas de plugins d'analyse de qualité de code (PMD, JDepend et autres)

Un outil sympa pour prioriser les refactorings. Et en plus il s'intègre dans maven

J'ai survolé l'article, mais je suis d'accord dans l'ensemble : il faut diminuer le nombre de fois où les humains impactent la livraison logicielle. Y compris en remplaçant les tests manuels par des tests automatiques.

Un article (et repo github) extrêmement complet sur les pratiques modernes dans le développement Java. Il y a tout un tas de bons conseils, et d'outils intelligents à mettre en place.
C'est sans doute un point de départ bien plus intéressant que de simplement utiliser un artefact maven ...

Il y a là-dedans un concept très intéressant, dont je vais avoir besoin très prochainement

L'article est extrêmement intéressant et couvre vraiment bien l'ensemble des impacts qu'il y a à réfléchir sur la qualité du code et sur tous les éléments associés.

J'ai parfois fait des choses un peu analogues, mais la systématisation du process (et l'inclusion des tickets de dette technique, dont je parle toujours mais que je ne fais pas assez) et vraiment bien pensée

Si vous voulez comparer la couverture de tests de votre branche avec celle d'une autre branche, ce plugin Maven est pour vous

Mais qu'est-ce que je fais ? Eh bien, tout simplement, j'essaye de créer de la confiance dans une base de code qui ne me donne vraiment pas confiance.

J'ai déja dû partager la version originale.
Mais en version traduite en français, c'est encore plus percutant

Une liste des éléments d'un logiciel de qualité. C'est assez intéressant, même si c'est assez simple.

Un détecteur de noms linguistiquement incorrects (par exemple un setter qui retourne une valeur)

Des métriques de sécurité pour les projets open-source. C'est plutôt une bonne idée. j'espère juste que ça n'est pas la même farce que le scan de vulnérabilité par analyse des dépendances ...

Cette discussion pose une vraie question méthodologique : comment compter les erreurs évitées ?

La conscience de soi et de ses limites est un truc que je travaille beaucoup à développer. Et ça n'est pas facile. Mais typiquement, le questionnement de soi à travers la psychologie, la réflexion, aident beaucoup.

L'idée est super chouette !

Une belle et bonne doctrine, qui améliore réellement les choses. Evidement, ça n'est valable que quand on est en position de corriger les problèmes 😉