Softwareentwicklungsschmutz - Teil 2

Schmutz im Code erkennen und vermeiden

Wie schon im 1. Artikel beschrieben, führt Softwareentwicklungsschmutz zu Ineffizienz und Verzögerungen im Entwickleralltag. Als Schmutz wird all das verstanden, was die Softwareentwicklung verlangsamt und die Akteure behindert.

Wie schon im 1. Artikel beschrieben, führt Softwareentwicklungsschmutz zu Ineffizienz und Verzögerungen im Entwickleralltag. Als Schmutz wird all das verstanden, was die Softwareentwicklung verlangsamt und die Akteure behindert.

Im 2. Artikel möchte ich zeigen, wie durch konkrete Präventionsmaßnahmen in verschiedenen Bereichen der Softwareentwicklung Schmutz erkannt und vermieden werden kann. Abschließend zeige ich im 3. Teil, welche Maßnahmen zur Steigerung der Softwarequalität auf Team-Ebene umgesetzt werden können.

Definition of Done

Die Definition of Done (DoD) stellt einen wesentlichen Bestandteil dar, um die Softwarequalität sicherzustellen. Die Abbildung (1.1) zeigt, welche Punkte zur Definiton of Done gehören können.

#

Ein Fehlen der DoD führt dazu, dass die unterschiedlichen Teammitglieder ein jeweils anderes Verständnis davon haben, wann ein Prozess abgeschlossen ist und wann nicht. Daher schlage ich als Gegenmaßnahmen vor:

  • die DoD so früh wie möglich klären,
  • allen Beteiligten die DoD vergegenwärtigen,
  • die Einhaltung der DoD durch ein 4-Augen-Review prüfen.

Die Gasfabrik

Dieser Begriff steht in der Softwareentwicklung für eine übertrieben komplexe Lösung. Probleme, die zu einer erhöhten Komplexität führen sind ungebremste Neugier, Neues auszuprobieren und eine zu hohe Priorisierung von Konfigurierbarkeit und Erweiterbarkeit – eine generische und an jede Situation anpassbare Lösung erfordert in der Regel eine unnötig komplexe Implementierung. Gegenmaßnahmen sind:

Wechselnde Anforderungen

Wie bereits in Artikel 1 dargestellt, ist der Projektalltag geprägt durch ständig wechselnde Anforderungen. Um die “Code-Sauberkeit“ dabei gewährleisten zu können, sollten folgende Gegenmaßnahmen angewendet werden:

  • betreffende Code-Zeilen mit einem speziellen Kommentar markieren und konsequent diese Markierungen prüfen (“Code-Tagging-System”),
  • agile Softwareentwicklungs-Methoden anwenden,
  • die Frusttoleranz stärken (z.B. mit einem Stück Schokolade).

Broken Windows

In der IT ist dieser Begriff auch als Software-Entropie bekannt. Konkret bedeutet dies – je weiter die Verrottung fortgeschritten ist, desto anstrengender wird es sich in diesen Sachverhalt hineinzudenken. Die Gefahr wird größer, dass Workarounds programmiert werden anstatt gründlich “aufzuräumen“. Folgende Präventionsmaßnahmen sind geeignet:

  • regelmäßige Refactoring-Maßnahmen,
  • konsequent Pfadfinder-Regeln (der Clean Code Developer) anwenden.

Konformitätsbrüche

Konformitätsbrüche liegen vor, wenn der Code plötzlich von einem regelmäßigen Implementierungsschema abweicht. Die Folge ist, dass zu einem späteren Zeitpunkt Entwickler unnötig Zeit damit verbringen nach dem Grund der Abweichung zu suchen. Typisch dafür ist unvollständiges Refactoring. Eine andere Ursache liegt darin, dass ein Entwickler eine Aufgabe mit einer bereits im Code umgesetzten Lösung realisieren könnte, diese aber nicht kennt (mangelnde Kommunikation) oder glaubt, die Aufgabe besser lösen zu können. Um dem vorzubeugen, helfen:

  • Code-Reviews oder Pair-Programming,
  • vollständiges Refactoring (Alle Stellen umbauen, wenn eine neue Lösung etabliert wird.).

Uneinigkeit im Team

Die Zusammensetzung eines Teams kann den Erfolg oder Misserfolg der Softwareentwicklung stark beeinflussen. So kann durch Unstimmigkeiten innerhalb des Teams die “Grund-Stimmung” negativ beeinflusst werden und die Kommunikation belasten/einschränken.

Wenn nicht im Team gearbeitet wird, existieren keine gemeinsamen Ideen von Lösungen – es entsteht “Code-Wildwuchs“. Gegenmaßnahmen sind:

  • mehr Mut zur Selbstreflektion,
  • mehr Mut mit anderen zu kommunizieren,
  • mehr Motivation Verantwortung zu übernehmen,
  • mehr Motivation Neues zu lernen und auszuprobieren.

Termindruck

Als Hauptgrund von Dirty-Code wird von Entwicklern meist als erstes Termindruck genannt. Wie auch schon im 1. Teil beschrieben, kann Termindruck in der Tat große Probleme aufwerfen. Das Kräfte-Dreieck aus Kosten, Termin und Qualität zeigt, dass die drei Kräfte miteinander konkurrieren. Das Bild der Waage verdeutlicht, dass bei erhöhtem Druck auf die Termine und gleichbleibenden Kosten – die (Software-)Qualität negativ beeinflusst wird.

Wie kann dem entgegengewirkt werden?

  • Verantwortung für die innere und äußere Softwarequalität übernehmen und seinem Berufsethos treu bleiben (Clean-Coding-Regeln),
  • Termindruck durch realistische Aufwandsschätzungen reduzieren,
  • Frusttoleranz stärken.

Fazit

Das Gewährleisten einer hohen Softwarequalität erfordert Disziplin, persönliche Verantwortung für das Produkt, eine gut funktionierende Kommunikation im Team und den Willen sich aktiv und gewissenhaft mit der Software auseinanderzusetzen.

Besonders wichtig für die Prävention von Softwareentwicklungsschmutz sind vor allem die Kernkompetenzen:

  • Mehr Motivation, sich neues Wissen und handwerkliche Fähigkeiten anzueignen.
  • Mehr Motivation , konstruktive Kommunikation zu suchen.
  • Mehr Mut, seinem Berufsethos treu zu bleiben.

Alle genannten Maßnahmen können unabhängig von dem Team durchgeführt werden. Welche Maßnahmen gemeinsames Engagement benötigen, zeigt der 3. Teil.


Artikelserie "Softwareentwicklungsschmutz"

Jetzt teilen: