Suite à la lecture de cet article sur la différence entre ce qu’est une bonne et une mauvaise dette technique j’ai pris l’initiative de faire réfléchir mon équipe et moi même sur le sujet. Nous avons abordé les choses en plusieurs points, en commençant par qu’est ce qu’une dette technique pour nous.
J’insiste un peu sur le “pour nous” car cet article et les suivants n’ont pas vocation à évangéliser les foules juste à vous partager un retour d’expérience.
Nous avons donc listé les points suivants et je vais tacher à travers une série d’articles de vous faire partager notre expérience.
Une dette technique pour nous c’est :
- absence de respect d’une convention de codage
- absence de commentaires
- complexité du code trop importante
- code dupliqué
- pas de tests unitaires
- pas de test fonctionnel
Nous avons ensuite pris chaque point pour les prioriser et surtout définir le périmètre de chacun. Pour chacun nous avons également discuté des options de mitigation afin de ne pas accumuler de dette sur des points simple.
Commençons par le plus simple la convention de codage. Nous avons adopté les conventions de codage psr 0-1-2-3 c’était un choix évident étant donné qu’on utilise Zend framework 2. Tous les membres de l’équipe ont bien assimilés la chose, tout le monde y trouve son compte en gagnant en lisibilité et en adaptabilité en passant sans problème du code de l’un à l’autre.
Même si la convention est présente dans l’esprit de chacun au court du développement, nous restons des humains faillibles. Pour cela nous nous sommes donc posés la question de comment garantir le respect de cette convention. Nous avons plusieurs éléments à notre disposition.
Premier point notre serveur d’intégration continue, jenkins. On y a PHP code sniffer (phpcs) avec l’implémentation de la convention PSR disponible ici. C’est bien mais on est réactif et non proactif et ça ne nous convient pas complètement.
Nous avons alors utilisé des plugins dans nos IDE. Sur sublime text ou netbeans il existe de solutions qui font tourner phpcs au fil des modifications. C’est bien pratique pour corriger au fil de l’eau les erreurs d’inattention.
Mais cette solution ne convient pas à tout le monde. Alors nous avons rajouté un autre système le pré commit hook. Ce pré commit lance cs fixer de sensiolabs qui corrige automatiquement les erreurs. Et derrière on passe de nouveau phpcs. Ceinture et bretelles on est tranquille.
Actuellement nous n’avons plus ce type d’erreur ou alors occasionnellement quand on fait des développements en dehors de nos ide etc… C’est rarissime mais ça peut arriver. Deux ou trois fois par an.
C’est pas grave on a pas tué un bébé panda.
Voilà pour la partie convention de codage. La prochaine fois on attaque le code dupliqué 😉