Tag Archives: Entwicklung

Von der Kunst der Vereinfachung

Posted on by

Abstrahieren und vereinfachen liegt in der Natur des Menschen. Wir alle haben es natürlich gerne wenn eine Aufgabe „leicht“ zu bewältigen ist oder ein Sachverhalt „einfach zu begreifen“ ist. Eine grundlegende Eigenschaft dabei ist es, dass wir Dinge „ausblenden“ die für die aktuelle Aufgabe nicht relevant sind oder deren genaue Zusammenhänge wir nicht bis ins Detail verstanden haben müssen um die Aufgabe zu lösen oder den Sachverhalt zu verstehen. Oftmals reicht es auch aus, die Hintergründe einmal umfassend bearbeitet zu haben und dann mit den gewonnenen Erkenntnissen und ggf. auch Erfahrungen weiter zu arbeiten. Jeder der ein Kraftfahrzeug fährt, hat sich (hoffentlich) einmal mit der dahinter stehenden Physik beschäftigt – doppelte Geschwindigkeit vervierfacht die Energie usw. Das alles setzt ein geübter Fahrer zusammen mit ggf. weiteren Erfahrungswerten ein um sein Fahrzeug im Verkehr sicher zu führen.

Wir Menschen sind auch Meister darin immer mehr dieser Denkarbeit zu automatisieren und uns somit das Leben noch leichter zu machen. Waren die ersten Computer noch groß und nur mit dem notwendigen Fachwissen zu bedienen, so benutzen wir heute fast schon wie selbstverständlich ein Smartphone dessen technische Komplexität um mehrere Größenordnungen über den ersten Großrechnern oder gar Heim-PCs liegt. Durch den Einsatz von Technik und entsprechenden Schnittstelle (der Fachmann spricht vom User-Interface) kann heute jeder mit minimalen Vorkenntnissen ein Smartphone zumindest grundlegend bedienen. Natürlich gibt es auch weiterhin die PowerUser bzw. Spezialisten die nochmals mehr aus dem Gerät „herausholen“ bzw. auch bei bestimmten Fehlerbildern Abhilfe schaffen können (oder zumindest einmal wissen wo man nachschlagen kann um ein Problem zu beheben). Continue reading →

Drei Monate und ein wenig Papa

Posted on by

Wahnsinn, wie die Zeit verflogen ist. Die Elternzeit und Urlaub sind schon etwas mehr als einen Monat vorrüber. Das Alltagsleben hat sich also (mit ein wenig Verzögerung wegen Grippe) wieder eingespielt.

Dem Sohnemann geht es  gut, das ist die Hauptsache. Wir beobachten fleißig Fortschritte die er immer  wieder macht – jedesmal sind wir etwas erstaunt und freuen uns natürlich total. Mit dazu beigetragen hat sicherlich auch der Kontakt mit Gleichaltrigen beim PEKIP zusammen mit den Anregungen die wir dort gemacht haben.

Zu meinem Leidwesen gehören zum PEKIP auch jede Menge Kinderlieder – nicht das die schlimm oder peinlich wären, aber die begleiten mich seitdem immer wieder als Ohrwurm… Zu einigen fallen mir dann auch immer noch die verballhornten Varianten ein, die wir selbst als Kinder gesungen haben. Besonders lästig sind mir dann Rythmen die auch noch zu meinem Laufstil passen – morgens PEKIP mit Singen und Abends jogge ich dann zum Beispiel zu „drei kleine Fische …“ Innerlich hoffe ich, dass er möglichst bald zu „vernünftiger“ Musik findet (einiges spielen wir ihm ja dann doch auch mal vor, oder wenn mir nichts besseres zum Einschlafen mehr einfällt, dann singe ich auch mal etwas aus meiner Collection vor).

In der Arbeitswelt ergibt sich vielleicht demnächst eine Veränderung für mich. Der Abstand mit der Elternzeit hat mir auch die Chance gegeben, etwas zu reflektieren. Um so mehr sind mir Ärgernisse und Schwachtellen aufgefallen, an denen ich wohl nichts mehr ändern kann, weil sie nicht meine eigene Arbeit betreffen sondern die Art und Weise wie gearbeitet wird. Vor allem der regelmäßige Austausch mit anderen informatik-affinen Personen die auf meinem Level sind, ist ein Mangel der mir auf die lange Sicht doch etwas zu schaffen macht. Noch heißt es abwarten, aber ich denke im Laufe des Jahres wird sich hier eine Veränderung ergeben – auch wenn das mal wieder viel auf einmal ist.

 

 

So bitte nicht – bad / worse practices

Posted on by

Nachdem ich mich immer wieder mal grün und blau (und nicht blau weil ich beim THW tätig bin) über diversen Software-Design-Schwachsinn ärgere, habe ich mich entschlossen in loser Folge immer einmal wieder eine schlechte Art der Programmierung / Modellierung und natürlich auch Wege wie man es besser machen kann vorzustellen.

Für heute will ich erst einmal mit einigen Grundlagen beginnen, die sicherlich nicht nur für die Programmierung und Software-Entwicklung hilfreich sind, sondern für jeden der ein Projekt in irgendeiner Form betreut.

