Psychanalyse du code

28 fév

 Pour ceux qui ne connaissent pas la pyramide de Maslow, voici un petit résumé : il s’agit d’une étude menée par le psychologue Abraham Maslow dans les années 1940 sur la motivation, résultant sur une hiérarchisation des besoins humains (physiologiques et psychologiques). Il explique qu’il faut veiller à satisfaire les besoins dans un ordre précis : par exemple, se nourrir avant de rechercher l’estime de soi.

À noter : si cette étude a été et est toujours largement appliquée aux problématiques de motivation au travail, le travail de Maslow était plus général et s’intéressait à la dynamique de la motivation dans la vie en général. Et Maslow n’a jamais présenté les conclusions de son étude sous la forme de la pyramide qu’on connaît aujourd’hui, mais c’est cette représentation qui s’est imposée pour son aspect « pratique ».

 

Scott Hanselman, l’un des plus influents développeurs de Microsoft l’a adaptée pour créer « the Hierarchy of Needs to Software and Technical Debt » qu’on pourrait traduire par « la pyramide des besoins structurels et techniques d’un logiciel ». En d’autres termes, quelles sont les caractéristiques nécessaires pour que mon code soit optimal ?

Revisable -  Change

Avant toute chose, le code doit pouvoir être modulable : le workflow des contributions est-il clair ? Est-ce que je peux annuler des modifications ? Est-ce que je peux facilement créer des branches ? Est-ce qu’il est possible de merger  sur les différents environnements ?

Buildable & Deployable – Change in production

Ensuite, il doit pouvoir être déployé aussi facilement qu’il a été codé. L’intégration continue est ce qu’on peut trouver de mieux dans les logiciels actuels, mais il ne faut pas négliger l’aspect déploiement continu… avec possibilité de rollback !

Maintenance – Change with verification

Une fois que la partie « développement » est optimale, il faut s’intéresser à la partie « maintenance ». Puis-je corriger les bugs ? Vérifier que les modifications que j’apporte sont bonnes et que je ne fais pas planter le reste du logiciel / site ? Puis-je mettre en place des tests ?

Refactorable – Change without fear

Si mon code est optimal aujourd’hui, ce ne sera peut-être plus le cas dans quelques temps. Est-ce que je peux facilement réorganiser mon code / mon système sans danger ? Est-ce qu’il est conforme aux conventions et utilise les axiomes appropriés au langage que j’ai choisi ? Puis-je automatiser des tests ?

Bragging Rights – Change you are proud of

Enfin, une fois que toutes les conditions précédentes sont réunies, je peux me vanter ! C’est à ce niveau-là que je me pose la question : est-ce que j’écris du code ou est-ce que je créé du code ? Mon code devient de l’art, et les générations futures (les développeurs en charge de la maintenance de mon logiciel / code) se diront « Wow ! »… mais uniquement si toutes les étapes précédentes sont respectées.

 

Scott Hanselman termine en précisant la nécessité d’un chef de projet rigoureux et attentif. Faire de mon code de l’art, c’est la partie fun, mais ce n’est pas forcément ce qu’il faut pour faire avancer le projet. Le chef de projet doit s’assurer que les processus fondamentaux sont en place en premier lieu.

No comments yet

Leave a Reply

*