Probleme beim Einloggen
Martin Mayr Auf dem Weg in eine bessere Welt
Hallo zusammen,
ich bin 26 und gehöre zu der Generation, bei der Windows und PCs schon Standard waren, als sie anfingen sich mit der Welt der Informatik zu beschäftigen. Meine Anfänge in der Programmierung bestanden vor 8 Jahren aus der Entwicklung einer Access-Datenbank für di e Buchhaltung eines befreundeten Musikvereins.
Die Arbeit an diesem Datenbank hatte mich so fasziniert, dass ich beschloss mich ganz der Informatik hinzugeben. Da mir ein Nachholen des Abiturs und anschließendes Studium zu lange dauerten, habe ich kurzerhand die Gelegenheit ergriffen, in einer kleinen Softwarefirma eine Lehre als Fachinformatiker/Anwendungsentwicklung zu machen.
Die Ausbildung hatte den Vorteil, dass ich von Anfang an in der Praxis aktiv sein konnte, jedoch auch den Nachteil, dass in diesem Betrieb VB6-Spagetti-Code als Maß aller Dinge galt. Ein Umstand der in mir ein ständiges Unwohlsein schwelen ließ.
Seit dieser Zeit beschäftigt mich die Frage, wie ich Code verständlicher und weniger fehleranfällig gestallten kann. Primär versuchte ich mich bisher mit diverser Literatur und „learning by doing“ weiter zu entwickeln (ein steiniger Weg). Auf der Suche nach Antworten bin ich auch auf diese Gruppe/Bewegung gestoßen.
Auch ich habe die schmerzhafte Erfahrung gemacht, dass zu viel auf einmal zu wollen, wahrscheinlich zu enttäuschenden Ergebnissen führt. Also kleine Schritte. Aber wie? Jetzt habe ich in CCD eine Orientierung gefunden, wie eine Weiterentwicklung aussehen könnte und bin fest entschlossen die Prinzipien Stück für Stück umzusetzen.
Optimistische Grüße
Martin
Ralf Westphal Spieglein, Spieglein - Iteration, Review, Issue Tracking
Und wann tun Sie es? Wann wenden Sie das Urprinzip und seine "Ableitungen" auf Ihren Code an? Das ist ja auch nur der Anfang. Andere Prinzipien und Regeln kommen dazu, die auf Ihren Code einwirken.
Befolgen Sie das Urprinzip ständig?
Bei der Versionskontrolle ist das nicht so schwierig. Einfach kontinuierlich während der Entwicklung kleine Verbesserungen einchecken. Nicht einmal am Ende des Tages oder gar am Ende der Woche. Nein, immer wenn Sie einen kleinen Erfolg verbuchen können. Sie erreichen im Verlauf der Implementierung eines Features einen stabilen Punkt? Die Tests sind grün? Dann einchecken.
Auch der Zeitpunkt für automatisierte Tests ist nicht schwer zu bestimmen. Er ist immer. Sie testen ständig. "Code a little, test a little" sagte schon weiland Kent Beck (http://members.pingnet.ch/gamma/junit.htm).
Dito bei der automatisierten Produktion. Die ist auch immer. Deshalb heißt sie ja Continuous Integration. Darüber müssen Sie sich sogar am wenigsten Sorgen machen. Sie läuft im Hintergrund ohne Ihr Zutun.
Wie ist´s nun aber mit der Anwendung der Prinzipien? Achten Sie ständig darauf, DRY zu sein, während Sie ein Feature X implementieren? Streben Sie gleichzeitig Funktionalität/Korrektheit und Innere Qualität an?
Nein. Innere Qualität ist eine Invariante. Das bedeutet, sie muss nicht ständig vorhanden sein, sondern nur am Ende einer Veränderungsperiode. So wie am Ende einer Transaktion die Daten konsistent sein müssen, zwischendurch aber nicht notwendig, so müssen auch die Prinzipien nicht zu jeder Sekunde alle voll eingehalten sein.
So gilt denn auch "Red, green, refactor", d.h. erst korrekte Funktionalität, dann Innere Qualität. Prinzipien müssen erst angewandt werden/sein, wenn die Funktionalität stimmt. Dann ist es Zeit, die korrekte Funktionalität in der Inneren Qualität anzuheben.
Das kann im täglichen Implementierungswahnsinn nach 15 Minuten oder 1 Stunde sein. Sie können eine Refaktorisierung als Prinzipienanwendung also quasi als Pause einplanen. Sozusagen zur Entspannung Qualität schaffen.
Was Sie da so im Tagesgeschäft erreichen in Bezug auf Innere Qualität, wird seine Grenzen haben. Erwarten Sie nicht, dass Sie größere Qualitätsprobleme in diesen "Miniiterationen" von Code-a-little()-Test-a-little(red-green)-Refactor()-Code-a-little()-... aus dem Code räumen können. Dazu sitzt Ihnen die funktionalitätstreibende Kraft zu sehr im Nacken. Dennoch sollten Sie Pausen zur Refaktorisierung des Überschaubaren einlegen.
Erwarten Sie auch nicht, dass Sie größere Qualitätsprobleme überhaupt im Tagesgeschäft sehen. Dafür sind Sie womöglich zu betriebsblind.
Es bleibt also die Frage: Wann tun Sie es? Wann räumen Sie die größeren "Design Issues" aus dem Code?
Die Antwort ist einfach: ebenfalls nach einer bzw. im Rahmen einer Iteration. Nach dem Urprinzip ist der nächste CCD-Baustein auf Ihrem Weg daher die Einführung von Iterationen. Die müssen nicht im Sinne von Scrum echte Sprints sein. Mit Absicht haben wir darauf im CCD-Wiki auch keinen Bezug genommen. CCD-Iterationen sind noch einfacher: Es geht nur darum, dass Sie sich einen Zeithorizont schaffen, der im Bereich 1 bis 3 Wochen liegt, in dem Sie wasimmer Sie wollen, wiederholt einplanen können.
Alles, was Sie nicht vergessen wollen, planen Sie in Iterationen ein. Alles, worüber Sie nicht ständig wieder diskutieren wollen, planen Sie in Iterationen ein. Im roten Grad haben wir das für Sie schon getan. Der definiert als kleinste Iteration den Tag. Und am Ende jedes Tages reflektieren Sie über die Einhaltung der CCD-Bausteine. Jeden Tag. Immer. Ohne nachzudenken. Ganz unemotional.
Für Ihr Projekt tun Sie das dann z.B. wochenweise. Sie definieren als Teamiteration 5 Tage und setzen z.B. auf den Mittwoch Nachtmittag einen Codereview. Wieder ein CCD-Baustein. Indem Sie ganz einfach laut Plan, der jedem zugänglich ist, jede Woche einmal einen Codereview machen, wissen Sie, wann Sie größere Qualitätsprobleme finden: immer wieder Mittwochs. Mindestens.
Und damit wissen Sie auch, wann Sie das Urprinzip anwenden: am Donnerstag. Denn nach dem Codereview ist die größere Refactorisierung. Wasimmer Sie an Veränderungswürdigem während des wöchentlichen Codereviews finden, das tragen Sie - nächster CCD-Baustein - in Ihr Issue Tracking Tool ein und erledigen es schnellstmöglich. Am besten gleich donnerstags.
Takten Sie Ihre Arbeit! Denn wenn Sie erstmal einen offiziellen Takt (Iteration) haben, dann müssen Sie nicht fürchten, die CCD-Prinzipien allzulange zu vernachlässigen, selbst wenn es mal im Tagesgeschäft noch höher hergeht. Und Sie müssen auch nicht ständig wieder mit Kollegen oder dem Chef darüber diskutieren, mal wieder einen Review (Reflektion des Codes) oder eine Retrospektive (Reflektion des Prozesses) einzulegen. Die sind einfach ganz regelmäßig dran.
Achten Sie nur darauf, dass die Ergebnisse solcher Reflektionen ins Issue Tracking Eingang finden wie jeder Featurerequest des Kunden. Da darf es keinen Unterschied geben. Verschieben Sie das Refaktorisierung also nach dem Aufdecken von "Code Smells" nicht, sondern nehmen Sie sie in Angriff. Sonst wird es nur schlimmer!
Jetzt sind Sie gerüstet für mehr Prinzipien, Regeln und Praktiken. Sie haben ein Sicherheitsnetz für angstefreie Arbeit am Code, sie erkennen erste "Problemzonen" (oder sollte ich sagen: Feuchtgebiete? ;-) - und Sie wissen, dass Sie die Problemzonen garantiert angehen: der Testbalken muss nur grün werden oder die Iteration enden. Reflexion ist das Zauberwort.
-Ralf Westphal
Ralf Westphal Das Urprinzip - DRY und seine Spezialisierungen SRP und SoC
Was tun mit all der hergestellten Testbarkeit? Versionsverwaltung + automatisierte Tests + automatisierte Produktion sind ja nur ein Rahmen für angstfreie Veränderung. Wohin aber den Code verändern? Was unterscheidet Code mit hoher "innerer Qualität" von Legacy Code?
Wie wesentlichen Antworten im Leben ist die auf diese Frage auch einfach:
Hohe "innere Qualität" zeichnet sich vor allem durch die Abwesenheit von Wiederholungen jeder Art aus.
Und wie alle wesentlichen Antworten im Leben bedarf auch diese der Interpretation und stetiger Anstrengung, ihr gerecht zu werden.
Das zu dieser Antwort passende Urprinzip ist DRY: Don´t Repeat Yourself. Es hat nicht umsonst Aufnahme in den roten Grad gefunden. Wiederholungen sind zu vermeiden, weil jede Wiederholung den Keim der Inkonsistenz in sich trägt. In der Datenbankentwicklung ist Normalisierung nicht umsonst ein zentrales Thema. Für die Codeentwicklung ist DRY das Pendant. (Ja, das bedeutet auch, dass gelegentlich Code moist/feucht sein darf, so wie Datenbankschemata auch gelegentlich bewusst denormalisiert sind. Beides sollte aber nur mit Bedacht zugelassen werden.)
Sobald Ihr Code im Rahmen der Angstfreiheit aufgehängt ist, beginnen Sie also am besten mit der Suche nach den offensichtlichen und dann den subtilen Wiederholungen.
Wiederholungen können winzig sein wie eine Zahlkonstante im Code. Oder sind können ausgedehnt sein wie ganze Klassen - die sich dann natürlich irgendwie schon unterscheiden. Wirklich 1:1 wiederkehrende Codeabschnitte sind kaum mehr als einige Zeilen lang. Am Anfang mag zwar oft auch bei längeren Wiederholungen ein 1:1 Copy&Paste stehen - doch der kopierte Code wird meist an seinen neuen Kontext angepasst, so dass er nur noch ähnlich zum Original ist.
Der Übergang von der offensichtlichen zur subtilen Wiederholung ist also fließend und recht schnell. Sie müssen also Ihre Wahrnehmung dafür sensibilisieren, mehr oder weniger ähnliche Codeabschnitte zu entdecken. Insofern warten Sie auch vergeblich darauf, dass Tools Sie entscheidend bei der "Austrocknung" Ihres Codes helfen. Die Muster, um die es geht, sind eher logisch/semantisch denn textuell/syntaktisch.
Auf der nächsten Stufe verliert sich dann sogar jede handfeste Spur von Wiederholung. Über die sichtbaren Wiederholungen von Artefakten hinaus gibt es nämlich auch die von Bedeutungen. Ein Beispiel: In den Eventhandlern eines Fensters finden Sie an vielen Stellen Zugriffe auf die Datenbank. Die sehen alle ganz, ganz anders aus, weil es in jedem Eventhandler um andere Daten geht. Dennoch liegen Wiederholungen vor! Die Bedeutung dieser Abschnitten mit DB-Zugriff ist gleich: es geht eben wiederholt um DB-Zugriff.
Die Verantwortlichkeit von Code für den Umgang mit der Datenbank wiederholt sich, auch wenn die Anweisungen sehr verschieden sind. Wenn sich an dieser Grundverantwortlichkeit etwas ändert, dann muss womöglich an vielen, sich ansonsten unähnlichen Stellen nachgezogen werden.
Das DRY-Prinzip ist somit das Urprinzip unterhalb des Single Responsibility Principles (SRP). Im Sinne von Occams Skalpell könnte das Clean Code Developer Bausteinsystem deshalb sogar auf SRP verzichten. Es wiederholt in anderen Worten letztlich nur, was DRY schon beschreibt. DRY ist umfassend; es bezieht sich auf jede Art von Wiederholung. SRP ist spezifischer, indem es auf semantische Wiederholungen fokussiert.
Dasselbe gilt für dann auch für das Separation of Concerns Prinzip (SoC), welches wiederum aus SRP hervorgehend gedacht werden kann. SoC ist noch spezifischer als SRP, weil Concerns eine Untermenge aller Verantwortlichkeiten sind. Verantwortlichkeiten sollen nur verschieden sein; Concerns/Belange jedoch sind sogar noch orthogonal zueinander.
Wenn Sie in den Eventhandlern eines WinForms-Formulars zum Beispiel Code zu den Themen:
-Graphische Anzeige
-Datenbankzugriff
-Geschäftslogikberechnung
-Validation
-Menüsteuerung
-Sicherheit
-Geschäftsregeln
finden, dann sind das alles natürlich unterschiedliche Verantwortlichkeiten. SRP verlangt dann nur, sie alle irgendwie zusammenzufassen.
SoC geht jedoch weiter. Für SoC stehen manche Verantwortlichkeiten in einer Linie oder liegen in Schichten aufeinander, z.B.
-Graphische Anzeige, Menüsteuerung
-Geschäftslogikberechnung, Geschäftsregeln
-Datenbankzugriff
Andere Verantwortlichkeiten jedoch lassen sich zwar absodern, nicht jedoch eindeutig in dieser Linie oder einer Schicht verorten. Das sind dann orthogonale oder übergreifende Belange wie z.B.
-Validation
-Sicherheit
Wie eingangs erwähnt, brauchen gerade einfache Antworten immer wieder Interpretation, um echt handlungsleitend zu werden. SRP und SoC sind in diesem Sinn als Auslegungen zu verstehen. Deshalb belassen wir sie auch im CCD-Bausteinsystem.
Sobald Sie Testbarkeit hergestellt haben und Ihrem Code mehr "innere Qualität" geben wollen, machen Sie sich auf die nimmerendende Suche nach Wiederholungen. Das leitende Urprinzip ist DRY mit seinen Konkretisierungen SRP und SoC.
-Ralf

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 5.051
  • Sichtbarkeit: offen
  • Beiträge: 493
  • Kommentare: 2.993