11 private links
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 😉
Nom de Zeus : Du refactoring au build ! ca m'a l'air fou ... et potentiellement génial !
Une affirmation discutable par son absolutisme ... Mais néanmoins intéressante.
Oh c'est vraiment une belle citation : "les travailleurs ne provoquent pas des accidents, ils déclenchent des accidents qui attendaient d'arriver".
Il est très bien, cet article ! Cette idée d'avoir un algorithme de résolution de priorité qui soit public et explicite me paraît honnêtement être de l'ordre du génie.
C'est une méthode de validation de couverture de test intéressante.