Advertisement
Faire du-code-centre-sur-l-humain devoxx
Report
VISEOFollow
VISEOApr. 26, 2012•0 likes•3,042 views
0 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Faire du-code-centre-sur-l-humain devoxx
Apr. 26, 2012•0 likes•3,042 views
0 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Report
Technology
Présentation de Yannick Grenzinger au Devoxx France 2012 : Faire du code centré sur l'humain
VISEOFollow
VISEOAdvertisement
Faire du-code-centre-sur-l-humain devoxx
- Faire du code centré sur l’humain ! par Yannick Grenzinger @ygrenzinger 1
- Faire du code centré sur l’humain difficile de faire du code Pourquoi est il si qu’un autre humain puisse facilement comprendre et maintenir ? Parce que nous avons tous notre vision du monde ! Mais les concepts du design et de l’utilisabilité peuvent nous aider ! 2
- Yannick Grenzinger •@ygrenzinger •Développeur chez Objet Direct •avec une passion pour la psychologie, l’agilité et l’expérience utilisateur (UX) en général •Blog UX : http://ux-fr.com •http://about.me/yannick.grenzinger 3
- “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” Martin Golding 4
- 5
- Le modèle mental du code Modèle mental – codeur original ≠ Modèle mental - mainteneur 6
- Les ergonomes ont déjà trouvé des solutions pour les objets de tous les jours ! Design centré sur l’utilisateur 7
- Voir le code comme un objet ? = 8
- Créons de bonnes affordances 9
- Les concepts 10
- Associations symboliques Dans le code : le nommage les patterns … 11
- Associations naturelles Behaviour driven development: • Given [condition] • When [action] • Then [resultat] 12
- Contraintes Evitons le code générique: • main (String[] args){ … } • void changeValeur( Object o, String nomChamp, Object val) 13
- Visibilité Evitons ce genre de piège : @Service Class MonService { @Scheduled void chaqueMatin() { reveilleToi(); } @Transactional void reveilleToi() { … } } 14
- Codons pour l’erreur code défensif Trace d’erreurs claires et complètes 15
- Standardisez ! Faites des opérations similaires pour des tâches similaires 16
- La boucle de feedback • Test Driven Development • Intégration continue • Déploiement continu Permettent d’accélérer le feedback ! 17
- Documentez ! “Good code is its own best documentation.” Steve McConnell Mais ne laissez pas le développeur seul face à votre génie ;) 18
- En appliquant ces concepts Votre modèle mental = Celui du mainteneur + documentation 19
- Vous aurez un code plus facile à comprendre plus lisible plus maintenable centré sur l’humain ! 20
Editor's Notes
- Bonjour, je suis Yannick Grenzinger, développeur chez Objet Direct, un des sponsors de Devoxx France. En plus de mon métier de dev, j’ai une passion pour la psychologie, l’agilité et l’expérience utilisateur en général. J’ai d’ailleurs un blog à ce sujet : ux-fr.com et vous pourrez trouver plus d’information sur ma page about.me .
- J’imagine que tout le monde ici code comme si la personne qui maintenait votre code serait un dangereux psychopate qui sait où vous habitez. Vous suiviez les principes d’Oncle Bob. Vous faites du code propre, compréhensible, maintenable.
- Et pourtant cela semble toujours finir en un code incompréhensible où la qualité se mesure au nombre de jurons à la minute. Les autres sont ils trop mauvais pour comprendre notre superbe code ?
- En fait nous avons tous notre façon de comprendre et d’interpréter notre monde. En fonction de notre pensée, du contexte et du problème, nous créons un modèle mental. La projection de ce modèle mental correspond au code que nous écrivons. A partir de ce code, le développeur qui vient maintenir le code va se construire son propre modèle mental. Et même s’il comprend le problème, il va très souvent construire un modèle mental très différent du codeur original. La différence entre ces deux modèles mentaux est l’origine de notre problème. Alors comment les rendre identique ?
- Le domaine du design avec des personnes a déjà étudié et trouvé des solutions à ce problème de modèle mental. Donald Norman, professeur en sciences cognitives, a d’ailleurs créé le design centré sur l’être humain. Pourquoi ne pas faire la même chose en tant que développeur ?
- Peut-être pourrions-nous voir notre code comme un objet qui va être réutilisé par des utilisateurs, d'autres codeurs et on pourrait parler de code centré sur l’humain
- Vous n’avez pas l’impression que cette porte ressemble fortement au code qu’on n’a l’habitude de croiser tous les jours ? L'affordance est la capacité d’un objet à suggérer sa propre utilisation. Par exemple pour qu’un code soit facilement utilisable, il doit avoir la capacité à suggérer sa propre utilisation. On parle de bonne affordance. La porte que vous voyez est un exemple de mauvaise affordance. Je vous propose de mettre en avant les différents concepts qui vont nous aider à construire du code centré sur l'humain
- Les associations sont la pour rendre simple les relations entre les opérations possibles et leurs effets . On voit ici l’exemple : Le nommage et les patterns sont ainsi des associations symboliques construites par la communauté des développeurs ou par l’équipe. Le nommage : get, set, addElement, removeElement … Les patterns : xxxBuilder, xxxFactory …
- En parlant de nommage, on peut aller plus loin et utiliser le langage qui est une des meilleurs associations naturelles dans le cadre abstrait du code. Les DSL type Behaviour driven development sont un très bon exemple.
- Pourquoi arrivent-on à construire facilement une moto en Lego ? Parce que chaque pièce de Lego nous contraint à placer les éléments d’une certaine façon. Les contraintes limitent les actions possibles. Cela guide l’utilisateur et réduit les risques d’erreur. Un code très générique et très flexible manquera de contraintes et sera plus difficile à comprendre.
- Le tableau de bord d’une voiture nous fournit beaucoup d’indicateurs sur l’état des opérations et les actions possibles. On parle de bonne visibilité. Les problèmes arrivent quand on ne peut voir ce qui se passe. Or, pour réduire la charge du code on a tendance à rendre beaucoup d’opération invisible, on utilise des frameworks. Ces frameworks ont tendance à donner une mauvaise visibilité. Il faut mettre des métriques, des logs, expliquer à votre utilisateur ce qu’il se passe ! Evitons le piège de l’exemple d’utilisation de Spring ici même. Les deux premières personnes qui trouvent le problème auront un cadeau en fin de session
- En tant que développeurs, nous sommes un peu des équilibristes surtout quand on travaille sur du code legacy N’hésitez pas à mettre des filets de sécurité ! Nous apprenons en faisant des erreurs . Il faut donc s’y préparer. Faites du code défensif. Mettez une explication de l’erreur précise et claire.
- On a tous envi de créer la chaussure rouge au millieu de toutes ces chaussures blanches mais il faut savoir que les systèmes consistants sont plus faciles à apprendre. Faites des opérations similaires pour des tâches similaires. Standardisez et soyez consistant !
- Pour comprendre et créer du code, nous fonctionnons tous de la même façon. Avant de coder notre objectif, nous interprétons le code existant. Et en fonction de notre objectif et de cette interprétation, nous écrivons le code qui vient se rajouter au code existant. Les problèmes émergent lors de l’interprétation et de l’écriture du code. Nous avons besoin d’un feedback pour réduire ces problèmes et, plus nous réduisons cette boucle, plus nous sommes efficaces. C’est la que le pair programming, le TDD, l’intégration ou le déploiement continu nous aide à accélérer le feedback.
- Enfin on sait tous qu’un bon code n’a pas besoin de documentation comme un objet bien désigné n’a pas besoin d’aide. Cependant vous rencontrerez souvent des problèmes complexes avec des solutions spécifiques et complexe et, dans ce cas, documentez ! Ne laissez pas le développeur seul face à votre génie ;)
- Quand nous aurons réussit à appliquer une bonne partie de ces principes, la personne qui aura à comprendre le code pourra ainsi se construire un modèle mental bien plus proche du votre. Vous allez rendre votre mainteneur heureux
- Vous aurez un code plus facile à comprendre, plus lisible, plus maintenable centré sur l’humain ! Merci !
Advertisement