Comment produire de la documentation technique et fonctionnelle, sans y consacrer des activités à part entière durant le projet (activités souvent écourtées/supprimées sous la pression des délais/des charges du projet).
La documentation intrinsèque se matérialise par la production d'une documentation de qualité inhérente à votre processus de développement (qui ne peut être lui supprimés, c'est le résultat final) : User Story, BDD, TDD, code explicite.
NB : des commentaires expliquent les slides -> téléchargez la présentation
2. Qui suis-je ?
Architecte/chef de projet/consultant mais avant tout
ARTISAN DEVELOPPEUR
> Twitter : @clem_bouillier
Membre actif des groupes suivants
> DevLyon : groupe de développeurs partageant une vision de
l’informatique créant de la valeur http://devlyon.fr
> MUG Lyon : groupe de passionnés de technologies en
environnement Microsoft sur Lyon
> Fier d’être développeur : groupe visant à promouvoir le métier
de développeur en France http://fierdetredeveloppeur.org/
4. …on vous explique les
processus à suivre pour y
arriver (ou pas!)
Exemples typiques :
Qualité = spécifications exhaustives, plans de tests, usine de tests manuels…
Documentation = spécifications exhaustives upfront, code commenté, wiki après
avoir codé…
Tout ça au bon moment dans le cycle projet évidemment !
6. Qualité en
apparence (pour
le client, à la
« recette »)
Aller vers la
QUALITE
INTRINSEQUE
Documentation
désynchronisée de la
réalité
(voire le néant)
Aller vers la
DOCUMENTATION
INTRINSEQUE
7. Qualité et documentation
intrinsèque vont de pair
Ne demande pas d’activités spécialisées ayant un autre but que :
« Produire un logiciel opérationnel PLUS QU’une documentation exhaustive »
11. …puis outillez légèrement
Conserver les éléments notés autour des User Story lors de la réalisation
(1 User Story = 3C : carte, conversation, confirmation)
+
Regrouper les User Story par Theme/Activité fonctionnel(le)
+
Gérer les User Story obsolètes (suppression/évolutions)
+ Taches…
+ Test Cases…
12. …et documenter avec une
démarche BDD
Piloter vos développements par la description du comportement métier désiré
« Conversation » et « confirmation » (cf. 3C) sont intimement liés
Le code est fonctionnellement lié à la User Story
14. Code explicite
PLUS QUE code commenté
Eviter les commentaires quand vous pouvez expliciter la même chose dans le code
Reprenez les termes métiers dans votre code
/! aux abstractions et aux APIs : à documenter (JavaDoc…)
// check to see if employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG)
&& employee.age > 65)
if (employee.isEligibleForFullBenefits())
Chapitre 4 de Clean Code – Uncle Bob
15. TDD = Test Driven
Development, mais aussi
DESIGN (= conception)
Conception incrémentale PLUS QUE « upfront »
+
Documentation des intentions plus que la structure
+
BONUS : tests automatisés non-régression
16. Et en complément…
Commentaires de commit propres (liés au User Story en BONUS)
+
Un wiki pour documenter
1. les pratiques de l’équipe
2. les exigences transverses
17. Toutes ces pratiques portent la
documentation
= Documentation intrinsèque
User Story/Story Mapping
BDD
TDD
Code explicite
PLUS QUE des processus de documentation complémentaires
Vous ne les connaissez pas ? Etudiez, entrainez-vous au plus vite…