Les bons outils …

9 08 2007

Vous savez que les 10 dernières minutes ont été productives quand vous passez de:

Total time: 15.5901584625244Average time: 3.11803169250488

à

Total time: 3.72735238075256Average time: 0.745470476150513

La raison de cette subite amélioration des performances ? Rien de bien compliqué: juste le fait que la dernière mouture de ruby-prof facilite grandement l’analyse des performances d’une requête donée .. et par là-même simplifie le travail de celui qui essaie d’optimiser un tant soit peu une application web déjà gourmande.

Ajoutez à cela un bon exemple d’utilisation de la part de l’auteur même, et vous avez une amélioration des performances assez impressionante qui somme toute se résume au changement de 2 ou 3 lignes de code. Le plus amusant étant que la cause de ces performances pitoyables était exactement la même que celle expliquée dans l’article: l’utilisation abusive de ActiveRecord#attributes au sein d’une méthode appelée lors de chaque accès aux champs d’un objet :

%self     total     self     wait    child    calls  name
 55.20     28.28    27.35     0.00     0.93    82447  Kernel#clone

Comme quoi, quand on a les bons outils …




BDD

9 05 2007

BDD - Behaviour Driven Development … En français, sans doute quelque chose comme “Développement piloté par le comportement”.

J’étais un fan de Test Driven Development (TDD pour les intimes) … que ce soit dans des languages qui s’y prêtent bien (Ruby, Perl, …) ou pas aussi bien que ça de prime abord (C pour ne pas le nommer)… Un des points fort de cette technique, à mon avis, réside dans le fait qu’elle permet de se placer du point de vue du futur utilisateur de l’API/classe que l’on est en train de développer … et d’avoir toute de suite un retour sur sa facilité d’utilisation, son ergonomie …

BDD n’est en ce sens pas tres éloigné de TDD … avec un coté plus “positif”. En effet, en TDD, on teste son code, avec toute la connotation négative que cela peut avoir ;), alors qu’en BDD on spécifie la façon dont va se comporter le code, et on vérifie qu’il le fait.

Cela peut-être très agréable à lire/écrire si le framework/librairie utilisé se plie bien à cela. Par exemple, en Ruby, et en utilisant RSpec:

Code (ruby)

context "A username with a strange-case fullname" do
  setup do
    @username = UserName.new( "joobarbaz", "jean-Christophe oobar BAZ" )
  end 

  specify "should have correctly capitalized firstname" do
    @username.firstname.should == "Jean-Christophe"
  end

  specify "should have correctly capitalized lastname" do
    @username.lastname.should == "Oobar Baz"
  end
end

Le DSL utilisé permet de spécifier ce que doivent faire les méthodes de la classe et de pouvoir le tester. Si l’on exécute le bout de code précédent:

$> spec -fs username-spec.rb
A username with a strange-case fullname
- should have correctly capitalized firstname
- should have correctly capitalized lastname
$>

.. on en arrive à un affichage de la specification pendant que celle-ci est testée …

On peut donc écrire les spécifications de sa classe, dans le DSL fournit par le framework utilisé, puis écrire le code qui fera que ces spécifications seront remplies: spécifications et code restant alors en parfaite synchronization … on se rapproche presque dans un sens du “LiterateProgramming” cher à Donald Knuth ;)

Donc pour moi, au revoir TDD, bonjour BDD ;)