+yannick grenzinger a fait une présentation, lors d’un quickie (session au format de 15mn), des différents concepts permettant de produire du code où l’humain saura s’y retrouver.
La question posée en introduction résume bien la problématique adressée par cette présentation :
Pourquoi est-il si difficile de faire du code qu’un autre humain puisse facilement comprendre et maintenir ?
A cette question le speaker apporte la réponse :
_ Parce que nous avons tous notre vision du monde !_
Cette introduction positionne le contexte et Yannick va nous expliquer comment faire tendre les visions de chacun vers une perception commune du code.
Inévitablement, il évoque le livre référence dans ce domaine : Clean Code en citant une phrase clef :
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live de Martin Golding
Ensuite, il nous explique un premier concept : le modèle mental du code.
C’est-à-dire que la vision que l’on peut avoir du code va différer entre celui qui l’a écrit et celui qui va le maintenir.
Dans le monde du design, les ergonomes ont mis en place des solutions concernant les objets de tous les jours : Le design centré sur l’utilisateur.
Si l’on fait un parallèle entre l’ergonomie appliquée aux objets et le code, on pourrait essayer de voir le code comme des objets et par conséquent lui appliquer les principes d’ergonomie.
La première chose serait de créer de bonnes affordances afin que notre code soit capable de s’exprimer lui-même.
Aussi, réussir à mettre en place des associations symboliques. Yannick montrait en exemple le panneau de sens interdit où la couleur rouge indique (par association symbolique) une interdiction ainsi que la forme et le contenu du panneau. Dans le cas d’un programme : mettre en place des patterns, des règles de nommage, etc.
La création d’association naturelle au travers du Behavior Driven Development (BDD).
Le processus BDD met en avant le langage naturel et les interactions dans la phase de développement logiciel. Cela permet aux développeurs de se concentrer sur les raisons pour lesquelles le code doit être créé, plutôt que les détails techniques, et minimise la traduction entre le langage technique dans lequel le code est écrit et le domaine de la langue parlée par les entreprises, les utilisateurs, les intervenants, la gestion de projet…
Le speaker encourage le coding défensif, c’est-à-dire de bien gérer les cas d’erreur afin de pouvoir les traiter et faire remonter un maximum d’informations en cas d’erreur.
L’avant dernier point abordé est la boucle du feedback, elle se compose de :
– Le code existant,
– L’interprétation,
– L’objectif,
– L’écriture du code.
Afin d’améliorer le feedback, plusieurs outils sont nécessaires :
– TDD
– Intégration continue
– Déploiement continu
Le dernier point concerne la documentation. Pour illustrer cette idée, Yannick cite une phrase de Steve McConnell : ”Good code is its own best documentation”.
Il la complètera en ajoutant que ce principe, assez connu, ne suffit pas toujours et la documentation dans certains cas a vraiment toute son importance.
Il conclura qu’en appliquant l’ensemble de ces principes (la liste faite ici n’est pas exhaustive), nous aurons un code plus facile à comprendre, plus lisible, et plus maintenable ; autrement dit :
Centré sur l’humain
Cette présentation a abordé, pendant 15mn, un certain nombre de concepts essentiels à connaitre dans la carrière d’un développeur.
Si votre curiosité a été piquée,si ce n’est pas déjà fait, de lire le livre Clean Code 🙂
les slides de la présentation sont disponible sur slideshare
#java #cleancode #design #ergonomie #code
Coder's IO 