Was ist die Qualität einer Software? Wie kann man sie messen und wie dann auch noch managen? Die Antworten auf diese Fragen sind so unterschiedlich wie die Menschen, die man fragt. Wir bei BRICKMAKERS haben dennoch Antworten gefunden, die alle Projektbeteiligten abholen. In diesem Artikel möchten wir sie mit Euch teilen.
Qualitätsmanagement Workflows
Der primär bei BRICKMAKERS eingesetzte Entwicklungs- und Projektmanagement-Workflow ist das SCRUM-Framework. SCRUM ist ein agiles Vorgehen, das die Nutzenden ins Zentrum stellt. Hierzu werden Anforderungen an die Software in Form von User-Stories gestellt. Der innerhalb unseres Unternehmens verwendete SCRUM-Workflow erzwingt Reviews von User-Stories durch eine zweite Person noch während der Entwicklung. Ein „Vier-Augen-Check“ ist damit in unserem Workflow eingebaut.
Beim Review einer User-Story wird diese mit einer „Definition of Done“ verglichen. Nur wenn alle Kriterien der „Definition of Done“ erfüllt sind, ist die Story fertig. Die Kriterien werden von allen Teams selbst definiert und enthalten neben dem Erfüllen der eigentlichen User-Story mindestens auch ein Code Review, sowie automatisierte Tests des Quellcodes. Weitere Kriterien werden je nach Projekt ergänzt.
Eine Anwendung wird nur dann ausgeliefert, wenn alle automatischen sowie abschließenden, manuellen Tests durch ein Test-Team erfolgreich durchlaufen wurden.
Die Verkettung von Code-Reviews während der Entwicklung, automatisierten Tests sowie manuellen Tests durch ein Test-Team ergeben zusammen ein engmaschiges Sicherheitsnetz. Dadurch bleiben wir agil und können flexibel auf neue Anforderungen reagieren.
Codequalität
Wir entwickeln nach den Clean Code Regeln und setzen Linter (z.B. Resharper) zur statischen Code Analyse ein. Hiermit wird eine gleichbleibende, saubere Code-Struktur erreicht. Das erleichtert Code-Reviews und den Neueinstieg für Entwickler. So wird z.B. durch den Einsatz von Inversion of Control und Dependency Injection eine lose Kopplung von Modulen erreicht.
Um die Funktionalität des Codes zu sichern, wird Test Driven Development (TDD) eingesetzt. Hierbei wird zunächst ein Test zur Überprüfung eines neuen Moduls oder einer neuen Methode geschrieben. Dieser Test kann und darf im ersten Schritt nicht erfüllt werden. Erst im Anschluss wird der bereits vorhandene Code soweit ergänzt, dass die neue Funktionalität erfüllt wird. Hierbei wird nur so viel Code geschrieben wie unbedingt nötig.
Durch die konsequente Durchführung von TDD wird sichergestellt, dass erstens nur Funktionalität implementiert wird, die auch wirklich gebraucht wird, und zweitens, dass diese durch Tests abgedeckt ist. Weiterhin erschafft man so ein „Sicherheitsnetz“ welches es erlaubt, notwendige Refactorings ohne großes Risiko durchzuführen.
Übrigens: Wir sind uns bei der Codequalität so sicher, dass wir unseren Kunden den Code immer zur Verfügung stellen.
Dokumentationsqualität
Die für ein Projekt verwendeten Technologien und Frameworks sowie relevante Information, z.B. zum Projekt-Setup, werden bei BRICKMAKERS in einem Wiki festgehalten, das allen beteiligten Entwickelnden zum Lesen und Bearbeiten zur Verfügung steht.
Die Clean Code Regeln sehen sogenannten “sich selbst dokumentierenden” Quellcode vor. Das heißt, dass durch die präzise, konsistente und logische Benennung von Variablen, Methoden und Klassen Code entsteht, der selbsterklärend ist. Durch die Vorgabe, Methoden und Klassen so kurz wie möglich zu halten, wird die Übersichtlichkeit und Wartbarkeit des Codes weiter erhöht.
Für Frameworks/Libraries, bei denen für die implementierenden Entwickelnden der Quellcode oft nicht einsehbar ist — oder auf Kundenwunsch — setzen wir in der Regel auf Header Doc Kommentare über Klassen und Methoden. Hier werden die für die eingesetzte Programmiersprache üblichen Formatierungen genutzt (z.B. C# XML Code Kommentare, Swift Documentation Comments oder JavaDoc). Dies lässt die Möglichkeit offen, Quellcode Dokumentation bei Bedarf unabhängig vom Quellcode, z. B. als Webseite zu verteilen. Die Erstellung der Dokumentation wird in diesem Fall mit Tools automatisiert.
Unit Tests
Unit Tests sind für alle Projekte bei BRICKMAKERS verpflichtend. Da nach dem Test Driven Development Schema entwickelt wird, werden alle testbaren Code-Teile mit Unit-Tests abgedeckt. Die Abdeckung wird regelmäßig mit Tools (wie z.B. DotCover) geprüft. Lediglich Code, der nicht sinnvoll Unit-Testbar ist, wird nicht von Unit-Tests abgedeckt. In diese Kategorie fallen zum Beispiel Views und Entities. Für Views sind manuelle oder UI-Tests wesentlich sinnvoller und werden vor allem bei komplexen Multi-Device-Szenarien eingesetzt.
Manuelle Tests
Jedes Feature, das in die Produktionsphase geht, wird durch einen nicht an der Erstellung des Codes beteiligten Entwickelnden getestet. Zusätzlich können dedizierte Softwaretester:innen für Integrationstests bereitgestellt werden.
Profiling
Zum Profiling von performance-relevanten Teilen von Anwendungen werden, je nach verwendeter Sprache, Tools wie z.B. DotTrace für Code oder SQL Server Profiler für Datenbanken eingesetzt.
Code-Reviews/Pairprogramming
Pairprogramming wird vor allem dann eingesetzt, wenn neue Mitarbeitenden in ein Projekt eingearbeitet werden oder besonders komplexe Probleme zu lösen sind. Die Entwicklungsteams organisieren Pairprogramming-Sessions selbstständig bei Bedarf.
Continuous Integration
Bei unseren Projekten werden CI Systeme, wie z.B. Travis oder visualstudio.com Continuous Integration von Microsoft, eingesetzt. Diese Tools automatisieren unter anderem die Ausführung von Unit-Tests, UI-Tests und Linter-Tests. Schlagen diese Tests fehl, wird ein Build nicht in den Produktivbetrieb zugelassen.
Fazit
Qualität in Softwareprojekten betrifft nicht nur den Quellcode, sondern vielmehr den kompletten Prozess von der Anforderungsanalyse über Konzeption, Entwicklung und Deployment bis letztendlich zu Wartung und Pflege. Neben den Dingen die zur Sicherstellung einer gleichbleibend hohen Qualität getan werden sollen gibt es mindestens genauso viele Punkte, deren Vermeidung die Qualität steigert.
Wir bei BRICKMAKERS sehen es daher als unsere Aufgabe unsere Prozesse und Standards ständig weiter zu entwickeln, um stetig noch bessere Software liefern zu können.
