Cleane Code: riecht

Karl Gorman
Clean code overview by Chudovo

Wir setzen die Artikelserie über Clean Code-Konzepte fort, die auf dem berühmten Buch von R.Martin Clean Code basiert: A Handbook of Agile Software Craftsmanship, der Klassifizierung von Urs Enzler von BBV und unseren Erfahrungen. Wir würden über Code Smells und Code Metrics schreiben: Indikatoren, die helfen, den Code in unserer Softwarelösung zu analysieren.

Code-Metriken

Die folgende Liste zeigt die Ergebnisse der Code-Metriken, die Visual Studio berechnet:

  • Wartbarkeitsindex – Berechnet einen Indexwert zwischen 0 und 100, der die relative Leichtigkeit der Wartung des Codes darstellt. Ein hoher Wert bedeutet eine bessere Wartbarkeit. Farbcodierte Bewertungen können verwendet werden, um Problemstellen in Ihrem Code schnell zu identifizieren. Eine grüne Bewertung liegt zwischen 20 und 100 und zeigt an, dass der Code gut wartbar ist. Eine gelbe Bewertung liegt zwischen 10 und 19 und zeigt an, dass der Code mäßig wartbar ist. Eine rote Bewertung liegt zwischen 0 und 9 und zeigt eine geringe Wartbarkeit an.
  • Zyklomatische Komplexität – Misst die strukturelle Komplexität des Codes. Sie wird durch die Berechnung der Anzahl der verschiedenen Codepfade im Programmfluss erstellt. Ein Programm mit komplexem Kontrollfluss erfordert mehr Tests, um eine gute Codeabdeckung zu erreichen, und ist weniger wartbar.
  • Tiefe der Vererbung – Gibt die Anzahl der Klassendefinitionen an, die bis zur Wurzel der Klassenhierarchie reichen. Je tiefer die Hierarchie, desto schwieriger kann es sein zu verstehen, wo bestimmte Methoden und Felder definiert oder/und umdefiniert werden.
  • Klassenkopplung – Misst die Kopplung an eindeutige Klassen durch Parameter, lokale Variablen, Rückgabetypen, Methodenaufrufe, generische oder Template-Instanziierungen, Basisklassen, Schnittstellenimplementierungen, auf externen Typen definierte Felder und Attributdekoration. Gutes Softwaredesign schreibt vor, dass Typen und Methoden eine hohe Kohäsion und eine geringe Kopplung aufweisen sollten. Hohe Kopplung deutet auf ein Design hin, das aufgrund seiner vielen Abhängigkeiten von anderen Typen schwer wiederverwendbar und wartbar ist.
  • Lines of Code – Gibt die ungefähre Anzahl der Zeilen im Code an. Die Anzahl basiert auf dem AWL-Code und ist daher nicht die genaue Anzahl der Zeilen in der Quellcodedatei. Eine sehr hohe Anzahl kann darauf hinweisen, dass ein Typ oder eine Methode zu viel Arbeit zu erledigen hat und aufgeteilt werden sollte. Es könnte auch darauf hinweisen, dass der Typ oder die Methode schwer zu warten ist.
  • Testcodeabdeckung – Um festzustellen, welcher Anteil des Codes Ihres Projekts tatsächlich durch kodierte Tests wie Unit-, Funktions- und andere Testtypen getestet wird.
Auf der Suche nach einer neuen Herausforderung?

Interessante Projekte

Zuverlässige Arbeitgeber

Faire Vergütung

– Steifigkeit

Die Software ist schwer zu ändern. Eine kleine Änderung bewirkt eine Kaskade von Folgeänderungen.
Präzise Indikatoren: Tiefe der Vererbung, Klassen-Kopplung.
Lösungsansatz: Code über Loose Coupling, High Cohesion Prinzipien refaktorisieren, Klassenstruktur neu gestalten.

– Zerbrechlichkeit

Die Software bricht an vielen Stellen durch eine einzige Änderung.
Präzise Indikatoren: Tiefe der Vererbung, Klassenkopplung, Abdeckung der Unit-Tests.
Lösungsansatz: Unit-Tests-Abdeckung, Change is Local-Prinzip, Code refaktorisieren über Lose Kopplung, Hohe Kohäsion, Single Responsibility-Prinzip

Kommentar: Refactor, Refactor, Refactor

– Unbeweglichkeit

Sie können Teile des Codes wegen der damit verbundenen Risiken und des hohen Aufwands nicht in anderen Projekten wiederverwenden.
Genaue Indikatoren: Tiefe der Vererbung, Klassenkopplung, Abdeckung der Unit-Tests.
Fixer Ansatz: Unit-Tests abdecken, Code über Loose Coupling refaktorisieren.

– Viskosität der Konstruktion

Eine Abkürzung zu nehmen und technische Schulden einzuführen, erfordert weniger Aufwand als es richtig zu machen.
Präzise Indikatoren: Maintainability-Index, zyklomatische Komplexität, Klassenkopplung.
Fixer Ansatz: Unit-Tests abdecken, Maintainability-Index und zyklomatische Komplexität verbessern über Aufteilung in Unter-Methoden

Kommentar: Manchmal treten zeitkritische Aufgaben auf, die ‚irgendwie‘ ASAP umgesetzt werden müssen. Eine solche Praxis sollte die Ausnahme sein.

– Viskosität der Umgebung

Bauen, Testen und andere Aufgaben nehmen viel Zeit in Anspruch. Daher werden diese Aktivitäten nicht von allen ordnungsgemäß ausgeführt und es entstehen technische Schulden.
Genaue Indikatoren: Zeit für das Bauen, Bereitstellen und Ausführen von Unit-Tests.
Lösungsansatz: Einrichtung von Continuous Integration mit automatischer Ausführung aller erforderlichen Schritte.

Kommentar: Die Zeit für das Deployment mit der Ausführung von Tests sollte bei normaler Teamarbeit nicht mehr als 5 Minuten betragen.

– Unnötige Komplexität

Das Design enthält Elemente, die derzeit nicht sinnvoll sind. Die hinzugefügte Komplexität erschwert die Verständlichkeit des Codes. Das Erweitern und Ändern des Codes führt daher zu einem höheren Aufwand als nötig.
Präzise Anzeigen: Schwierig, eine einfache Funktion hinzuzufügen, große unnötige Flexibilität.
Fixer Ansatz: KISS-Prinzip, Analysieren und Reduzieren, wenn es möglich ist, Geschäftsregeln

Kommentar: Manchmal muss man die Flexibilität vergessen und versuchen, den Geschäftswert des Produkts zu verstehen

– Unnötige Wiederholungen

Code enthält exakte Code-Duplikate oder Design-Duplikate (die das Gleiche auf andere Weise tun). Eine Änderung an einem duplizierten Codestück ist teurer und fehleranfälliger, weil die Änderung an mehreren Stellen vorgenommen werden muss, mit dem Risiko, dass eine Stelle nicht entsprechend geändert wird.
Genaue Indikatoren: in VS -> Anaylze Solution for Code
clonesFix-Ansatz: Code über Refactoring ähnliche Funktionalität an allgemeine Codestelle extrahieren

– Schlechte Opazität

Der Code ist schwer zu verstehen. Daher erfordert jede Änderung zusätzliche Zeit, um den Code zunächst zu überarbeiten, und es ist wahrscheinlicher, dass es zu Defekten kommt, weil die Seiteneffekte nicht verstanden werden.
Genaue Indikatoren: Maintainability Index, Zyklomatische Komplexität, Lines of Code.
Fixer Ansatz: Code-Konventionen befolgen, KISS-Prinzip, Aufteilung in Unter-Methoden

Kommentar: Hier ist eines der Hauptziele von Clean Code: Code ist sauber, wenn er leicht verstanden werden kann – von jedem im Team

Der nächste Artikel wird sich mit den Prinzipien des Klassenentwurfs befassen: Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Dependency Inversion Principle, Interface Segregation Principle, Class Size, Class Responsibility.

Quellen:
R.Martin Clean Code: A Handbook of Agile Software Craftsmanship
MSDN
Wikipedia