Archives mensuelles : décembre 2012

FIXME & TODOs

Nos IDEs reconnaissent des tags TODO, FIXME et XXX, etc…, permettant de spécifier que quelque chose est à faire, ou pourrait être à faire, dans le code d’un projet. Je n’en écris plus, et je n’aime pas en voir dans du code sur lequel je travaille. Voici mes arguments contre :

Definition of Done

« Do or do not, … »

On ne devrait pas laisser de morceaux inachevés quand on réalise une tâche. Or commiter du code avec un commentaire de ce type signifie quelque part que l’implémentation n’est pas terminée.

On a deux cas :

  • Soit le point relevé dans le TODO est à faire dans le cadre de la tâche, et dans ce cas la tâche n’est terminée que quand celui-ci est fait.
  • Soit il n’est pas indispensable, au moins pour le moment et dans ce cas (KISS, YAGNI, tout ça, …) il n’est pas à faire, du moins pour le moment.

Dans le second cas, on peut laisser un commentaire expliquant ce qui pourrait être amélioré si le besoin se fait sentir (exemples : optimisation des performances, gestion plus fine des différents cas, …), mais sans laisser de flag, ainsi on a l’avantage d’offrir de l’information au développeur suivant, sans marquer le projet comme inachevé. Un TODO c’est de la dette, un commentaire c’est de la doc.

Effet tâche cachée

Autre point gênant : Les TODO sont en quelque sortes des tâches « cachées » dans le code : à moins d’afficher la vue adequate dans l’IDE, ce que peu de gens font (y compris parmi ceux qui en écrivent) on ne les voit pas. Ils resteront donc intouchés et non implémentés pendant une bonne partie de la vie du projet; ce qui peut amener à avoir l’équivalent de jours, voire de semaines de travail en TODO et FIXME.

Et en fait, il y a d’autres outils pour gérer les tâches :

Pour la plupart des projets, on utilise un bug tracker. Donc si quelque chose ne peut pas être réalisé à un certain moment, parce qu’il manque un pré requis par exemple, ou que cela représente trop de charge pour l’itération en cours, cela devrait apparaitre dans le bug tracker plutôt que dans le code, afin d’éviter cet effet de tâche cachée.

Autre avantage de passer par le tracker : comme bien souvent beaucoup de collaborateurs, notamment des responsables et des fonctionnels y ont accès cela permet aussi de filtrer les todos en se posant les questions « Est-ce vraiment nécessaire ? », et surtout : « Ne devrais-je pas le faire tout de suite en fait ? »

Conclusion

Il ne devrait pas y avoir de TODO dans le code : soit il faut le faire tout de suite, soit ce n’est pas vraiment utile.

Bonus : Et si on en écrit un quand même ?

Si malgré cela on en écrit tout de même, il faut se souvenir que peut-être quelque d’autre s’en occupera, peut-être un an plus tard, et donc laisser assez d’information pour que le point puisse être corrigé.

Exemple d’informations insuffisantes :

// TODO Erreur

Est-ce qu’on devrait remonter une erreur ? Est-ce qu’une erreur se produit parfois ? Laquelle ? Pourquoi ?

 

Chaque site ou application a, ou devrait, avoir une fonction unique formalisée

Petite réflexion du week-end : chaque application, chaque site a une ou des fonctions, qui peuvent normalement se résumer en une ou quelques phrases.

Exemples :

  • fnacspectacles : Vendre des billets de spectacles.
  • outlook.com : Permettre aux utilisateurs la consultation et la gestion de leurs mails en ligne.
  • facebook.com : Permettre aux utilisateurs d’échanger sur  leur actualité personnelle et de discuter.

Formaliser ?

Cette fonction est en générale implicite et évidente. Mais dans certains cas, elle gagnerait sans doute à être formalisé. On voit parfois des applications déesses qui font trop de choses, dont la fonction n’est pas clairement déterminée. Un exemple sur le web (pas forcément le meilleur, puisqu’il s’agit de la définition d’un portail, mais le premier qui m’est venu à l’esprit) : yahoo.fr qui fournit de la recherche, des actualités, un accès à des mails, …

On construit autour de cette fonction

Définir formellement, la mission, la fonction maitresse d’un site ou d’une application permet de mieux définir et de mieux prioriser le besoin et les fonctionnalités : on construit pour et autour de cette fonction.

Référence

De plus cela permet, en cas de doute, d’avoir une référence. La question « est-ce que cette fonctionnalité doit être implémentée/mise en avant ? » devient « est-ce que cela correspond à la fonction de mon application ? ». A chaque questionnement sur le design ou le planning, on peut se référer au but déclaré du projet.

Mobile-first

On dit souvent qu’il faut construire d’abord pour les mobiles, puisque l’espace limité sur l’écran permet de choisir la/les fonctionnalités importantes, à mettre en avant sur tous les supports. Définir formellement la mission de l’application va dans le même sens : qu’est-ce qui est essentiel ?

Fortement lié au business model

Bien sur cette mission est en général fortement corréllée au business model. Dans le cas de facebook par exemple, les auteurs ont tout intérêt à ce que les utilisateurs passent le plus de temps possible sur le site afin d’augmenter les chances qu’ils cliquent sur une des publicités, ciblées avec leurs données. De même le site de fnac spectacles comporte de nombreux liens vers fnac.com.