Den meisten Organisationen ist klar, dass Application Code Review (ACR), also die Überprüfung des Anwendungscodes, unerlässlich ist, um die Qualität der von ihnen entwickelten Anwendungen zu halten. Organisationen wollen heutzutage Anwendungen immer schneller bauen, bereitstellen und updaten können. Daher ist das eigentliche Problem, die notwendige Zeit für die Durchführung dieser Reviews zu finden.
Natürlich gibt es einige sehr gute Gründe für eine genaue Überprüfung des Anwendungscodes. Der erste ist, dass so Fehler so früh wie möglich entdeckt werden können. Dadurch wird ihr Effekt sowohl auf die Anwendung selbst minimiert als auch auf externe Codeabschnitte, die möglicherweise auf dem beim Review entdeckten fehlerhaften Code aufbauen.
Um den ACR-Prozess zu vereinfachen, müssen sich Reviewer natürlich erst mit der Funktion vertraut machen, die sie überprüfen sollen. Einheitliche Programmierregeln mit gemeinsamen Namenskonventionen und Codierungsstrukturen machen es nicht nur zu diesem Zeitpunkt einfacher, die Struktur des Codes zu verstehen, sondern auch z. B. sechs Monate später, wenn Entwickler oder Tester den Code eventuell noch einmal überarbeiten müssen.
Letztendlich dient ACR zwei höherrangigen Zielen. Erstens gibt es dem Team das Gefühl, dass es gemeinsam für den zu entwickelnden Code verantwortlich ist. Zweitens eröffnet ACR eine unschätzbare Gelegenheit: Entwickler und Tester können so lernen, wie sieimmer die bestmögliche Nutzungsqualität der Anwendung sicherstellen können.
Die Herausforderung beim Code-Review
In Organisationen, die bei der Anwendungsentwicklung und bei Updates viel Wert auf Geschwindigkeit legen, kann es schwierig sein, die Qualität der Anwendungen zu halten. Es kann viel Mühe und Zeit kosten, die Anwendungsqualität sicherzustellen. Oft stellt sich aber erst über einen längeren Zeitraum hinweg heraus, dass diese Mühe sich lohnt. Code-Reviews können sogar dafür sorgen, dass für andere Aufgaben zunächst weniger Zeit bleibt, z. B. für die Erstellung zusätzlicher User Stories für Tests.
Im Bereich ACR müssen außerdem oft noch andere große Herausforderungen gemeistert werden:
- Langfristige Konsistenz ist schwer zu erreichen, besonders wenn Reviews von mehreren Personen durchgeführt werden.
- Eine positive Einstellung beizubehalten kann eine Herausforderung darstellen, besonders wenn Reviewer immer wieder auf die gleichen Probleme stoßen.
- Entwickler und Tester ziehen sich nur ungern aus einem aktuellen Programmierprozess zurück, um sich Zeit für die Überprüfung einer bestehenden Anwendung zu nehmen.
- Man vergisst leicht, dass Menschen keine Maschinen sind. Es kommt durchaus vor, dass Reviews wiederholt werden müssen, um sicherzustellen, dass keine zusätzlichen Änderungen nötig sind.
Code-Reviews automatisieren
Viele Teile des Code-Review-Prozesses können problemlos automatisiert werden. Die Überprüfung der Einhaltung von Namenskonventionen, Projekteinstellungen, der Größe des Codes und der Komplexität und Anzahl der Programmierregeln – all diese Aufgaben sollten automatisiert sein. Wie wir immer sagen: Wenn es automatisiert werden kann, sollte es automatisiert werden!
Der größte Vorteil: Entwickler können sogar dem ganzen Team Zeit sparen, indem sie die meisten automatisierten Tests selbst durchführen. Dadurch können sich Reviewer auf die wirklich wichtigen und komplexen Probleme konzentrieren.
Die Vorteile des Code-Review-Prozesses
Wird der ACR-Prozess ausgelassen, so bedeutet das im Grunde, dass Code erstellt und bereitgestellt wird, der nicht nur schwierig zu pflegen ist, sondern der auch schnell zu „Spaghetticode“ wird. Schon nach ein paar Sprints wird das Entwicklungsteam merken, dass es die Konsequenzen von fehlenden Regressionstests, schlechten Design-Entscheidungen und fehlerhaftem Code tragen muss.
Bei jeder User Story muss Zeit für die nötigen Qualitätskontrollen eingerechnet werden, die Teil der Fertigstellungskriterien einer User Story sein sollten. Sowohl der Reviewer als auch der Entwickler des ursprünglichen Codes haben eine gemeinsame Verantwortung für abgeschlossene User Stories. Wenn der ursprüngliche Entwickler nicht verfügbar ist, sollte der Reviewer von ihm übernehmen können, um den Code weiterzuführen, zu verbessern oder zu ändern.
Der erfahrenste Entwickler im Team sollte die Rolle des Softwarearchitekten, des Code-Reviewers, des Coaches und des Trainers übernehmen. Diese Person sollte in die komplette Codeentwicklung eingebunden sein, um so das Team auf ein höheres Niveau zu bringen. Natürlich muss diese Person in das Schreiben des Codes involviert sein. Allerdings kann die Gesamteffizienz des Teams und die Qualität des entwickelten Codes effektiver verbessert werden, indem dieser Person keine User Stories zugewiesen werden oder indem bestimmte Zuständigkeiten zur Verringerung des Overheads auf andere übertragen werden.
Der Application Code Reviewer (ACR) von Mansystems für Mendix
Das Application-Code-Review-Tool (ACR) von Mansystems für Mendix automatisiert Code-Reviews von Regeln und Namenskonventionen. Es ruft das Mendix Model über das Mendix Model SDK auf, um den Code zu überprüfen. Tests können entweder manuell durch den Entwickler oder automatisch bei jedem Commit ausgeführt werden. Automatisierbare ACR-Prozesse umfassen:
• Performance
• Sicherheit
• Wartbarkeit
• Zuverlässigkeit
• Architektur
• Projektpflege
Für jede dieser Kategorien hat Mansystems Regeln erstellt:
Ein Beispiel für eine Performance-Regel ist, dass zeitaufwändige Aktionen nicht innerhalb einer Schleife verwendet werden. Commits in die Datenbank werden am besten außerhalb einer Schleife durchgeführt.
Ein Beispiel für eine Sicherheitsregel ist die Überprüfung, ob alle Einheiten über XPath-Regeln für jede Rolle verfügen, die mandantenfähige Sicherheitsmaßnahmen erfordert.
- Beispiele für Zuverlässigkeitsregeln sind Überprüfungen auf Timeouts bei REST/Web-Services-Aufrufen und benutzerdefinierte Fehlerbehandlungsroutinen. Eine andere Regel erfordert, dass eine benutzerdefinierte Fehlerbehandlungsroutine eine Protokollzeile erstellt.
- Wartbarkeitsregeln umfassen die Überprüfung von Namenskonventionen und ob Einheiten oder Microflows einer bestimmten Größe dokumentiert sind.
- Zu den Architekturregeln gehören Überprüfungen auf modulübergreifende Zuordnungen und Aufrufe zur Unterstützung von „sauberem Design“.
- Projektpflegeregeln überprüfen die Projektsicherheit auf Basis der Einstellungen in einer Produktionsumgebung, unter anderem indem Benutzer mit Administratorrechten umbenannt werden müssen.
Mansystems wird in Zukunft noch sehr viele weitere Regeln erstellen.
Auf Ihre Bedürfnisse anpassbar
Über Programmierregeln lässt sich immer streiten. Darum haben wir bei Mansystems beschlossen, die Anpassung dieser Regeln zu ermöglichen. Sie können Regeln für jedes Projekt ein- oder ausschalten. Sie können Limits setzen. Sie können ändern, wie streng eine Regel angewendet wird.
Regeln sollten Organisationen helfen und sie nicht dazu zwingen, schlechten Code zu schreiben, um eine automatisierte Regelverletzung zu umgehen. Wenn beispielsweise ein Microflow gegen eine Regel verstößt, sich aber alle einig sind, dass das Ignorieren dieser Regel das Beste wäre, kann der Microflow zu einer Whitelist hinzugefügt werden.
Self-Service
Das ACR-Tool ist auch in die CI/CD-Plattform (Continuous Integration/Continuous Development) integriert, die Mansystems als Teil der SMART Digital Factory anbietet. Der automatisierte Code-Review kann bei einem Commit oder täglich durchgeführt werden. So wird automatisiertes Testen nicht nur direkt für den Entwickler verfügbar, die Feedbackschleife wird dadurch auch enger.
Entwickler können mit dem automatisierten Code-Review ihre Arbeit schon frühzeitig überprüfen und Regelverstöße beheben, bevor ein anderer Entwickler einen Peer-Review ihres Codes durchführt. Diese Herangehensweise spart nicht nur Zeit, durch sie wird der Peer-Review auch zu einer Gelegenheit, wirklich etwas zu lernen, und ist nicht mehr nur einfach ein weiterer Kontroll- und Prüfprozess.
Application Quality Monitor
Die über die SMART Digital Factory angebotenen automatisierten ACR-Funktionen wurden entwickelt, um gute Programmiergewohnheiten zu fördern, indem sie direkten Zugang zu Feedback ermöglichen. Ohne diesen Automatisierungsgrad erinnern sich die meisten Entwickler nicht einmal daran, wie und wann sie einen bestimmten Codeabschnitt geschrieben haben. Sie sind schon ganz bei ihrem nächsten Projekt.
Ein ergänzendes AQM-Tool von Mendix ermöglicht einen ganzheitlichen Ansatz für die Anwendung. Hierbei werden z. B. Eigenschaften wie die Wartbarkeit von komplexem Code bewertet. Das AQM-Tool überwacht die Qualität auf Grundlage der Norm ISO 25010.
ACR richtet sich im Grunde an die Entwickler, während AQM sich ans Management wendet. Durch das Beheben von ACR-Verstößen sollten sich die AQM-Werte verbessern. Zusammen bieten ACR und AQM einen Mehrwert, der weit über die Summe ihrer Einzelbeiträge hinausgeht.
Fazit
Man sollte immer mit gesundem Menschenverstand an die Automatisierung des ACR herangehen. Code-Reviews sollen dazu dienen, die Nutzungsqualität der Anwendung zu verbessern, und nicht nur verhindern, dass schlechte Gewohnheiten einen Alarm auslösen. Ich habe schon erlebt, dass Entwickler Code geändert haben, um eine bessere Bewertung zu erreichen, obwohl sie den Code dadurch meiner Meinung nach verschlechtert haben.
Es ist vielleicht keine gute Idee, einen großen Microflow einfach nur aufzuteilen, weil ein Code-Review-Tool sagt, dass er groß ist. Die Automatisierung des ACR ist ein Mittel, um besseren Code zu schreiben. Wenn das Tool dem Erreichen dieses Ziels im Weg steht, ignorieren Sie es einfach!
