Retour à l'accueil

14 ans de Pastebin sur Scala : Leçons de maintenance

L'article décrit l'évolution sur 14 ans du Pastebin interne sur Scala, Spring et Hibernate. Il couvre les problèmes de compatibilité, le crash des frameworks Compass et Tiles, le choix de Maven. Leçons pour la maintenance de projets legacy.

Comment maintenir Pastebin pendant 14 ans : Crash des frameworks et Scala
Advertisement 728x90

14 ans de support pour un Pastebin interne : Leçons tirées de l'évolution de la pile technique

Un outil interne de partage de code et de logs, similaire à Pastebin, lancé en 2012 et ayant duré 14 ans. Initialement, il s'agissait d'un simple formulaire web pour enregistrer des « collages » avec génération de liens et suppression automatique des entrées obsolètes. Par la suite, nous avons ajouté la coloration syntaxique, les commentaires ligne par ligne, l'autorisation et le dessin sur le texte. La principale valeur était le déploiement local sans services externes.

Le projet ne prétendait pas être unique : de telles solutions sont facilement reproductibles. Le défi principal n'était pas la création, mais le support à long terme, où les technologies deviennent obsolètes, les frameworks meurent et les attentes des utilisateurs augmentent.

Pile technique : Scala associé à Spring et Hibernate

Le choix de la pile était motivé par la disponibilité et l'intérêt : Scala au lieu de Java sur une configuration classique Spring-Hibernate-JSP. Scala 2.x était compilé en bytecode JVM, mais l'intégration a révélé des problèmes de compatibilité.

Google AdInline article slot
  • Annotations et scanners de classes : Spring et Hibernate géraient incorrectement le bytecode Scala. Exemple de problème avec les champs Entity :
@ManyToOne(fetch = FetchType.EAGER, cascade = Array(CascadeType.PERSIST, CascadeType.MERGE))
@JoinColumn(name = "owner_id")
private var owner: User = null

Les champs nécessitaient des valeurs par défaut explicites.

  • Types de données, héritage, énumérations et annotations : Une gamme complète d'incompatibilités, résolues par essais et erreurs.

Nous avons évité NoSQL et le stockage de fichiers : la perte de données au redémarrage était inacceptable. Lucene pour l'indexation provoquait des doublons lors des mises à jour.

Système de build : Maven au lieu de sbt

En 2012, sbt était brut, avec une intégration IDE et CI médiocre. Maven offrait de la stabilité : support de SonarQube, bases de données multiples et conteneurs de servlets multiples.

Google AdInline article slot

Avantages de Maven sur une période de 14 ans :

  • Versions prévisibles.
  • Intégration facile avec l'écosystème.
  • Modifications de configuration minimales.

sbt a évolué, mais la migration n'était pas nécessaire—Maven ne nous a jamais laissés tomber.

La disparition de Compass Search

Compass, le prédécesseur d'Elasticsearch, s'intégrait avec Hibernate/Spring pour la recherche embarquée. D'ici 2014, le projet est mort : l'auteur est passé à ES distribué.

Google AdInline article slot

Conséquences :

  • Les dépendances sur des bibliothèques obsolètes ont cassé les mises à jour.
  • Le support du code mort a duré 5 ans.
  • La migration vers Hibernate Search n'a pas réussi du premier coup.

Leçon : surveillez l'activité des projets en amont.

Problèmes avec Apache Tiles et les modèles JSP

Tiles ajoutait la composition de modèles à JSP, où la technologie de base était limitée aux directives include. Chaque page dupliquait la structure :

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<!DOCTYPE html>
<html>
<head>
   <c:import url="header.jsp" />
</head>
<body>
   <%@include file="body.jsp"%>
</body>
<footer>
   <jsp:include page="footer.jsp" />
</footer>
</html>

Le refactoring est devenu un cauchemar. Tiles est également mort, aggravant les problèmes.

Dépôt et commits : 14 ans dans un seul dépôt GitHub

Le développement sur le temps libre a conduit à des commits moins qu'idéaux. Le code dans les versions récentes est nettoyé, et le projet est stable. L'accès public simplifie les forks et contributions.

Principaux enseignements

  • Le support du projet est plus important que le développement : les technologies deviennent obsolètes plus vite que les attentes.
  • Choisir une pile basée sur la disponibilité fonctionne mais nécessite des tests de compatibilité (Scala + Spring/Hibernate).
  • Les frameworks morts (Compass, Tiles) vous entraînent vers le bas : surveillez les feuilles de route.
  • Maven reste la référence en matière de stabilité pour les projets legacy.
  • Les données utilisateur sont critiques même pour les outils temporaires.

Globalement, le projet illustre la réalité du développement d'entreprise—90 % des efforts vont à la maintenance.

— Editorial Team

Advertisement 728x90

Lire ensuite