Outils | Entreprise | Compte-rendus | Humeurs |   

Mot-clé - clean code

Fil des billets - Fil des commentaires

4 juin 2010

Session : comment écrire du code testable

 J'ai eu le plaisir d'animer la session "Comment écrire du code testable" à la conférence Agile France 2010. C'est l'heure de mettre les slides à disposition et de faire une rétrospective !

Connaître les symptômes d'un code intestable vous permettra de mieux vous en débarrasser :
  1. Un constructeur cher
  2. Des instanciations directes
  3. Des blocs statiques
  4. Une dynastie de classes
  5. Des états globaux
  6. Annuaire de service
  7. Interroger des collaborateurs
  8. Des classes hyperactives
  9. Des méthodes trop chargées
  10. Mélanger les objets valeurs et les objets services

Lire la suite...

30 avril 2010

Soat à l'agile conférence

Agile Conference 2010

Nous tiendrons deux sessions à l'agile conférence (ex-XPDays) les 31 Mai et 1er Juin : un atelier fun et une conférence geek.

Survivre sur la lune avec la NASA ou l’importance de travailler en groupe

L'idée de l'atelier est de démontrer que pour résoudre un problème, 1111 est bien plus fort que 1+1+1+1. On sait ce qu'on perd en mobilisant du monde sur une tâche (pair programming, planning game), mais nous ne sommes pas si convaincus de ce qu'on y gagne. Nous allons pouvoir comparer les résultats des deux approches en réfléchissant ensemble sur un exercice de survie de la NASA.

Voir les autres billets sur le même sujet.

Comment écrire du code testable

Nous pouvons avoir toute la bonne volonté du monde, travailler en TDD, s'être familiarisé avec les frameworks de mocks et pourtant encore galérer sur le posage de tests, en particulier sur du code existant. Ne pas pouvoir en poser n'est pas une bonne raison pour ne pas en faire, surtout si c'est fréquent. Vous apprendrez ce qui fait qu'un code est facilement testable ou non. Vous saurez repérer les signaux d'alertes et verrez quelles solutions sont possibles face à ce type de problème.

Voir les autres billets sur le même sujet.

Agile conférence 2010

Le programme des conférences sera en ligne demain. Esther Derby, co-auteur du livre référence 'Agile Retrospectives est invitée cette année.

Il reste 21 places au tarif préférentiel, vous pouvez encore en profiter.

28 avril 2010

Design for Testability, de Misko Hevery

Misko Hevery reprend dans Design for testability les différents points abordés lors de ses clean code talks.

En conséquence, si vous avez regardé les vidéos clean code talks, vous allez sentir quelques répétitions.

Lire la suite...

6 avril 2010

Book review : Clean Code, Robert C. Martin

I really enjoyed the first part of the book and read it very fast. Then I got slower in the second part with the case studies. But I eventually finished it and I really don't regret purchasing it.

Read the review of Clean Code....

27 janvier 2010

Don't Look For Things, de M. Hevery

J'entends assez souvent "il faut", "il ne faut pas", comme si c'était une loi venant d'une instance suprême. Ce n'est pas un reflexe de remettre les choses en cause et de se demander pourquoi on fait quelque chose. Questionner n'est pas forcément bien vu non plus et peut heurter. C'est la force de l'habitude.

Si un projet plante, et que le manager n'a rien fait de "spécial", on se dira que c'est la faute à pas de chance. S'il a eu le malheur d'innover, en mettant en place des méthodes agiles par exemple, alors il y a de grandes chances pour que ce soit cette innovation qui soit pointée du doigt. Quelque part, suivre sans interroger se comprend, nous supposons que d'autres gens se sont déjà penchés sur la question. Heureusement que nous avons un minimum confiance en notre passé.

Extrait d'une conversation :

Bonnie : On devrait regrouper les imports statiques des matchers JUnit que l'on utilise dans une librairie à part, et ne faire qu'un seul import.

Clyde, hésitant : S'ils sont amenés à être utilisés ensemble, pourquoi le framework ne met pas directement tout dans un seul import ou dans le même package? Plutot que pousser chacun à tout repackager?

Bonnie : C'est une bonne pratique, même sur Xebia ils le disent. Si tu ne me crois pas, tu peux demander aux architectes, ils te diront la même chose.

Ah bah s'ils le disent... Autant vous dire que l'argument qui tue "c'est Jacques que tout le monde respecte qui l'a dit" a beaucoup aidé Clyde.

Cela n'empêche pas Bonnie d'avoir raison. Un argument est évoqué dans Clean Code, elle concerne les API externes en général. L'idée est de réduire le couplage de notre code avec les API externes tout bêtement. Si elles changent, il n'y aura qu'un endroit à changer. Depuis, j'ai cette "note pour moi-même" : même si les raisons me paraissent évidentes, elles ne le sont pas pour tout le monde, il vaut mieux dire d'emblée pourquoi je pense qu'il vaut mieux faire ci que cela.

Je m'égare, je m'égare. Là où je voulais en venir, c'était qu'on m'avait fait remarquer un jour "qu'il ne faut pas faire travailler un constructeur, même pas en appelant une méthode init()". Je savais cela, mais honnêtement, je ne savais pas très bien pourquoi. Du coup, quand un petit travail dans le constructeur me facilitait la vie, je le faisais quand même...

Et bien voici une raison, citée par Misko Hevery dans Don't Look For Things : pour poser un test sur un objet, l'opération que l'on ne peut absolument pas éviter est d'instancier l'objet et donc d'invoquer le constructeur. S'il y a des opérations compliquées dans le constructeur, nous sommes obligés de faire avec dans les tests. Et tous les tests utilisant cet objet en tant que collaborateur auront le même boulet à trainer (à moins d'avoir un framework magique qui permette de mocker les constructeurs).

Lire la suite...

- page 1 de 2