Java- und Eclipse-Modernisierung, beschleunigt durch KI, mit festem Umfang.

3 bis 5 TageJava · Eclipse

Toten Code entfernen

Nicht erreichbare Klassen, ungenutzte Konstanten, verwaiste Member und hängengebliebene Importe: vom Agenten gefunden und vom Compiler und Suchindex Ihrer eigenen IDE als tot nachgewiesen, bevor eine einzige Zeile verschwindet.

Trockenlauf auf eclipse.platform.ui: 3.692 Zeilen aus 148 Dateien entfernt, null Compile-Fehler. 38 Klassen, 49 Konstantengruppen, 3 private Member, 107 Importe, über sechs Runden. Das Sicherheitsnetz hielt Dutzende Klassen zurück, die aus anderen Repositories genutzt werden, dazu eine Klasse, die nur aus der plugin.xml eines anderen Plug-ins referenziert wird, und e4-Addons, die ausschließlich in .e4xmi-Dateien registriert sind.

VoraussetzungDie Projekte lassen sich in die Eclipse IDE importieren, denn der Nachweis läuft über deren Compiler und Suchindex.

Das bekommen SieEine bereinigte Codebasis, in Etappen nach Git committet, ein ausführlicher Bericht zu jeder Löschung samt Beleg und eine Liste möglicher Folgeschritte für Ihr Team.

5 TageJava

Library-Abhängigkeiten und Java-Version anheben

Der Weg von Java 8, 11 oder 17 auf Java 21 oder 25, zusammen mit den Bibliotheken, die dabei mitziehen müssen, mit grünem Build und laufender Testsuite nach jedem Schritt statt einem großen Sprung am Ende.

VoraussetzungDie Testsuite läuft heute grün, sonst fehlt der Vergleichspunkt.

Das bekommen SieEin Repository, das auf der neuen Java-Version und auf aktuellen Bibliotheksversionen baut und testet, mit angepasster Toolchain und CI, jeder erzwungenen Änderung erklärt in ihrem Commit und einer Liste der Stellen, die wir nur mechanisch angepasst haben und die Ihr Team später inhaltlich anfassen sollte.

5 TageJava

Tests stabilisieren, Abdeckung wo sie zählt

Abdeckung auf dem Code, den Sie als Nächstes ändern, nicht ein Durchschnitt über das Repository. Zuerst Charakterisierungstests, damit das heutige Verhalten festgenagelt ist, bevor jemand es anfasst.

Das bekommen SieReviewte Tests in Ihrem Repository, eine Coverage-Baseline mit Delta, ein Mutationsscore, der zeigt dass die Tests wirklich etwas prüfen, und die ungesicherten Bereiche, nach Risiko sortiert.

5 TageJava

Performance- und Speicheroptimierung

Messen statt raten. Profiling unter realer Last, die teuersten Fundstellen zuerst, und jede Änderung mit einer Vorher-Nachher-Zahl belegt.

VoraussetzungEin reproduzierbarer Lastfall oder eine repräsentative Arbeitslast, die wir fahren können.

Das bekommen SieEin Messprotokoll mit Vorher-Nachher-Zahlen, die Commits hinter jeder belegten Optimierung, einen Benchmark, der im Repository bleibt, damit Sie die Werte selbst reproduzieren, und die gemessenen, aber noch nicht umgesetzten Optimierungen, nach Aufwand und erwartetem Gewinn sortiert.

5 bis 10 TageEclipse RCP

Eclipse-RCP-Anwendung auf das aktuelle Release heben

Eine Eclipse-RCP-Anwendung auf das aktuelle Eclipse-Release und eine aktuelle Java-Version bringen, in Wellen, mit einer startbaren Anwendung nach jeder einzelnen Welle.

VoraussetzungEine Target Platform und ein Tycho-Build, den wir ausführen können.

Das bekommen SieEin Produkt, das auf aktuellem Eclipse und Java baut, startet und seine Tests besteht, mit jedem API-Ersatz dokumentiert in seinem Commit und den kompatibel überbrückten APIs samt sauberem Ersatz für später.

5 bis 10 TageEclipse RCP

Von Eclipse 3 auf Eclipse 4

Eine Eclipse-3-Anwendung auf das Eclipse-4-Anwendungsmodell und Dependency Injection bringen, schrittweise, während der Kompatibilitätslayer trägt was noch nicht umgezogen ist.

VoraussetzungEine Target Platform und ein Tycho-Build, den wir ausführen können.

Das bekommen SieEine Anwendung auf dem e4-Modell, mit dokumentiertem Migrationspfad für die Teile, die wir bewusst auf dem Kompatibilitätslayer belassen haben.

2 bis 3 TageBeliebiger Stack

KI-Code-Review einführen

Ein Review-Agent auf Ihren Pull Requests, der Ihre Hausregeln aus Ihrer eigenen Review-Historie gelernt hat, so lange nachjustiert bis seine Befunde lesenswert sind.

VoraussetzungEine CI mit Pull Requests, GitHub oder GitLab, und das Recht, einen Bot einzurichten.

Das bekommen SieEinen Review-Agenten in Ihrer CI, seine Regeln im Repository eingecheckt, eine schriftliche Team-Konvention darüber, was er blockieren darf, und die Regeln, die wir bewusst nicht scharf geschaltet haben, mit Begründung.

3 bis 5 TageBeliebiger Stack

Eigene Agenten-Skills und MCP-Integrationen

Die Abläufe, die Ihr Team ständig von Hand wiederholt, werden zu Agenten-Skills, und über MCP hängt der Agent an Ihren internen Werkzeugen, arbeitet also mit Ihren Systemen statt an ihnen vorbei.

VoraussetzungEin Agenten-Client, der im Team bereits im Einsatz ist.

Das bekommen SieSkills und MCP-Integrationen in Ihrem Repository, samt den Kontextdateien und Prompts, die sie funktionieren lassen, und den Abläufen, die sich als Nächstes lohnen, nach Aufwand sortiert.