Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Grundlagen der Programmierung: Codemetriken

Codeanalyseverfahren

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Es gibt grundsätzliche Codeanalyseverfahren, die sich in einigen Dingen immer gleichen. Welche sind das?
04:28

Transkript

Eines der wichtigsten Mittel in der Qualitätssicherung ist die statische Codeanalyse. Jeder von uns weiß, was manuelle Tests sind. Dabei prüft man einfach, ob die Software sich so verhält, wie man das erwartet, indem man einen Eingabewert bereitstellt, den Code entsprechend ausführt und dann prüft, ob der Ausgabewert dem entspricht, was man erwartet, was der Kunde erwarten würde. Wenn ich all meine Daten eingebe, speichere, die Anwendung neu starte, dann sollten meine Daten immer noch vorhanden sein. Das wäre ein eindeutig manueller Test - ein Blackbox-Test. Denn mir ist nicht so wichtig, wie der Code aufgebaut ist, der die Anforderung umsetzt, insofern die Anforderung umgesetzt ist. Dabei unterscheiden sich manuelle und automatisierte Tests nicht besonders, wobei automatisierte Tests natürlich dennoch prüfen können, wie der Code intern aufgebaut ist. Sie sind dann eher so eine Art Graybox-Test, aber das führt jetzt zu weit. Demgegenüber ist die statische Codeanalyse nicht dafür da, zu prüfen, ob die richtigen Anforderungen umgesetzt sind. Mit statischer Codeanalyse ist es uns egal, ob das Speichern überhaupt funktioniert, insofern der richtige Transaktionskontext aufgesetzt wurde. Ob überhaupt Transaktionen richtig eingesetzt wurden, ob wir eventuell eine Konvertierung von Daten vornehmen müssen um sie zwischen der Datenbank zu übertragen. All das bekommen wir über die statische Codeanalyse geprüft, indem der Code statisch analysiert wird, indem wir einen Whitebox-Test machen, indem jede Methode, jede logische zusammenhängende Einheit unseres Codes geprüft wird, ob wir unsere Technologie korrekt einsetzen. Das ist die statische Codeanalyse. Dabei gibt es zwei Ausprägungen. Hier in dem Fall haben wir Quellcode, der zwar in C# geschrieben ist, aber überhaupt nicht dem Stil entspricht, wie man C#-Code schreiben würde. Demgegenüber ist dieser Code wiederum, der jetzt eingeblendet wurde, Code, der den gängigen Styling-Regeln von C# entspricht. Ein Teil von statischer Codeanalyse beschäftigt sich also auch damit, sicherzustellen, dass der Stil des Codes so eingehalten wird, dass unterschiedliche Entwickler das gleiche Verständnis von Quellcode entwickeln können, dass sie es leicht verstehen können, dass man in den Quellcode unterschiedlicher Personen hineinschauen kann und sofort versteht, was da letztendlich passiert. Das ist aber nicht die einzige Form der statischen Codeanalyse. Eine andere wird heutzutage sehr häufig bereits in den Entwicklungsumgebungen eingesetzt, um beispielsweise zu prüfen, inwiefern Situationen entstehen, weil die Technologie falsch eingesetzt wurde. Wenn man zum Beispiel die Sichtbarkeit einer überschriebenen Methode ändert, indem man sie "protected" macht, obwohl sie vorher "public" war, dann müsste das Visual Studio einen darauf hinweisen, bevor man kompiliert und der Kompilierungsfehler entsteht. Man könnte das zwar auch später machen, aber dann kann schon wieder so viel Zeit ins Land gegangen sein, dass man gar nicht mehr so genau weiß, wo der Fehler entsteht. In dem Fall wird der Code auch gegen Code-Metriken geprüft. Die statische Codeanalyse kann uns dann beispielsweise sagen, ob wir von zu vielen Basisklassen erben, ob die Methoden zu komplex sind und so weiter und so fort. Es wird eindeutig der Code geprüft, ob er gängigen Richtlinien entspricht, um uns langfristig vor Fehlern zu bewahren. Die Werkzeuge, die dabei eingesetzt werden, sind natürlich technologieabhängig. Häufig teilen sie sich in zwei unterschiedliche Klassen von Werkzeugen. So sind im Microsoft-Umfeld StyleCop und FxCop weit verbreitet, wobei StyleCop sich eher darum kümmert, ob der Code richtig aussieht, und FxCop, ob der richtige Code eingesetzt wurde, beziehungsweise ob der Code, der vorhanden ist, richtig eingesetzt wurde. Im Java-Umfeld gibt es dafür checkstyle. Das prüft, ob eben der Code richtig aussieht, und FindBugs, ob eventuell Fehler vorhanden sind. Dann gibt es noch so etwas wie JSLint und TSLint, also "typescript". Diese kümmern sich häufig eher darum, dass der Code den richtigen Aufbau hat, aber sie können zeitgleich auch Hinweise darüber geben, ob zum Beispiel der dreifache Ist-gleich-Operator richtig eingesetzt wurde oder nicht. Und auf die Art und Weise analysieren sie eben den Code und sagen uns, ob hier Probleme entstehen oder nicht. Im C++-Umfeld gibt es dann entsprechend auch einen C++-Check, mit dem man den Code überprüfen kann.

Grundlagen der Programmierung: Codemetriken

Lernen Sie Methoden, Prinzipien und Werkzeuge kennen, mit deren Hilfe Sie die Qualität Ihrer Software dauerhaft sicherstellen können.

1 Std. 43 min (20 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.04.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!