Ad 1) Klar festlegen was ich eigentlich will – jeder hat es sicherlich schon mal erlebt: „So hab ich mir das aber nicht gedacht gehabt …“ Die Ursache ist meist leicht gefunden: Es mangelt an klarer und eindeutiger Vorgabe – da gehört hinein was man will, aber auch was man gerade nicht will. Es ist sicherlich nicht immer leicht alles möglichst eindeutig und klar zu beschreiben, aber alleine wenn man sich darum bemüht ist schon eine große Menge Missverständnissse aus dem Weg geschafft

Ad 2) Klare Definitionen und einheitliches Vokabular: Jeder Mensch ist einzigartig, mit all seinen Vorlieben, Stärken, Schwächen und Erfahrungen. All diese Einflüsse prägen uns und haben eine Auswirkung auf die Rezeption und Reaktion gegenüber unserer Umwelt. Daher ist es keineswegs selbstverständlich das jeder unter einen Begriff anfänglich genau das gleiche versteht und ihn genauso abgrenzt wie ein anderer Mitarbeiter. Daher klar festlegen was unter einem bestimmten Begriff zu verstehen ist, und was nicht – es mag lästig erscheinen jede Entität und deren Bedeutung im Prozess-Zusammenhang einmal ausführlich zu beleuchten und zu beschreiben, aber es macht im weiteren Verlauf das Leben deutlich leichter. Wichtig ist hierbei: Jeder muss das Vokabular auch entsprechend anwenden, was abgestimmt wurde ist fest, ein „aber ich hab doch eigentlich 0815 anstelle 4711 gemeint“ ist ein absolutes no-go

