Dies ist ein (unvollständiger) Auszug aus dem gedruckten Buch .
Schmutzfinken – eine Spezies, die so alt ist wie das Programmieren selbst. Schmutzfinken besitzen einen überaus starken Überlebenswillen und lassen sich auch durch Technologiewechsel nicht aus ihrem Konzept bringen. Im Gegenteil: Mit jeder neuen Technologie, Programmiersprache und jedem Framework entdecken Schmutzfinken neue und kreative Möglichkeiten, ihrer Passion zu frönen.
Namen sind Schall und RauchPermalink
Wie im ersten Programmierkurs nennen Schmutzfinken die Dinge gerne kurz.
i, j, x
und y
eignen sich als Namen hervorragend, ob Businessdaten oder Statusinformation, kürzer als einbuchstabig geht leider nicht. Und in der Kürze liegt die Würze.
Statt viel Zeit in das Erfinden fachlich passender Bezeichner zu investieren, halten wir uns an etablierte Kurzformen und schaffen dadurch knackig kompakten Code. Das gilt natürlich sowohl für Variablen, Attribute sowie Funktionen oder Methoden.
Modularisierung ist bösePermalink
Nur solche Menschen modularisieren, die zuhause warm duschen oder im Winter eine Heizung benutzen. Richtige Entwickler zentralisieren Logik und Daten in möglichst wenigen Dateien. Funktionen oder Methoden sind schon Modularisierung genug, was braucht der schmutzige Fink dazu noch weitere Klassen, Packages oder Namespaces.
Eine einzige Klasse, beispielsweise Server.java
, genügt für mittelgroße Systeme in jedem Fall. Da bekommt der Schmutzfink richtig schöne Kohäsion: Es steht alles, wirklich alles, zusammen, was zusammen gehört (okay, möglicherweise noch einiges mehr – aber das ist Erbsenzählerei).
Big is beautifulPermalink
In langen Funktionen oder Methoden steht alles, was der Schmutzfink über diese Methode wissen muss – kein lästiges Hin- und Herspringen, kein Verfolgen von Aufrufketten. Diese Vorschläge, höchstens eine Bildschirmseite voll (oder gar noch kürzer, wie Robert Martin1 fordert) taugen höchstens für Menschen mit schwachem Kurzzeitgedächtnis, aber nicht für echte Entwickler.
Zwei-Augen-PrinzipPermalink
Zwei Augen genügen. Immer. Sonst redet dem Schmutzfink ja nur jemand anders unnötigerweise rein – und unterbricht unter Umständen den kontinuierlichen Ausfluss der Komplexität – ähm Genialität. Allein programmiert es sich immer noch am besten. Außerdem sitzt mir ja der Computer gegenüber – der hilft in Krisen zuverlässig und kompetent weiter.
QuellenPermalink
Das Original erschien im September 2014 im JavaMagazin.
HinweisPermalink
arc42 offers architecture training.
Two expert trainers at all times, highly practical and pragmatic, ideal preparation for iSAQB CPSA-Foundation certification.Next available dates (in English):
- June 24-26 2025, online (Trainer: Wolfgang Reimesch)
- October 14-16 2025, online (Trainer: Wolfgang Reimesch)
Next available dates (in German):
- May 20.-23. 2025, Mannheim (only few seats available)
- September 23.-26. 2025, Frankfurt
- Dec 2.-5. 2025, Munich
iSAQB Advanced Topics
IMPROVE: Learn to effectively evolve and maintain systems.
- May 7.-9th 2025, Mannheim, SOLD OUT Gernot Starke and Peter Hruschka
- July 15.-17th 2025, Hamburg, Carola Lilienthal with Gernot Starke
- November 25.-27th 2025, Hamburg, Carola Lilienthal with Gernot Starke
Req4Arc: Getting your Requirements right.
What to do if your requirements need improvement.ADOC: Architecture Documentation
How to efficiently and effectively create and maintain useful technical documentation, with a strong focus on arc42. Within this practical course you improve your own documentation!Contact us for inhouse training.
Version of: 2025-March-30
-
Martin, Robert: „Clean Code. A Handbook of Agile Software Craftsmanship“, Prentice Hall, 2008 ↩