Teilen
Inhaltsverzeichnis
- Wie SonarQube nicht zu verwenden ist
- Die goldene Regel der Nutzung von SonarQube
- Damit SonarQube für das Team funktioniert
- Mit Hilfe von SonarQube Spitzenleistungen erzielen
- Auswirkungen auf die Produktivität
- Zusammenfassung
Eine effiziente Softwarebereitstellung ist mehr als nur die schnelle Auslieferung einer Lösung an den Kunden. Es stellt auch sicher, dass Sie die richtige Lösung anbieten, sowohl in Bezug auf die Gesamtqualität als auch auf die Geschäftsanforderungen. Qualitätskontrolle ist ein unverzichtbarer Bestandteil des Prozesses - Software sollte ständig validiert, verifiziert und getestet werden. Durch die Einführung der DevOps-Tools und -Mentalität kann die allgemeine Qualität der Lösung verbessert und die Lieferzeit verkürzt werden.
Aber selbst bei einem ausgefeilten Ansatz ist es wichtig, sich daran zu erinnern, dass der Code immer die Grundlage der Software ist. Deshalb ist es wichtig ihn sauber, fein abgestimmt und frei von potenziellen Schwachstellen zu halten. Die meisten Probleme in Bezug auf Sicherheit, Leistung und Erweiterbarkeit werden während des Implementierungsprozesses oder später während der Codeüberprüfung festgestellt, wobei wir uns ausschließlich auf die Erfahrung unserer Entwickler verlassen. Aufgrund der Komplexität moderner Software bleiben einige Sicherheitslücken jedoch auch nach umfangreichen Tests unentdeckt. Sie können sich dann erst lange nach der Bereitstellung zeigen.
Einer der empfohlenen Ansätze, welchen wir bei Objectivity praktizieren, besteht darin diese Probleme zu mindern, indem unsere Codebasis sauber und frei von Design- und Sicherheitsproblemen gehalten wird. Sie können dies erreichen, indem Sie eine statische Code-Analyse verwenden, welche, wie der Name schon sagt, den Code nicht ausführen muss, um ihn zu verarbeiten. Bei Objectivity verwenden wir in unseren DevOps Services ein Tool, das diese Funktion zusammen mit einer umfangreichen Regelbasis bietet. Es passt zu unseren Praktiken und lässt sich leicht in unsere CI / CD-Pipelines integrieren. Wir haben uns für die Sonar Suite entschieden (SonarQube, SonarLint und SonarScanner). Aber reicht es aus, nur diese Tools zu implementieren, ein paar Qualitätsgatter einzurichten und sich strikt an die Ergebnisse der Analyse zu halten, um unser Team dann zu zwingen ihren Code blind zu „reparieren“? Nach unserer Erfahrung ist dies nicht der Fall. Nach einigen Lektionen haben wir einige nützliche Richtlinien für den effektiven und stressfreien Einsatz dieser Tools festgelegt. Dadurch konnten wir das Potenzial der Sonar-Suite maximieren, ohne dass unsere Entwickler sie leidenschaftlich verabscheuen mussten.
Wie SonarQube nicht zu verwenden ist
SonarQube ist ein großartiges Tool, welches unserem Team beim Schreiben von besserem Code helfen kann. Es hebt die problematischen Abschnitte hervor, liefert klare Erklärungen und schlägt sogar beispielhafte Lösungen vor, die auf ähnlichen Fällen basieren. Es werden auch viele Code-Metriken wie Komplexität, Duplikationen, alle Arten von Problemen sowie Testabdeckung erstellt. Darüber hinaus wird sogar versucht, die technische Schuld abzuschätzen, wobei der Zeit- und Arbeitsaufwand für die Behebung aller Wartbarkeitsprobleme vorausgesetzt wird. Wie bei jeder Art von Metriken üblich, liefern sie dem Team bei korrekter Verwendung und Interpretation hilfreiche Informationen über den aktuellen Zustand der Codebasis. Wenn sie jedoch als absoluter Indikator für die Codequalität oder noch schlimmer als KPI verwendet werden, kann dies negative Auswirkungen auf das gesamte Projekt haben.
Das übliche Setup für SonarQube in der CI / CD-Pipeline verwendet Quality Gates mit festgelegten Schwellenwerten für ausgewählte Metriken. Sie werden häufig vor Beginn der Implementierung oder nach der Entscheidung die statische Code-Analyse zu verwenden, mit dem Kunden konsultiert. Wenn eine der Anforderungen der Qualitätsgatter nicht erfüllt ist, wird der Rest des Prozesses blockiert. Auf den ersten Blick klingt es vernünftig. Schließlich ist es unser Ziel, die Codequalität sicherzustellen. Und das Unternehmen ist auch zufrieden - es sieht so aus, als ob es jetzt möglich ist, die gesamte technische Arbeit zu erkennen und zu messen.
Infolgedessen kann das Team keine neuen Funktionen veröffentlichen oder Integrationstests durchführen, es sei denn, der Code entspricht den durch die Ergebnisse der Analyse auferlegten Standards. Es verhindert auch, dass das Team bewusste Entscheidungen über die technische Schuld trifft. Dies macht die Arbeit mit dem Legacy-Code, der nur selten von Tests abgedeckt wird, noch schwieriger. Manchmal sind die Entwickler gezwungen, SonarQube zu umgehen, indem sie Änderungen am Code verbergen, indem sie verschiedene Arten von „Hacks“ verwenden. Dies ist das Gegenteil von der Vermeidung technischer Probleme. Die einzige Möglichkeit die Arbeit fortzusetzen, besteht darin, ständig zu verhandeln, die Anforderungen an die Quality Gates aufzulockern, indem einige der Regeln außer Kraft gesetzt werden. Das Team hat das Gefühl, seine Autonomie zu verlieren. Im Gegenzug steigt die Frustration und das Projekt verlangsamt sich.
Die goldene Regel der Nutzung von SonarQube
Einer der beliebtesten Ansätze ist der Aufbau agiler Teams um Autonomie, bei denen sich das Team als Besitzer der von ihm implementierten Lösung fühlt. Die Verwendung der SonarQube-Analyseergebnisse als absoluter Qualitätsindikator verringert die Bedeutung der Erfahrungen und Fähigkeiten der Teams. SonarQube ist wie jedes andere statische Code-Analyse-Tool ein technisches Tool, das für das Team funktionieren sollte und nicht umgekehrt. Es ist wichtig, sich an diese einfache Regel zu erinnern, während Sie den Zweck und den Umfang der Verwendung von SonarQube im Entwicklungsprozess mit dem Kunden präsentieren und diskutieren.
Ein ausgereiftes und verantwortungsbewusstes Team, kann seine Erfahrung und Fähigkeiten nutzen, um aus den Analyseergebnissen nützliche Schlussfolgerungen zu ziehen und die Produktqualität zu verbessern. Gleichzeitig stärkt dieser Ansatz die Autonomie des Teams und fördert die Transparenz. Die Verwendung von SonarQube als Geschäftstool ohne den richtigen technischen Kontext und das entsprechende Fachwissen kann zu einer Reihe von Missverständnissen führen. Die gemeldeten Zahlen müssen richtig interpretiert und analysiert werden, bevor sie in vollem Umfang genutzt werden können.
Damit SonarQube für das Team funktioniert
Unter Berücksichtigung dieser Grundannahme kann das Team SonarQube zu seinem Vorteil einsetzen. Wie bei jedem anderen Entwicklungstool sollten die Auswirkungen jedoch ständig überwacht und bewertet werden. Ohne Erfahrung ist es unmöglich, es von Anfang an richtig einzurichten und ohne Änderungen im gesamten Projekt zu verwenden. Es wird empfohlen, mit den Einstellungen für "The Sonar Way" zu beginnen. Sie sind sofort verfügbar, sodass Benutzer sich mit dem Tool vertraut machen können. Dieses Setup funktioniert am Anfang ganz gut.
Als Teil des kontinuierlichen Bereitstellungsprozesses sollte die Konfiguration von SonarQube entsprechend den Änderungen im Projekt angepasst werden. Alle Bedingungen für Quality Gates können vom Team festgelegt werden, angefangen von den am einfachsten zu erreichenden bis hin zu den immer strengeren. Es ist keine gute Idee, eine erforderliche 90% Testabdeckung für eine vorhandene Codebasis festzulegen. Das Bewusstsein der Teammitglieder wird zusammen mit der Strenge der Qualitätsanforderungen wachsen.
Stellen Sie beim Einführen einer statischen Codeanalyse in eine Legacy-Lösung zum Zweck einer Überarbeitung sicher, dass SonarQube die gesamte Codebasis analysiert, nicht nur die neuen Fragmente des Codes. Es ist ein großartiges Tool, um den Fortschritt des Refactorings (manuelle oder automatisierte Strukturverbesserung von Quelltexten unter Beibehaltung des beobachtbaren Programmverhaltens) zu überprüfen. Natürlich nur, wenn Quality Gates die CI / CD-Pipeline nicht blockieren.
Die Anpassung von SonarQube gilt auch für den Umfang der erkannten Probleme. Es wird durch die aktivierten Regeln definiert, die je nach den Anforderungen des Teams geändert werden können. Die Änderungen können den aktuellen Fokus auf ein bestimmtes Thema widerspiegeln. Wenn eine Gruppe von Problemen häufiger auftritt, können zusätzliche Regeln aktiviert werden, um die Entwickler zu unterstützen. Die SonarQube-Regelbasis kann problemlos mit weit verbreiteten externen Tools erweitert werden, die Konventionsprüfer für Codestile wie Checkstyle oder StyleCop enthalten.
Wie bereits erwähnt, kann SonarQube auch die technische Schuld anhand der Zeit abschätzen, die zum Ändern einer Codezeile als Eingabewert erforderlich ist. Diese Metrik kann jedoch große Auswirkungen haben. Daher sollte sie vorsichtig und erst nach einer ordnungsgemäßen Überarbeitung verwendet werden. Der zuverlässige Eingabeparameter muss einzeln eingestellt werden, da SonarQube ihn auf 30 Minuten pro 1 LOC festlegt und nicht für jeden Projekttyp geeignet ist. Sie müssen auch sicherstellen, dass SonarQube die richtigen Pakete analysiert. Dies ist besonders wichtig bei externen Bibliotheken, bei denen falsche Stilprobleme erkannt werden können. Dies hat erhebliche Auswirkungen auf mögliche technische Schulden.
Eine weitere bewährte Methode bei der Arbeit mit SonarQube ist das Exportieren und Speichern von Projektkonfigurationen zur weiteren Verwendung in ähnlichen Projekten.
Mit Hilfe von SonarQube Spitzenleistungen erzielen
Eine weitere wichtige Aktivität, die bei der Integration von SonarQube in den Softwarebereitstellungsprozess durchgeführt werden sollte, besteht darin, das Team über den Zweck, die Arbeitsweise, die Schwierigkeiten und die Vorteile dieses Tools zu informieren. Das Team sollte eine klare Vorstellung davon haben, wie SonarQube funktioniert, wozu es in der Lage ist und wie es ihnen bei alltäglichen Aktivitäten helfen kann, mit dem Code zu arbeiten und ihn sauber zu halten. Am wichtigsten ist, dass Sie die zuvor beschriebene Grundregel hervorheben. Dies bedeutet natürlich auch, dass jedes Teammitglied Zugriff auf eine Instanz des SonarQube haben sollte.
Jedes erkannte Problem hat einen permanenten Link. Benutzer können diese Links öffnen und Kommentare hinterlassen, wodurch diesem Tool eine Funktion zum Wissensaustausch hinzugefügt wird. Die Verfügbarkeit ist auch für den Zweck der Transparenz und die Fähigkeit, eine der hilfreichsten Funktionen zu verwenden, von entscheidender Bedeutung - die Erklärung der Probleme. Es kann das Wissen der Entwickler über Fehler, Code-Smell, Schwachstellen und Sicherheits-Hotspots verbessern, indem es eine ausführliche Erklärung zu jedem Problem bereitstellt, einschließlich:
- das Risiko - der Kontext des Problems und mögliche Konsequenzen,
- eine Checkliste - damit der Entwickler leichter feststellen kann, ob es sich um ein echtes Problem handelt,
- der vorgeschlagenen Möglichkeiten zur Behebung des Problems oder zur Minderung des Risikos.
Auf diese Weise kann ein Teammitglied sein Wissen mit wertvollen Informationen erweitern - nicht nur, welcher bestimmte Code anfällig ist, sondern auch, was der Grund für das Problem ist und wie die Bedrohung gemindert werden kann. Wenn das nächste Mal eine ähnliche Herausforderung auftritt, kann sie früher angegangen oder vollständig vermieden werden. Die ordnungsgemäße Nutzung dieser Art von Wissensbasis kann auf dem Weg zu Spitzenleistungen von Vorteil sein.
Auswirkungen auf die Produktivität
Die Einführung eines neuen Qualitätswerkzeugs in einen bestehenden Lieferprozess wirkt sich immer auf die Produktivität aus. Das Team muss zusätzliche Aktivitäten ausführen, um die Qualitätsanforderungen zu erfüllen, auch wenn es im Prozess selbst kein Blocker ist. Zunächst beobachteten wir einen leichten Rückgang der Produktivität bei der Bereitstellung neuer Funktionen im Vergleich zum Prozess ohne die Verwendung von SonarQube. Dies wurde durch die Tatsache verursacht, dass sich das Team an die neue Situation gewöhnen musste, sowohl im Hinblick auf das Erlernen des Tools als auch auf die zusätzlichen Anstrengungen, die unternommen werden mussten. Die Auswirkungen nahmen jedoch nach einigen Iterationen der Arbeit mit den statischen Code-Analyse-Tools ab.
Zusammenfassung
Die statische Code-Analyse ist eine großartige Technik, um die Qualität des Codes zu verbessern, die technische Schuld zu verringern und das mit Schwachstellen jeglicher Art verbundene Risiko zu mindern. Die von SonarQube, zusammen mit anderen Funktionen, angebotene Implementierung macht es zu einer umfassenden Plattform für die Automatisierung und Unterstützung von Teammitgliedern, die an dieser Aufgabe beteiligt sind. Leider kann es bei unsachgemäßer Verwendung auch zu einem verhassten Werkzeug werden. Dieser kurze Artikel enthielt einige grundlegende Richtlinien für eine reibungslose Integration und Nutzung von SonarQube bei gleichzeitiger Förderung der Transparenz und Autonomie des Teams. Statische Code-Analyse kann für viele Projekte wertvoll sein. Es kann einfache Empfehlungen geben, die es wert sind, berücksichtigt zu werden. Bei richtiger Anwendung ist SonarQube ein großartiges technisches Tool, welches das Team in vielerlei Hinsicht unterstützen kann.
