Il y a eu un débat comme ça lors du dernier apéro Rails Paris (à quand le 
prochain ?), entre l'utilité, la faisabilité, l'usage, l'élégance, la 
propreté... et comme Raphaël venait de terminer sa présentation 
CoffeeScript, on comparait les approches de plusieurs langages.

À quatre, on a réussi à être d'accord sur trois points :

 * FACILE : bien sûr que c'est faisable, surtout en Ruby.
   Le moyen précis ou l'astuce technique varie selon chacun mais ce n'est 
pas très grave.

 * ILLISIBLE : tout va bien tant que tu maîtrises ta codebase, en gros que 
tu es seul. Plus, et c'est la cata.
   C'est moins lisible, moins compréhensible, c'est plus dur pour un autre 
dev de rentrer dedans...
   sans parler de toi-même, si tu dois relire ce code dans un an et que ta 
méthode favorite a changé.

 * DANGEREUX : si les développeurs de bibliothèque y jouent.
   Ils ne devraient jamais livrer du code avec ce genre de surprises, parce 
que tu ne sais jamais quelles astuces de code un autre développeur ou une 
autre lib utilisera.

   Et aussi parce que c'est Mal de pourrir le namespace global, parce que tu 
ne maîtrises pas toujours ton environnement et la manière dont ça sera 
initialisé, et simplement par respect des contributeurs et utilisateur (car 
illisible).


Bref, trop jouer au monkeypatch, c'est Mal, et on ne devrait le faire que 
sur des projets tout petits (en lignes de code et en durée de vie), sur 
lesquels tu es tout seul comme dev, que tu utilises un minimum de 
bibliothèques, qui ne sera pas utilisé par d'autres... au final, très très 
peu de scripts rentrent dans ces contraintes.

-- 
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
[email protected]

Répondre à