Documentation intrinsèque

Human Talks Lyon – Mars 2014 – Hébergé par l’INSAClément Bouillier - @clem_bouillier

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/

La documentation,

c’est un peu comme la qualité…

(…tout le monde en parle, très peu en font…)

…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 !

…et pourtant le résultat est régulièrement le

même…

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

Qualité et documentation

intrinsèque vont de pairNe demande pas d’activités spécialisées ayant un autre but que :

« Produire un logiciel opérationnel PLUS QU’une documentation exhaustive »

1. Documentation fonctionnelle

Développement piloté par l’expérience utilisateur User

Story

…inspirez-vous du Story Mapping…«understanding what your whole system is intended to do » - Jeff Patton

…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…

…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

2. Documentation technique

Code explicite PLUS QUE code

commentéEviter les commentaires quand vous pouvez expliciter la même chose dans le codeReprenez les termes métiers dans votre code

/!\ aux abstractions et aux APIs : à documenter (JavaDoc…)

// check to see if employee is eligible for full benefitsif ((employee.flags & HOURLY_FLAG) && employee.age > 65)

if (employee.isEligibleForFullBenefits())

Chapitre 4 de Clean Code – Uncle Bob

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

Et en complément…

Commentaires de commit propres (liés au User Story en BONUS)+

Un wiki pour documenter 1. les pratiques de l’équipe2. les exigences transverses

Toutes ces pratiques portent la documentation= Documentation

intrinsèqueUser Story/Story Mapping

BDDTDD

Code explicite

PLUS QUE des processus de documentation complémentaires

Vous ne les connaissez pas ? Etudiez, entrainez-vous au plus vite…

MERCI

QUESTIONS ?

ROTI ?