Ad 3) Kenne deine Werkzeuge: Nicht jeder in einem Projekt muss mit jedem Werkzeug umgehen können – eine Führungskraft muss nicht zwingend mit einem Code-Editor und Compiler hantieren (es schadet nichts wenn sie sich dennoch einmal damit auseinander setzt), aber das tagtägliche Handwerkszeug mit den Routine-Funktionen muss nahezu blind bedienbar sein. Dazu muss auch klar sein: Für welchen Zweck welches Werkzeug? (Das kann von Projekt zu Projekt ein wenig schwanken, auch hier hilft es ggf. niederzulegen welche Mittel zur Verfügung stehen und für welchen Zweck benutzt werden sollen). Wichtig ist gerade in der Software-Entwicklung der sichere Umgang mit der persönlichen Entwicklungsumgebung (da kann jeder Entwickler verwenden was er für richtig hält, es sei denn es gibt zwingende Vorgaben. Gerade im Code ist es aber egal ob jemand eine vollwertige IDE wie Netbeans, KDevelop, Eclipse verwendet oder doch lieber einen schlichten Text-Editor mit ein wenig Syntax-Highlighting. Ebenso gehört der Umgang mit Team-Werkzeugen wie e-mail, Versionskontrolle, Bugtracker, Requirement-Management etc. zum Routine-Werkzeug. Hier muss ggf. geübt werden, aber nach einer gewissen Zeit darf es kein Bremsklotz mehr sein. Für die Arbeit am Rechner empfiehlt sich auch ein flüssiges Tippen und Arbeiten mit reduziertem Mauseinsatz (Shortcuts).

Ganz wichtig: Die ganzen Punkte da oben gelten für alle im Projekt, Neueinsteiger oder auch weitere Führungsebenen muss man da etwas heranführen und klar kommunizieren wie der Hase läuft. Absolut hinderlich ist es, wenn Leute die sehr viel an einem Projekt mitwirken diese einfachen Regeln nicht gebacken bekommen. Das geht auf die Nerven und somit auf die Performance des restlichen Teams.

So weit mal für den Anfang, wie geschrieben: in loser Folge kommen weitere Grausamkeiten der Software-Entwicklung (alles leider Dinge die man immer wieder erlebt, auch das oben ist keineswegs aus den Fingern gesaugt).

Quick’n’Dirty in MySQL und anderen Datenbanken

Posted on by

Heute habe ich mich mal wieder einer Altlast der Datenbankentwicklung hingegeben, da sich einige Veränderungen ergeben hatten. Ich hatte schon mehrfach, die Hoffnung diese Tabellen der Datenbank endlich einmal längere Zeit in Ruhe lassen zu können um mich neuen Funktionen zu widmen – aber Pustekuchen wars.

Also wieder das Design auf den Prüfstand und schauen wie man es an die neuen Anforderungen anpassen kann. Ich weiß, dass ich vor etwa einem halben Jahr noch mit einem Freund und ausgesprochenen Experten in Sachen Datenbankdesign mich über einige Dinge ausgetauscht habe. An einigen Stellen hatte ich mich für geschickt gehalten bzw. wollte an dem Design nicht mehr übermäßig rütteln. Es hat ja auch alles soweit funktioniert und gerade die Schlüsseldefinitionen folgten auch einer gewissen Logik. Ich hatte mich für einen kombinierten Schlüssel entschieden – ein referenziertes Objekt kann zu einem Zeitpunkt (auf die Sekunde genau) nur an einer Stelle sein – für den Anwendungsfall eine absolut zutreffende Annahme. Zudem hatte ich den Schlüssel dann auch noch über mehrere Tabellen als Fremdschlüssel „durchgeschleift“ – vom damaligen Standpunkt aus war das eine mögliche Lösung die mir eigentlich auch gut gefiel – löste sie doch elegant auch diverse Bezugsprobleme, bzw. ich konnte einen Trigger verwenden um die notwendige Abhängigkeit einer Tabelle von einer anderen automatisch aufzulösen. Es gab also die Basis-Tabelle, eine erweiterte Tabelle und eine Tabelle die in vergleichsweise wenigen Fälle sich auf die erweiterte Tabelle stützte – ein klassisches Prozessgefälle – aus vielen kleinen Datensätzen werden am Ende nur wenige bis zur Blüte oder gar Reife gebracht.

Nun, die Anforderungen haben sich verschoben und die  mittlere/erweiterte Tabelle musste angepasst werden. Wie sich gezeigt hatte brauchten wir für eine spezielle Auswertung nicht nur eine Referenz auf die Basis-Tabelle sondern mindestens zwei, nach eingehender Analyse bin ich auf vier gekommen. Dies liegt in der Tatsache begründet, dass die erweiterte Tabelle eigentlich ein Zusammentreffen mehrer Datensätze aus der Basis-Tabelle abbildet. Das ist mir aber erst im Laufe der weiteren Entwicklung klar geworden – ich denke ich habe das auch beim letzten Mal eher „on the fly“,“mal eben schnell“, „quick’n’dirty“ entwickelt ohne die wahren Beziehungen zu erkennen. Was will man machen – so manches wird einem eben erst im Laufe der Zeit klar.

Erste Konsequenz – der ursprünglich ach so geschickte natürliche Schlüssel über zwei Spalten war nun nicht mehr tragbar – viel zu umständlich: für vier mögliche Referenzen wären es acht Spalten gewesen – Übersichtlichkeit gegen null, zumal die Aussagekraft der jeweiligen Schlüsselpaare zum Gesamtbild nur vergleichsweise wenig beiträgt.- und selbst wenn man es braucht – gejoint ist es dank Indizierung und Foreign Keys doch recht fix. Daher bekommt die Basis-Tabelle neben den natürlichen Spalten ein Surrogat – einen eindeutigen numerischen Primärschlüssel. Wie leicht der einem die Arbeit im weiteren macht ist mir bei der Anpassung des Programmcodes dann aufgefallen.

Wie mit der erweiterten, nunmehr ja eher aggregierenden Tabelle weiter verfahren – außer den vier Spalten für die Referenz – ein natürlicher Primärschlüssel über vier Felder schien mir doch recht gewagt, zumal diese Referenzen sich auch mal im Nachinein noch verändern können. Also auch hier die „künstliche“ Variante mit einem Surrogat.Das entschlackt auch die letzte Tabelle in der Reihe – deren Referenz musste ja auch wieder irgendwie hergestellt werden – nachdem der ursprünglich „durchgereichte“ Schlüssel ja nicht mehr da war musste da eh etwas neues her – auch hier erweist sich die Lösung per Surrogat doch recht tauglich.

Lehrwerte dieser Aktion:

Erstens – natürliche Schlüssel haben einen gewissen Charme – auch wenn sie zur Not aus zwei Spalten bestehen – moderne Datenbank-Systeme stecken das recht gut weg, auch was die Performance betrifft.

Zweitens – eine sorgfältige Analyse und Diskussion eines Entwurfs und die Bedeutung eines Objekts im Gesamtzusammenhang ist durch nichts zu ersetzen – leider zeigt sich hier mal wieder, dass es in meinem Fall keinerlei Prozessdefinition gab und somit natürlich auch die Artefakte nur sehr lückenhaft beschrieben waren. Ein Pflichtenheft wurde aus Kostengründen auch nicht erstellt – stattdessen gab es eine Alt-Datenbank an der man sich orientieren sollte – in bestimmten Dingen war das Design eine Anleitung „wie man es tunlichst nicht machen sollte“ (bei Gelegenheit werde ich dazu mal noch ein paar Zeilen schreiben). Auf einem solchen weichen Untergrund ein solides Fundament und hinterher ein Gebäude zu errichten ist nahezu unmöglich – irgendwo sackt es am Ende doch unangenehm weg.

Drittens – Surrogate sind im ersten Moment oftmals hinderlich und an einigen Stellen „verstellen“ sie teilweise den Blick aufs Wesentliche – man muss sich ggf. die weiterführenden Informationen aus anderen Tabellen erst mal zusammen suchen. Aber sie haben auch eine Menge Vorteile in Sachen Eindeutigkeit und Handhabbarkeit – wenn es einen eindeutigen Wert gibt, erleichtert dass das Auffinden eines Datensatzes und das Instanzieren eines Objekts daraus ganz erheblich.

Mal sehen welche alten Entscheidungen ich demnächst wieder ausgraben muss und mich über meine eigene Schusseligkeit wundern/ärgern darf. In diesem Sinne: Augen auf beim Datenbank-Design.