14 Jahre interner Pastebin-Support: Lehren aus der Stack-Entwicklung
Ein internes Tool zum Teilen von Code und Logs, ähnlich wie Pastebin, wurde 2012 gestartet und hielt 14 Jahre durch. Ursprünglich war es ein einfaches Webformular zum Speichern von "Pastes" mit Link-Generierung und automatischer Löschung veralteter Einträge. Später fügten wir Syntax-Highlighting, zeilenweise Kommentare, Autorisierung und das Zeichnen über Text hinzu. Der Hauptvorteil war die lokale Bereitstellung ohne externe Dienste.
Das Projekt beanspruchte nicht, einzigartig zu sein: Solche Lösungen sind leicht reproduzierbar. Die größte Herausforderung war nicht die Erstellung, sondern die langfristige Unterstützung, bei der Technologien veralten, Frameworks sterben und die Erwartungen der Nutzer wachsen.
Technologie-Stack: Scala gepaart mit Spring und Hibernate
Die Wahl des Stacks wurde durch Verfügbarkeit und Interesse bestimmt: Scala statt Java auf einem klassischen Spring-Hibernate-JSP-Setup. Scala 2.x wurde in JVM-Bytecode kompiliert, aber die Integration offenbarte Kompatibilitätsprobleme.
- Annotationen und Class-Scanner: Spring und Hibernate verarbeiteten Scala-Bytecode falsch. Beispielproblem mit Entity-Feldern:
@ManyToOne(fetch = FetchType.EAGER, cascade = Array(CascadeType.PERSIST, CascadeType.MERGE))
@JoinColumn(name = "owner_id")
private var owner: User = nullFelder benötigten explizite Standardwerte.
- Datentypen, Vererbung, Enums und Annotationen: Eine ganze Reihe von Inkompatibilitäten, die durch Versuch und Irrtum gelöst wurden.
Wir vermieden NoSQL und Dateispeicherung: Datenverlust beim Neustart war inakzeptabel. Lucene für die Indizierung verursachte Duplikate bei Updates.
Build-System: Maven statt sbt
Im Jahr 2012 war sbt roh, mit schlechter IDE- und CI-Integration. Maven bot Stabilität: Unterstützung für SonarQube, mehrere Datenbanken und mehrere Servlet-Container.
Vorteile von Maven über 14 Jahre hinweg:
- Vorhersehbare Releases.
- Einfache Integration in das Ökosystem.
- Minimale Konfigurationsänderungen.
sbt entwickelte sich weiter, aber eine Migration war nicht nötig – Maven ließ uns nie im Stich.
Das Ende von Compass Search
Compass, der Vorgänger von Elasticsearch, integrierte sich in Hibernate/Spring für eingebettete Suche. Bis 2014 starb das Projekt: Der Autor wechselte zu verteiltem ES.
Konsequenzen:
- Abhängigkeiten von veralteten Bibliotheken brachen Updates.
- Die Unterstützung von totem Code dauerte 5 Jahre.
- Die Migration zu Hibernate Search gelang nicht beim ersten Versuch.
Lehre: Überwachen Sie die Aktivität von Upstream-Projekten.
Probleme mit Apache Tiles und JSP-Templates
Tiles fügte JSP Template-Komposition hinzu, wo die Basistechnologie auf Include-Direktiven beschränkt war. Jede Seite duplizierte die Struktur:
<%@ 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>Refactoring wurde zum Albtraum. Tiles starb ebenfalls, was die Probleme verschlimmerte.
Repository und Commits: 14 Jahre in einem GitHub-Repo
Entwicklung in der Freizeit führte zu weniger als idealen Commits. Der Code in neueren Versionen ist bereinigt, und das Projekt ist stabil. Öffentlicher Zugang vereinfacht Forks und Beiträge.
Wichtigste Erkenntnisse
- Projektunterstützung ist wichtiger als Entwicklung: Technologien veralten schneller als Erwartungen.
- Die Wahl eines Stacks basierend auf Verfügbarkeit funktioniert, erfordert aber Kompatibilitätstests (Scala + Spring/Hibernate).
- Tote Frameworks (Compass, Tiles) ziehen Sie runter: Überwachen Sie Roadmaps.
- Maven bleibt der Goldstandard für Stabilität in Legacy-Projekten.
- Nutzerdaten sind kritisch, selbst für temporäre Tools.
Insgesamt illustriert das Projekt die Realität der Unternehmensentwicklung – 90 % des Aufwands gehen in die Wartung.
— Editorial Team
Noch keine Kommentare.