Clean Code
Kommentare

Grundprinzip: Keep it Simple, Stupid! (KISS)
Das zehnte Prinzip des agilen Manifest lautet „Simplicity – the art of maximizing the amount of work not done – is essential.“ Auf den ersten Blick wird die

Grundprinzip: Keep it Simple, Stupid! (KISS)

Das zehnte Prinzip des agilen Manifest lautet „Simplicity – the art of maximizing the amount of work not done – is essential.“ Auf den ersten Blick wird die „Maximierung von nicht getaner Arbeit“ vielleicht als „Faulheit“ missverstanden. Bei genauerer Betrachtung ist vielen Entwicklern klar, dass es darum geht, die einfachste Lösung zu entwickeln und nicht mehr. Das Antipattern dazu ist „Goldplating“ – also das Vergolden von Features: Man schreibt das Stück Funktionalität zu generisch oder auch mit viel zu viel Extras rundherum, die keiner braucht. Wie schon bei TDD erwähnt, sagt uns dieses Prinzip das gleiche auf einer höheren Ebene: Es sollte die zunächst einfachste Lösung umgesetzt werden, die funktioniert – und dann auf der Basis von Feedback, neuen Erkenntnissen und neuen Anforderungen darauf aufbauend weiter gearbeitet werden.

Systeme werden unter Missachtung des KISS-Prinzips („Halte es einfach, Dummkopf!“ und nicht „Halte es einfach und dumm!“) von vornherein aufgebläht und generisch entwickelt. Am Ende stellt sich dann heraus, dass die Dinge, die man versucht hat zu antizipieren, entweder gar nicht benötigt werden und wenn, dann in einer deutlich anderen Art und Weise als ursprünglich angenommen. Die essenzielle Frage, die sich Teams immer wieder stellen müssen, ist: „Mit wie wenig kann ich davonkommen, um alle bekannten und tatsächlich geforderten Anforderungen umzusetzen?“ Die zweite Frage, die sich ein Team immer wieder stellt, ist die, ob sie sich bei einer Entscheidung auf Tatsachen oder Annahmen stützen. Oft freue ich mich dann, wenn ich dann aus ihrem Munde höre „Keep it simple, stupid!“

Eine noch stärkere Konsequenz erschließt sich mit dem Kürzel „YAGNI – you ain’t gonna need it“. Mit der gleichen Intensität, mit der wir hinterfragen, ob wir die einfachste Lösung gewählt haben, sollten wir auch fragen, ob wir ein gegebenes Softwarefeature überhaupt brauchen.

Grundprinzip: Verfrühte Optimierung vermeiden

Donald Erwin Knuth, einer der Pioniere in der algorithmischen Informatik, hat (in Anerkennung einer früheren Aussage von CAR Hoare) einen wichtigen Satz geprägt: „Premature Optimization is the root of all evil!“ [5]. Unzählige Fehler und „Verbrechen“ am Code sind im Namen der Optimierung begangen worden. Die Vorsicht vor Optimierungen ist mehr als angebracht, denn in der Regel haben wir Entwickler es ja schon schwer, es beim ersten Mal richtig zu machen – was einer der Gründe für Test-driven-Development und Refaktorisierung ist. Wie sollen wir es dann beim ersten Mal optimiert hinbekommen?

Ein weiteres Standardwerk der Informatik, das nicht zuletzt aufgrund seines Alters vermutlich von hunderttausenden von Entwicklern gelesen wurde, griff das Thema ebenfalls auf. Brian Kernighan und Dennis Ritchie gaben Entwicklern in ihrem Buch „The C Programming Language“ bereits 1977 den Rat, eine Funktion zunächst mal zum Laufen zu bringen und sie dann erst zu optimieren [6].

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -