Ich hab schon vor einiger Zeit mir mal die CCD Armbänder bestellt und trage jetzt seit etwa 3 Wochen das rote Band an meinem Arm. Ehrlich gesagt hilft dieses Band wenig, mich während der Arbeit an die Regeln zu erinnern – eher ist es schlechter Code der mich daran erinnert. Ich find die Bänder aber ein bisschen stylisch und hab deshalb auch das schwarze Band ständig an meinem Arm. :-)

Auf jeden Fall bin ich gerade mal die Liste der Prinzipien und Praktiken für den Roten Grad durch gegangen und dabei ist mir mein fatalster Fehler aufgefallen: Ich reflektiere nicht! Das ist auch der Grund, warum ich das Prinzip Favour Composition over Inheritance (FCoI) total unter den Tisch habe fallen lassen. Kein Wunder, dass mir in meinem Posts „private Methoden vermeiden“ nicht aufgefallen ist, dass Vererbung in vielen Fällen gar nicht angebracht ist.

Ansonsten kann ich im Nachhinein sagen, dass ich die anderen Regeln gut einhalten konnte:

  • DRY: Ich liebe dieses Prinzip und es ist mir ins Blut übergegangen. Da muss ich eher aufpassen, dass ich es nicht übertreibe! ;)
  • KISS: Das mach ich meiner Meinung nach sowieso, da ich nicht so der akademische Typ bin und ich zufrieden bin, wenn der Code funktioniert und gut aussieht. Obwohl ich mir vielleicht manchmal mehr Gedanken über eine Lösung machen sollte, anstatt einfach alles auszuprogrammieren. Dies endet nämlich oft in verschachtelten Schleifen die nur noch anhand Ihrer Kommentare zu entziffern sind.
  • Vorsicht vor Optimierung: Davon lass ich generell die Hände weg. Die Gründe sind ähnlich wie im vorherigen Punkt. Die einzige gern gesehene Optimierung ist bei mir Refaktorisierung!
  • Favour Composition over Inheritance (FCoI): Wie schon im einleitenden Text erwähnt, hatte ich diesen Punkt total übersehen. Aber ich denke, dass genau hier zu oft strukturelle Fehler entstehen. Zumindest konnte ich das so bei mir feststellen.
  • Pfadfinderregel beachten: Meiner Meinung nach die beste Regel um alle Praktiken und Prinzipen zu üben: Dreckigen Code aufräumen. Damit gewöhnt man sich schnell ab, selber ekligen Code zu schreiben. Zumindest tut es ganz arg im Hirn weh, wenn man man doch schnell mal etwas hinhackt! ;)
  • Root cause analysis: Das ist eine Sache, an der ich noch einiges arbeiten muss. Denn schneller ist ein Workaround gebaut, als der eigentliche Bug entfernt. Liegt aber auch daran, dass ich in der Dienstleistung und nicht in der Entwicklung arbeite. Da hab ich einfach kein Zeit mit meinem lahmen Rechner die Dependency Projekte zu debuggen, den Fehler zu beheben und dann alles noch hoch zu laden. Wenn es auch noch ganz schlecht läuft, bin ich dann für die Folgefehler verantwortlich und es geht noch mehr Zeit drauf! Meine Alternative: Workaround bauen und den Bug ins Tracking System eintragen.
  • Ein Versionskontrollsystem einsetzen: SVN ist cool! Mehr hab ich nicht zu sagen. Zum Glück darf ich es einfach nur verwenden. (Danke Edu)
  • Erste Refaktorisierungsmuster anwenden: Im roten Grad bedeutet das nur Methoden extrahieren (=> DRY) und Umbenennen. Beides habe ich sehr oft gemacht in letzter Zeit und bin daher ziemlich zufrieden mit mir.
  • Täglich reflektieren: Hatte ich bisher leider vergessen. Vor allem, wenn ich kurz vor Feierabend noch schnell was machen muss und dann einfach keine Lust mehr hab länger zu bleiben. Aber ich denke, dass ich es damit nachgeholt hab. Mal sehen, ob ich es zukünftig besser umsetzen kann.

Mein Fazit: Diese Woche noch roter Grad – nächste Woche widme ich mich dann dem orangenen zu.

Advertisements