14 lat wsparcia wewnętrznego pastbinu: lekcje ewolucji stosu technologicznego
Wewnętrzne narzędzie do udostępniania kodu i logów, analogiczne do Pastebin, uruchomione w 2012 roku, przetrwało 14 lat. Początkowo — prosta forma internetowa do zapisywania "past" z generowaniem linków i automatycznym usuwaniem przestarzałych wpisów. Później dodano podświetlanie składni, komentarze wiersz po wierszu, autoryzację i rysowanie na tekście. Główna wartość — lokalne wdrożenie bez zewnętrznych usług.
Projekt nie rościł sobie prawa do unikalności: podobne rozwiązania łatwo odtworzyć. Kluczowe wyzwanie — nie stworzenie, ale wsparcie na dłuższą metę, gdzie technologie się starzeją, frameworki umierają, a oczekiwania użytkowników rosną.
Stos technologiczny: Scala w połączeniu z Spring i Hibernate
Wybór stosu zależał od dostępności i zainteresowania: Scala zamiast Java na klasycznym Spring-Hibernate-JSP. Scala 2.x kompilowała się do bajtkodu JVM, ale integracja ujawniła problemy z kompatybilnością.
- Adnotacje i skanery klas: Spring i Hibernate niepoprawnie przetwarzały bajtkod Scali. Przykład problemu z polami Entity:
@ManyToOne(fetch = FetchType.EAGER, cascade = Array(CascadeType.PERSIST, CascadeType.MERGE))
@JoinColumn(name = "owner_id")
private var owner: User = nullPola wymagały jawnych wartości domyślnych.
- Typy danych, dziedziczenie, enum i adnotacje: Pełny zakres niezgodności, rozwiązanych metodą prób i błędów.
Rezygnacja z NoSQL i przechowywania w plikach: utrata danych przy restarcie była niedopuszczalna. Lucene do indeksowania powodował duplikaty przy aktualizacjach.
Budowanie: Maven zamiast sbt
W 2012 sbt był niedojrzały, ze słabą integracją w IDE i CI. Maven zapewnił stabilność: wsparcie dla SonarQube, multi-DB, multi-serwlet-kontenerów.
Zalety Mavena na 14-letniej drodze:
- Przewidywalność wydań.
- Łatwa integracja z ekosystemem.
- Minimalne zmiany konfiguracji.
sbt ewoluował, ale migracja nie była potrzebna — Maven nie zawiódł.
Upadek Compass Search
Compass, przodek Elasticsearch, integrował się z Hibernate/Spring dla wbudowanego wyszukiwania. Do 2014 projekt umarł: autor przeszedł do rozproszonego ES.
Konsekwencje:
- Zależności od przestarzałych bibliotek łamały aktualizacje.
- Wsparcie martwej bazy kodu zajęło 5 lat.
- Migracja na Hibernate Search nie powiodła się za pierwszym razem.
Lekcja: monitorować aktywność projektów upstream.
Problemy Apache Tiles i szablonów JSP
Tiles dodawał kompozycję szablonów w JSP, gdzie podstawowa technologia ograniczała się do dyrektywy include. Każda strona powielała 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>Refaktoryzacja zamieniała się w koszmar. Tiles też umarł, pogłębiając problemy.
Repozytorium i commity: 14 lat w jednym repozytorium GitHub
Rozwój w wolnym czasie prowadził do niedoskonałych commitów. Kod najnowszych wersji został oczyszczony, projekt jest stabilny. Publiczny dostęp ułatwia forki i wkład.
Co jest ważne
- Wsparcie projektu ważniejsze niż rozwój: technologie starzeją się szybciej niż oczekiwania.
- Wybór stosu według dostępności działa, ale wymaga testów kompatybilności (Scala + Spring/Hibernate).
- Martwe frameworki (Compass, Tiles) ciągną w dół: monitorować roadmap.
- Maven pozostaje wzorem stabilności dla legacy-projektów.
- Dane użytkowników są krytyczne nawet dla tymczasowych narzędzi.
Ogólny przekaz: projekt ilustruje rzeczywistość enterprise-rozwoju — 90% wysiłku na utrzymanie.
— Editorial Team
Brak komentarzy.