Duck-Tape-Programming und Clean-Code

Als auf der letzten PRIO der Begriff "Duck-Tape-Programming" fiel konnte ich mir sofort was drunter vorstellen - wer könnte das nicht.

Natürlich wurde diese Art der Programmierung als unprofessionell und schlecht gebrandmarkt.

Natürlich?? Warum eigentlich?

Wenn ich Duck-Tape höre fällt mir als erstes der Rally-Sport ein. Hier vollbringen Mechaniker mit Duck-Tape wahre Wunder. Für den Laien völlig zerstörte Fahrzeuge werden mit Duck-Tape, Draht und Spuke wieder zusammen geflickt, bestehen noch die nächste Prüfung und vielleicht gewinnt das Team sogar noch die Rally.

Arbeiten diese Mechaniker unprofessionell?
Sind sie schlecht?
Nein, schlecht sind sie garantiert nicht. Die besten Mechaniker schaffen es vielleicht mal Rally-Mechaniker zu werden.

Sie arbeiten nur unter sehr ungewöhnlichen Bedingungen. Ihre Arbeit erfolgt unter enormen Zeit- und Erfolgsdruck mit einem Ergebnis das nur eine sehr begrenzte Zeit durchhalten muss.

Den Gegenpart bildet der Mechaniker in der Werkstatt in die der Familienvater sein Auto bringt: Hier erwarten wir dass in Ruhe ein Ergebnis erzielt wird das "ewig" hält. Niemand will eine Reperatur die zwar schnell geht aber nur circa 100 km hält.

Und hier sehe ich den Zusammenhang zu unserer Arbeit: Die meisten Entwickler (wie auch die meisten Kfz-Mechaniker) arbeiten in einer "Werkstatt" in der es auf Zuverlässigkeit, Langlebigkeit und Robustheit ankommt. Und somit sollten sie so sauber und sorgfältig wie nur irgend möglich arbeiten. Das Ziel sollte immer das bestmögliche und bestwartbare Produkt sein.

Immer mal wieder ist aber auch eine Rally angesagt:
Wenn der Vorstand JETZT Zahlen haben will die einmalig für diesen Forecast gebraucht werden (für den nächsten gelten eh wieder andere Regeln) und man somit "Wegwerf"-Software baut oder Software JETZT um eine ganz spezielle Funktion erweitert werden muss für die Präsentation HEUTE NACHMITTAG - dann ist "Dranflicken" und Improvisieren angeagt. Duck-Tape-Programming ist dann angesagt - ob wir es so nennen oder nicht.

Aber wie auch bei jeder Rally sollte man nicht die Vor- und Nachbereitung vergessen! Rally-Teams bereiten sich mit einem ungeheuren Aufwand von Zeit und Geld auf die extremen Phasen vor. Und jede dieser Phasen wird hinterher ausgewertet und fließt in Verbesserungen und Veränderungen des Fahrzeugs ein.
Und auch das sollten wir uns zum Vorbild nehmen: Nach der letzten Wertungsprüfung alle mit Tape angeklatschten Teile abreißen und die Ursache analysieren warum sie abgerissen sind. Und diese Ursachen dann beheben.

Und damit sind wir wieder in unserer Werkstatt und arbeiten nach dem Clean-Code-Ansatz.

Bis zur nächsten Rally!

Listen in Datenbanken

Klassischer Fall: Der Benutzersoll in einem Feld Werte erfassen, die aus einer Liste ausgesucht werden.
Sei es, das danach später gesucht werden soll und daher die anzahl der Einträge nicht endlos ausufern soll, sei es, dass nur bestimmte Werte erlaubt sein sollen.




Die klassische Lösung: Die Werte werden in einer eigenen Tabelle hinterle und in der ursprünglichen Tabelle wird die ID gespeichert.




Vorteil: Wird die Screibweise eines Eintrags geändert, ändert sich der Wert für alle - es ist ja die ID hinterlegt.
Nachteil: Jeder Wert, der eventuell verwendet werden soll, muss gepflegt werden - also muss eine Datenpflege geschaffen werden und wenn ein neuer Wert zulässig sein soll, muss dieser erst in der Domain-Tabelle erfast werden. Wurde die Eingbe über eine Liste gewählt, weil nur bestimte, vorgegebene Werte erwünscht sind, ist diese Lösung mt Sicherheit die richtige.




Erfolgt die verwendung der Liste dagegen aus Gründen der Komforsteigerung, so ist die reflexible bzw. selbtfüllende Liste eine bedenkenswerte Alternative: Hierbei wird die Liste mit einer Anweisung im Stile von "Select DiesesFeld from MeineTabelle group by DiesesFeld order by DiesesFeld" gefüllt. Somit stehen immer alle schon erfasten Werte zur Auswahl zur Verfügung.




Was aber nun, wenn über das Feld eine 1:n -Verknüpfung befüllt werden soll? Bei der klassischen, egen Koppelung ist es notwendig, erst alle Einträge zu erzeugen, auf die dann über de Liste referenziert werden soll.




Handelt es sich bei der Eingabe - die ja auch der Schlüssel der n-Seite ist - um einen Wert, der einen realen Bezug hat und an sich schon eindeutig ist, wie z.B. eine Raumnummer, so wäre doch auch ein Verfahren denkbar, dass ich mal die "verzögerte Tabellenbindung"nennen möchte.




Hierbei ist es möglich, die Raumnummer zu erfassen, auch wenn der Raum selber in der Raumtabelle noch nicht angelegt ist. Die Liste füllt sich mit den schon angelegten und den in der Tabele erfasten Raumnummern, also der UNION aus reflexibler Liste und echter Verweisliste.
In einem anderen Bearbeitungsschrit, auf einer anderen Maske, bekommt man dann die Raumnummern angezeigt, die zwar verwendet werden, aber in der Raumtabelle noch nicht angelget sind.




Alternativ kann bei jedem neuen Wert erst mal der Benutzer nach den restlichen Informationen gefragt werden und diese Daten dann in der Raumtabelle gespeichert werden. Der Nachteil dieser Vorgehensweise ist zum einen das Zerreißen der Datenerfassung und zm Anderen besteht die Möglichkeit, dass der Benutzer, der aktuell die Daten erfast, über die abgefragten Zusatzdaten nicht verfügt.




Die Auswahl der "richigen" Vorgehensweise ist von der konkreten Aufgabenstellung abhängig.