Notes about “Design Sense – Cultivating Deep Software Design Skill”

image

Bei diesem Talk von Michael Feathers handelt es sich wieder einmal um ein absolutes Meisterwerk. Ein Mischung aus Andy Hunt’s Buch: “Pragmatic Thinking and Learning”, Bob Martin’s Buch “Clean Code” und natürlich Michael Feathers’ Buch “Working Effectively with Legacy Code”.

Der Talk geht eigentlich hauptsächlich auf die Frage ein, wie man als Entwickler schlecht geschriebenen Code erkennen kann. Natürlich kommt es immer darauf an was man unter schlecht geschriebenen Code versteht. Die Entwickler des Linux-Kernel haben ein anderes Verständnis für sauberen Code als die Mitglieder der Agile Community.

Anhand von einigen Beispielen zeigt Michael Feathers, dass man auch schon allein anhand der Code-Strukturierung erkennen kann ob Code eventuell chaotisch wirkt. Dabei zeig er einige Beispiele in verschiedenen Programmiersprachen die nur als Nullen dargestellt werden.

image

image

Eine sehr interessante Möglichkeit um festzustellen ob Code gut entkoppelt, eine hohe Kohäsion, kleine Klassen etc. besitzt, ist ein Abhängigkeitsgraph der zeigt, welche Methode oder Variable von welcher anderen wie abhängt. Ein sehr übersichtliches Beispiel hierfür war die Junit-Klasse “TestCase”. In der Abbildung kann man sehr schön erkennen, dass z.B. die run-Methode von dem etwas anderem Konstrukt darunter total entkoppelt ist. Ist das eventuell ein Anzeichen, dass diese Methode in eine andere Klasse gehört?

image

Trotzdem kann man sagen, dass ich lieber mit so einer kleinen Klasse, mit übersichtlicher Funktionalität arbeite also mit dem folgenden absolut grässlichen Konstrukt.

image

Dabei handelt es sich um eine einzige Klasse eines nicht genannten Open-Source Projekts. Michael Feathers erwähnt, dass egal was der Autor dieser Klasse, oder irgendjemand behauptet; dass ist schrecklicher Code. Niemand möchte mit so einer Klasse lieber arbeiten als mit der zuvor gezeigten TestCase-Klasse des JUnit-Frameworks. Leider ist dieses Tool zum Erzeugen so eines Diagrammes noch nicht veröffentlicht worden aber sobald es das ist, wird Michael Feathers darüber auf seinem Weblog berichten.

Auch wenn jeder Entwickler seinen eigenen Coding-Style besitzt gibt es doch gewisse allgemein geltende Ansichten darüber, wann Code gut bzw. schlecht entworfen wurde. Dabei geht Michael Feathers auf die folgenden Punkte ein:

  • Die Länge von Methoden: Wie lange sollten Methoden sein? Dabei erwähnt er, dass ein allgemeiner Konsens darüber herrscht, dass kurze Methoden besser sind als lange. Dem stimme ich zu 100% zu, jedoch dieser Konsens existiert meiner Meinung nach leider noch nicht.
  • Anzahl der Parameter einer Methode: Wie viele sind noch ok?
  • Die Länge von Identifiern: Namensgebung für Klassen, Variablen und Methoden.
  • Verschachtelungen: Refactoring-Hinweis: Replace Conditional with Guard Clause
  • “Looked good in a diagram”: Zwar gab es ein gutes Top-Level-Design aber was darunter passiert kümmert niemanden.
  • Heterogene Teams: Code-Basis mit vielen verschiedenen Styles
  • Structure-Fetisch: Disziplin ist gut allerdings sollte man offen für Verbesserungen sein. Homogenität sollte nicht das allerwichtigste Kriterium einer Code-Base sein.

Zum Schluss erklärt Michael Feathers noch bestimmte Stile die er in der Praxis am Häufigsten antrifft. Die Bezeichnungen wurden von ihm erfunden, jedoch weiß er noch nicht ob sie absolut treffend für die einzelnen Kategorien sind:

  • Equipoise Style: Dieser Stil wird von Bob Martin, Kent Beck und vielen anderen propagiert. Dieser Stil sollte von jedem Entwickler angestrebt werden. Es geht dabei um Reduzierung von Code-Duplikation, dem Entwerfen von sehr ausdruckstarkem Code etc.
  • Slack Style: Es gibt vereinzelte Klassen und/oder Methoden die noch verbessert gehören.
  • Ossified Procedural: Prozeduraler Code in OOP
  • Sprawl Style: Kein Stil vorhanden😉

Zum Schluss erwähnt Michael Feathers noch einen interessanten Punkt und zwar, dass es in der Industrie so viele Entwickler gibt die aufgrund ihrer Code-Basis leiden, jedoch nichts anderes kennen, und eventuell daher gar nicht wissen, dass sie leiden. Was heißt das nun genau? Was kann man daraus schließen? Es handelt sich glaube ich dabei um eine Mixtur aus Desinteresse, sich keine Zeit für Weiterbildung einzuplanen, das nicht-lesen der richtigen, wichtigen Bücher wie die in diesem Post erwähnten. Was ist daher die Aufgabe der Entwickler die sich sehr wohl dessen bewusst sind und den sogenannten Equipoise Style praktizieren? Die Devise kann nur sein: Propagieren, propagieren, propagieren! Mit seinen Kollegen darüber reden, diskutieren, auf Bücher verweisen, auf Tech-Talks hinweisen usw. In der heutigen Zeit ist es einfach nicht mehr notwendig, dass man Methoden entwirft, die über 100 Zeilen lang sind. Es gibt so viel Fortbildungsmaterial, so viele gute Möglichkeiten mit Entwicklern in Kontakt zu treten (Twitter und Co.), die etwas von ihrem Handwerk verstehen.

Deshalb plädiere ich darauf, sofern man sich noch nicht mit all diesen Themen beschäftigt hat, dass man sich den Talk von Michael Feathers ansieht und in Folge meinen Weblog nach weiteren Materialien durchstöbert. Ich habe schon einige Posts mit vielen Verweisen auf die richtigen Materialien erstellt.

Never stop learning!

Über sageniuz

https://about.me/ClausPolanka
Dieser Beitrag wurde unter Clean Code veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s