Entwicklungsleitung
Bitrix-Entwicklung im Team: Code Reviews und Releases
Ein schlanker Ablauf von der verständlichen Aufgabe bis zum geprüften Release: Kontext, Review, Abnahme, Rückkehr zur vorherigen Version und Verantwortungsübergabe.
Prüfen Sie beim Code Review auch die ursprüngliche Aufgabe und das Ergebnis. Ein Diff, also die Übersicht der Codeänderungen, zeigt allein noch nicht, ob der Bedarf der Nutzer verstanden wurde und die Änderung sicher veröffentlicht werden kann.
Hier folgt ein empfohlener Mindestprozess für Teams, die bestehende Unternehmenswebsysteme weiterentwickeln. Er lässt sich schrittweise einführen, zunächst für ein Projekt oder einen Aufgabentyp.
Vor der Entwicklung: das Ergebnis beobachtbar machen
Eine Aufgabe braucht Nutzerablauf, erwartete Änderung und Abnahmekriterium. „Integration verbessern“ muss konkretisiert werden: Welcher Fehler tritt auf, wie lässt er sich reproduzieren und welches Ergebnis wird nach der Korrektur erwartet?
Klären Sie, wer Aufgaben priorisiert und wer das Ergebnis abnimmt. Das können unterschiedliche Personen sein. Entwickler sollten nicht bei jeder dringenden Anfrage erraten müssen, welche wichtiger ist.
Wenn das Verhalten der Plattform noch unklar ist, untersuchen Sie zunächst einen begrenzten Bereich. Die Untersuchung soll eine konkrete Frage beantworten. Danach können Sie den Aufwand für die Umsetzung schätzen.
Änderungen müssen überschaubar bleiben
Wenn eine Änderung zugleich einen Fehler korrigiert, viel Code neu formatiert und benachbarte Architektur umbaut, wird das Review schwieriger. Begrenzen Sie die Änderung auf ein verständliches Ziel und die dafür notwendigen Begleitarbeiten.
Eine Merge-Request-Beschreibung sollte festhalten:
- Welches Problem die Änderung löst.
- Was sich für Nutzer ändert.
- Welche Komponenten und Daten betroffen sind.
- Wie das Ergebnis geprüft wurde.
- Was für Release und Rückkehr zur vorherigen Version erforderlich ist.
Das spart dem nächsten Entwickler Zeit, wenn er die Lösung Monate später nachvollziehen muss. Der Aufgabenlink sollte erhalten bleiben, ersetzt aber keine kurze Erklärung direkt an der Änderung.
Fragen für das Review
| Frage | Welches Problem sichtbar wird |
|---|---|
| Entspricht das Verhalten der Aufgabe? | Technisch richtige Lösung des falschen Problems |
| Werden Rechte serverseitig geprüft? | Direkter Zugriff unter Umgehung der Oberfläche |
| Was geschieht bei Wiederholung oder Fehler? | Duplikate, Teilausführung und Datenverlust |
| Welche Plattformabhängigkeiten werden genutzt? | Fragile Bindung an eine bestimmte Version |
| Ist die Änderung separat prüfbar und veröffentlichbar? | Versteckte Release-Abhängigkeiten |
| Versteht ein anderer Entwickler die Lösung? | Kontextverlust bei Übergabe der Wartung |
Erklären Sie im Kommentar die Folge eines Problems. „Nach einem Timeout ist hier ein erneuter externer Aufruf möglich“ hilft mehr als eine unbegründete Forderung, Code umzuschreiben. Trennen Sie persönliche Stilvorlieben von Fehlern im Verhalten.
Review, Tests und Abnahme ergänzen sich
Reviewer lesen die Lösung und stellen Fragen. Prüfungen zeigen das Verhalten unter gewählten Bedingungen. Die fachlich verantwortliche Person bestätigt die Übereinstimmung mit dem Bedarf. Keiner dieser Schritte deckt die anderen vollständig ab.
Bei kleinen Anpassungen reichen möglicherweise wenige prüfbare Abläufe. Änderungen an Rechten, Datenaustausch oder Speicherstruktur benötigen Fehler- und Regressionsprüfungen. Die Prüftiefe sollte dem Risiko entsprechen.
Bei Bitrix ist es hilfreich, die Versionen betroffener Module festzuhalten. Eine erfolgreiche Prüfung auf einem anderen Portal mit anderen Modulversionen beweist keine Kompatibilität mit der Zielumgebung.
Release und Rückmeldung
Legen Sie vor dem Release fest, wer es ausführt, in welcher Reihenfolge die Schritte ablaufen und wie das Ergebnis kurz geprüft wird. Wenn die Änderung Daten betrifft, muss der Plan zur Wiederherstellung auch deren Zustand berücksichtigen. Alte Dateien allein genügen dafür nicht.
Nach dem Release muss sichtbar werden, was sich geändert hat: für Prozessverantwortliche das Verhalten, für betreuende Fachkräfte Einstellungen und Diagnose. Rückmeldungen können statt eines Codefehlers einen fehlenden Teil des ursprünglichen Ablaufs offenlegen.
Vereinbaren Sie, was der Status „fertig“ bedeutet. Zum Beispiel: Code angenommen, Prüfungen abgeschlossen, Änderung veröffentlicht und Ergebnis bestätigt. Wenn diese Schritte zu unterschiedlichen Zeiten erfolgen, zeigen Sie das in der Aufgabe.
Was der Teamleiter tun kann
Beginnen Sie mit einer klaren Vereinbarung: Jede wesentliche Änderung enthält Ziel, Prüfnachweis und Release-Beschreibung. Betrachten Sie anschließend die tatsächlichen Schwierigkeiten des Teams und passen Sie den Ablauf daran an.
Die Zahl abgeschlossener Aufgaben oder Review-Kommentare zeigt die Qualität allein noch nicht. Besprechen Sie, welche Zusagen erfüllt wurden, was Ergebnisse blockiert und welche Informationen oder Befugnisse fehlen.
Dokumentation
Merge Requests in GitLab unterstützen gemeinsame Änderungsdiskussionen, Reviews und die Verknüpfung mit Prüfungen. Konkrete Teamregeln müssen separat festgelegt werden; das Werkzeug allein definiert keinen Prozess.