Session SonarSource à l'ElsassJUG
Très bonne session dirigée avec brio par Freddy Mallet pour re(découvrir) sonar et ouvrir la discussion autour de la qualité du code et de la dette technique.
Parmi les points marquants : - les 7 péchés capitaux du développeur (cf slides) - une méthode de classe n'est jamais trop petite (car maintenance/évolution se traduira toujours par un ajout) Une définition de code sans Tests Unitaires. Il s'agit d'une des options suivantes: - du code jetable - du code dont le coût d'ajout d'une fonctionnalité et des régresssions associées est sans importance; - du code d'une *pure* application CRUD - du code du code legacy dont la piètre qualité entraîne un coût d'écriture et de maintenance des TU trop élevé. Note sur la complexité dans sonar: En standard la complexité par méthode est toujours < 10. Pour autant la norme souhaitable est < 5 pour tout et <= 3 en moyenne Leur mode de fonctionnement : si une tâche prend plus de 1,5 à 2 semaines alors il est impossible d'estimer le temps de réalisation => découpage en étapes fonctionnelles de 3-4jours max => elles-mêmes découpées en baby-steps de quelques heures avec commit en fin de step.
Slides de la présentation : http://www.slideshare.net/ElsassJUG/soire-qualit-logicielle-avec-sonar
To-check list : - Structure101 : outil d'étude de design d'application - nemo.sonarsource.com - Track/Request tracker - Martin Fowler's blog - Itay Maman : A well-written program is a program where the cose of implementing a feature is constant throughout the program's lifetime.