Clean Code
Seit einiger Zeit bin ich ein großer Fan der Clean-Code-Prinzipien.
Auch wenn man - besonders als Access-Entwickler - nicht wirklich alle Prinzipien und Praktiken beherzigen und umsetzen kann, verhilft das Ganze dem eigenen Code doch zu einem erheblichen Gewinn in Sachen Lesbarkeit, Erweiterbarkeit und Wartbarkeit.
Wie oft hat man schon Stunden mit dem Studium von Code zugebracht und bei sich gedacht "welcher Vollpfosten hat das nun schon wieder verbrochen" ... nur um dann irgendwann festzustellen: Das war eigener Code, den man in einem Anfall von geistiger Umnachtung eingehackt hat.
Wem es hier ähnlich geht, der sollte sich einmal eingängig mit den Prinzipien und Praktiken beschäftigen, die u.a. von "Clean-Code-Developers" oder von Robert C. Martin (Uncle Bob) in seinem Standardwerk "Clean Code" vorgestellt werden.
Für mich steht die Lesbarkeit von Quellcode ganz oben auf der Prioritätenliste. Gut lesbarer Code ist die Grundbedingung für gut wart- und erweiterbaren Code.
Dabei gilt das nicht nur für die reine Form des Codes ... die Lesbarkeit von Code ist meiner Ansicht nach die Summe aus:
- Naming matters
Die Benennung von Methoden, Variablen und Konstanten macht einen großen Teil der Lesbarkeit aus. Sparsamkeit schadet hier eher als dass sie nützt. - Format matters
Neben der Benennung spielt die Formatierung des Quellcodes eine mindestens gleichwertige Rolle. Nur gut formatierter Code lässt sich auch flüssig lesen.
Als Nächstes steht die Erweiterbarkeit auf der Liste. Aber hier wird's bereits schwierig und hier widersprechen sich die Prinzipen von Clean Code bereits zum ersten Mal.
So soll doch nach dem Motto "You ain't gonna need it" nur das implementiert werden, was explizit gefordert ist (also das, was der Kunde zahlt).
Auf der anderen Seite sind im Entwurf natürlich bereits Vorkehrungen für die zukünftige Erweiterbarkeit zu treffen. Was aber, wenn dies (noch) nicht gefordert ist und der Kunde diese Weitsicht nicht bezahlen möchte?
Man muss für sich selbst hier wohl den goldenen Mittelweg finden und sich auf seine Erfahrungen verlassen.
Oft wird das Thema Erweiterbarkeit aber auch völlig übertrieben und ein zu allen Seiten offenes System entworfen.
Das ist wohl in den seltensten Fällen explizit gefordert und schnell hat sich aus solchen extrem offenen und erweiterbaren Entwürfen ein neues Problem ergeben: Das Ganze wird so komplex, dass an allen mögliche Ecken und Enden Fehler auftreten.
Daher die Empfehlung für ein weiteres Prinzip aus Clean Code: KISS = keep it simple, stupid!
Einfache Konstrukte sollten in der Regel bevorzugt werden. Natürlich kann man mit Tricks und Schweinereien auch noch das allerletzte an Performance rausholen, aber in der Mehrzahl der Fälle handelt man sich damit mehr Nach- als Vorteile ein. Lieber ein wenig zu simpel gedacht und ein bisschen "old school" programmiert, als sich "auf Teufel komm raus" in Interfaces und Zeiger-Referenzierungen verrennen, durch die später niemand mehr durchblickt.
Im Übrigen holt man durch Änderungen im Code selbst nur selten wesentlich mehr Performance heraus. Die wird im Grunde hauptsächlich durch das Applikationsdesign bestimmt. Tief im Code ist hier kaum noch etwas zu optimieren.
Und für die Datenbankentwickler gilt: Die Performance bestimmt sich hier primär über die Geschwindigkeit des Datenbankzugriffs. Hier ist also viel eher das Augenmerk auf Optimierungen zu richten. Wer seine SQL-Statements vergurkt, braucht im Code seiner Anwendung nicht nach Optimierungen zu suchen.
Tags: Clean Code, Anwendungsdesign, Architektur, Performance, Lesbarkeit, Wartbarkeit, Erweiterbarkeit