author
Lors de la dernière journée de QCon Londres, dans le cadre du track The rise of Scala & Functional Programming, les équipes du journal The Guardian nous proposaient un second retour d’expérience via leur architecte Graham Tackley. L’objectif de cette session était de présenter comment les équipes sont passées à Scala et comment ce choix a simplifié les développements.
Tout d’abord, il faut savoir qu’entre 2006 et 2008, l’architecture applicative du site web du journal reposait sur un socle composé des technos Spring, Hibernate et Velocity. Assez rapidement, ce socle commença à poser des problèmes de maintenabilité aux équipes. En premier lieu, la cause incombait à la verbosité des technologies utilisées. Pour se faire une idée, il suffit de jeter un œil aux métriques et en particulier au cumul des lignes de code:
- les classes Java représentaient 185.000 lignes,
- les fichiers XML : 35.000 lignes correspondant en grande partie au code Spring,
- les fichiers de templating (Velocity) : 72.000 lignes.
Ces totaux peuvent vous sembler importants, mais il faut se rappeler que Java n’est pas un langage appliquant particulièrement les principes DRY. De plus, les configurations XML des applications basées sur Spring étaient particulièrement verbeuses ce qui est moins le cas aujourd’hui depuis la généralisation de l’usage des annotations. Il faut cependant relativiser s’il faut ramener ces chiffres à la verbosité des tests unitaires qui représentaient à l’époque, accrochez-vous, 248.000 lignes de code.
Graham nous explique qu’un cycle de développement de deux semaines pour une application web est bien trop long. De plus, cela ne répond pas aux exigences du monde du web. Cependant, cela est trop rapide pour les équipes qui ne peuvent répondre aux cadences exigées par le monde du web avec un applicatif aussi lourd à faire évoluer.
Un autre aspect des problématiques de maintenabilité et de charge semblait venir de la partie ORM de l’application. Non pas qu’Hibernate, utilisé à l’époque, soit remis en cause, mais plutôt les concepts associés.
Une des premières initiatives prises pour remédier aux problèmes de cycles de développement a été de scinder l’application monolithique en différentes micros applications indépendantes avec des cycles de développement très courts et dont la maintenabilité est facilitée par leur faible taille et leur découplage.
Rapidement, les équipes ont commencé à créer des micros applications dans différentes technologies telles que Python avec Django. Ces outils ont rapidement permis aux équipes de se focaliser sur des aspects métiers plutôt que sur des aspects techniques. Cependant, ces nouveaux environnements semblaient poser des problèmes d’exploitation puisque les environnements d’exécution associés impliquaient de nouvelles acquisitions de compétences. Cela avait pour effet de générer des problématiques d’exploitation qui jusqu’ici n’existaient pas. Comme Graham le rappelle, il vaut mieux privilégier les évolutions plutôt que les révolutions.
Afin de retrouver un environnement proche du monde Java, les équipes ont cherché de nouvelles solutions et se sont orientées vers le développement de composants basés sur Scala. L’objectif recherché étant d’avoir accès aux avantages que peuvent apporter la JVM et l’environnement Java : même infrastructures, même outils (Maven notamment), même bibliothèques, mêmes runtimes, etc. Le compilateur Scala génère du bytecode et un war, c’est à dire tout ce qu’il y a des plus standard dans le monde java. Scala étant opérable avec Java, il est possible de mixer les deux langages dans une même application et de pouvoir reprendre certaines parties de code de l’un ou de l’autre.
Scala est connu pour sa concision, ce qui est réellement important aux yeux de Graham vis-à-vis des problématiques engendrées par la taille de la base de code historique.
En novembre 2009, les équipes sont parties sur un socle technique basé sur Java + Guice + Guice Servlet + Apache Solr et 3 à 4 développeurs, pour switcher en février 2010 de Java à Scala. Graham explique qu’Il n’aura fallu que trois mois à l’équipe pour passer le projet en Scala et le porter en production. Par la suite, il insiste sur le fait que la mise en production s’est passée sans incident, et ce, même avec un changement aussi impactant.
Enfin en juillet 2010, les équipes sont passées à SBT afin de disposer d’un outils plus puissant et mieux adapté aux besoins des projets Scala. SBT permet en particulier d’outrepasser les problématiques de lenteur du compilateur Scala.
La stack actuellement exploitée par le site est composé de Scala + Lift + Apache Solr. On pourra s’interroger sur ces changements de technologies incessants. Mais comme le répète Graham, mieux vaut privilégier les évolutions que les révolutions.
Afin de faire taire certaines idées persistantes à propos de la supposée difficulté d’apprendre Scala, Graham prend les devants en expliquant que ce choix a été plus bénéfique que prévu pour les équipes. Les membres ont pris beaucoup de plaisir à apprendre ce langage, ce qui a favorisé une forte collaboration dans cet apprentissage. Cela a pris entre un et trois mois pour que chaque développeur devienne productif avec le langage. Graham insiste sur le fait que ses équipes n’ont pas rencontré tous ces problèmes énoncés dans différents articles qui ont enflammé la communauté Scala ces dernièrs mois.
Graham voit au final dans Scala plusieurs avantages pour ceux qui veulent l’utiliser ou bien encore l’apprendre :
- Scala tend à favoriser l’immutabilité dans les développements,
- La console Scala encourage la vision du code comme une entité vivante (qui évolue),
- Les frameworks de tests sont d’une extrême simplicité,
- Scala ne pousse pas à l’intégrer de frameworks complexes à tous les étages.
Parmi les inconvénients imputables au langage, Graham met en avant :
- La relation de type “je t’aime, moi non plus” des développeurs (en général) avec SBT. On pourrait dire la même chose avec la communauté Java avec Maven…
- Le support encore immature des outils,
- Un compilateur lent,
- Le rythme des évolutions du langage.
Enfin, Graham dit à demi-mot que le framework Play!2 semble très prometteur et qu’il faut garder un œil dessus dans les prochains mois.
Liens utiles:
- Slides de la présentation: Simplifying Development at the Guardian.co.uk