Revue de code
Le but de la revue de code (merge request, pull request) est de réduire les erreurs de conception, d’éviter les régressions, partager les connaissances
Pour que les revue de code se passe bien:
- Automatisez le linter (style guide adopter par l’équipe)
- Automatisez l’éxécution des tests avant l’acceptation de la PR. Si TU fail , PR ne peut pas passer
- Faire de petites Merge request et de petits commits
- Etre humain, pensez aux autres developpeurs du projet
KISS
Keep it simple stupid : on préconise la simplicité dans la conception de toute chose et toute complexité non indispensable est à éviter. Ce principe ne s’applique pas qu’au développement mais à beaucoup d’autre discipline
DRY
Don’t repeat yourself. La duplication est un problème en développement.
SOLID
Single responsibility : une classene devrait avoir qu’une seule responsabilité.
Open-closed : principe ouvert / fermé : les classes doivent être ouverte aux extensions mais fermées aux modifications.
Liskov Substitution
Interface segregation
Dependency inversion
STUPID
Terme utilisé pour décrire un code cauchemardesque.
Singleton
Tight-coupling : couplage fort
Unstestability : intestable
Premature Optimization : optimisation prématurée
Inconsistence naming : nommage incohérent
Dupplication
Clean Code
Code prope ? Chacun a sa définition. mais la majorité est d’accord pour dire qu’un code prope est plus maintenable et évolutif. Il peut être définit comme suit
- un code simple : au niveau implémentation, pas de hack, pas de magie, ps de code trop verbeux. Le code peut ne pas être simple au niveau algorithme mais son implémentation doit le rester autant que possible.
- un code lisible : les intentions d’origines de l’auteur du code doivent être comprises par n’importe quel développeur arrivant sur le projet. Pour ce faire il faut suivre les bonnes pratiques, conventions de nommage et de codage. Le code peut paraitre moins élégant mais il est dès lors plus ouvert à la communauté.
- un code testé : pour éviter de casser le code lors d’ajout de nouvelle fonctionnalité dans le futur
- un code pratiqué : écrire du code propre nécessite d’avoir de bon réflexes. Plus on pratique , plus on s’améliore. De ce fait même sur les projets personnelle, il faut continuer à avoir du code propre.
- un code sans cesse refactoré : un code prope est un code en constante refactorisation. Avec une bonne couverture de code, on ne craint plus les régressions.
- un code SOLID: un code prope est code qui est définit autant par sa propeté que par sa bonne conception
SOURCE :
Craftmen
Le craftmanship est une approche agile axée sur la qualité techniques des réalisations.
A la base, le manifeste agile
La méthode agile contient 4 valeurs fondamentales avec 12 principes sous-jacent à ces valeurs.
Les 4 valeurs du manifeste agile sont :
- Les individus et leurs interactions plus que les processus et les outils
- Des logiciels opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que le suivi d’un plan
(rappel : Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.)
Le manifeste du Software Craftsmanship part de ces 4 valeurs agiles pour compléter certains aspects afin de renforcer l’excellence technique déjà recommandée par le manifeste agile lui-même.
Le manifeste du Software Craftsmanship
Voici les 4 valeurs du software craftsmanship qui ont été écrites par les craftsman se voulant de ce mouvement agile :
- Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
- Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de valeur.
- Pas seulement les individus et leurs interactions, mais aussi une communauté professionnelle.
- Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.
« C’est-à-dire qu’en recherchant les éléments de gauche, nous avons trouvé que les éléments de droite sont indispensables. »
Fondamentalement : un retour non référencé à XP
Finalement, il ressort de l’analyse de cette déclaration la constatation d’une reformulation des autres méthodes agiles et particulièrement d’XP :
- Qualité : conception simple (DDD, OO), clean code et refactoring, tests dont TDD (XP)
- Humilité : je me remets en question et je m’améliore en continu (rétrospectives de Scrum)
- Partage : binomage, pair programming et propriété collective du code (XP)
- Pragmatisme : je comprends les contraintes et m’adapte si nécessaire (rétrospectives de Scrum)
- Professionnalisme : je traite mon client comme un partenaire (principe du « courage » d’XP)
SOURCE :
Test de comportement
Pourquoi :
- Eviter les campagnes de tests manuels (notamment lors des montées de version techniques)
- Centralisation des cahiers de recette
- Sécurisation du fonctionnel des applications -> Fiabilité
- Gain de temps:
- Livraisons plus fréquentes, plus rapides.
- Régression anticipée
- Gain d’argent pour la société