Vous trouverez une étude de cas intéressante sur les projets de dimensionnement utilisant un langage interprété et dynamique dans Beginning Scala de David Pollak.
J'ai commencé à chercher un moyen d'exprimer le code dans mon cerveau d'une manière plus simple et plus directe. J'ai trouvé Ruby and Rails. Je me suis senti libéré. Ruby m'a permis d'exprimer des concepts dans beaucoup moins de lignes de code. Rails était tellement plus facile à utiliser que Spring MVC, Hibernate et les autres frameworks Web Java «rationalisés». Avec Ruby et Rails, j'ai pu exprimer beaucoup plus de ce que j'avais dans la tête en moins de temps. C'était semblable à la libération que j'ai ressentie lorsque je suis passée de C ++ à Java ...
Alors que mes projets Ruby and Rails s'étendaient au-delà de quelques milliers de lignes de code et que j'ajoutais des membres à mon équipe , les défis posés par les langages dynamiques devenaient évidents.
Nous passions plus de la moitié de notre temps à coder pour écrire des tests, et une grande partie des gains de productivité constatés ont été perdus lors de la rédaction de tests . La plupart des tests auraient été inutiles en Java car la plupart d'entre eux visaient à s'assurer que nous avions mis à jour les appelants lors de la refactorisation du code en modifiant les noms de méthodes ou le nombre de paramètres. De plus, j’ai trouvé que dans les équipes où il y avait une fusion mentale entre deux ou quatre membres de l’équipe, tout se passait bien pour Ruby, mais comme nous essayions d’intégrer de nouveaux membres à l’équipe, les liens mentaux étaient difficiles à transmettre aux nouveaux membres de l’équipe .
Je suis parti à la recherche d'un nouveau langage et d'un environnement de développement. Je recherchais un langage aussi expressif que Ruby mais aussi sûr et performant que Java ...
Comme vous pouvez le constater, la mise à l'échelle des projets pour l'auteur s'est révélée être un défi majeur en termes de développement de tests et de transfert de connaissances.
En particulier, l'auteur explique plus en détail les différences entre les langages typés de manière dynamique et statique dans la rédaction de tests au chapitre 7. Dans la section "Poignly Killing Bunnies: Dwemthy's Stairs", l'auteur traite du port Scala d'un exemple Ruby particulier:
Why the Lucky Stiff ... présente certains des concepts de métaprogrammation de Ruby dans Dwemthy Array, dans lesquels un lapin combat un éventail de créatures. N8han14 a mis à jour l' exemple pour qu'il fonctionne en Scala ...
Comparé au code Ruby, les éléments de bibliothèque du code Scala étaient plus complexes. Nous avons dû faire beaucoup de travail pour nous assurer que nos types étaient corrects. Nous avons dû réécrire manuellement les propriétés de Creature dans les classes DupMonster et CreatureCons. C'est plus de travail que method_missing
. Nous avons également dû faire pas mal de travail pour soutenir l’immuabilité de nos Créatures et Armes.
Par contre, le résultat était beaucoup plus puissant que la version Ruby. Si nous devions écrire des tests pour notre code Ruby afin de vérifier ce que le compilateur Scala nous assure, nous aurions besoin de beaucoup plus de lignes de code. Par exemple, nous pouvons être sûrs que notre lapin ne pourrait pas manier une hache. Pour obtenir cette assurance dans Ruby, nous devons écrire un test qui vérifie que l’invocation |^
sur un lapin échoue. Notre version Scala garantit que seules les armes définies pour une créature donnée peuvent être utilisées par cette créature, ce qui nécessiterait beaucoup de réflexion à l'exécution en Ruby ...
La lecture ci-dessus peut laisser penser que, à mesure que les projets prennent de l'ampleur, la rédaction de tests peut devenir extrêmement lourde. Ce raisonnement serait faux, comme en témoignent des exemples de très grands projets réussis mentionnés dans cette question ("Python est utilisé avec succès pour ... YouTube").
Le problème est que la mise à l'échelle des projets n'est pas vraiment simple. Les très grands projets à longue durée de vie peuvent «se permettre» différents processus de développement de tests, avec des suites de tests de qualité de production, des équipes de développement de tests professionnelles et d’autres types de produits lourds.
Les suites de tests Youtube ou le kit de compatibilité Java ont une vie différente de celle des tests dans un petit projet de tutoriel tel que Dwemthy's Array .