Design-Guidlines

Was bringen einem eigentlich Design-Guidlines, also Richtlinien für das Programmieren, Schreiben und Entwerfen von Sourcecode? Nun ganz einfach. Es trägt zur einfacheren Lesbarkeit der vorhandenen Quellen bei. Es sind Vorgaben, die dem Entwickler und Teammitgliedern helfen, den vorliegenden Code besser zu verstehen. Das war schon in Zeiten von Win32 und MFC so und das ist auch in Zeiten von C# so. Früher war Ungarische Notation "IN". Heute steht es auf der Liste der "DONT'S" und ist somit ein absolutes "NO GO". Wie komme ich dazu? ...

Nach einer kurzen und auch unterhaltsamen Diskussion über Codedesign vor ein paar Wochen hatte ich mich auf Google umgeschaut, was so von Microsoft kommt. Ich hatte mir schon einmal die Guidlines vor ca. 3 Jahren durchgelesen und wusste daher auch, dass es entsprechende Dokumente gibt. Auf Amazon findet sich z.B. dieses Buch hier in dem die Framework Design-Guides beschrieben sind. Diese kommen von Brad Abrams (hier sein blog). Er hat sie für das .NET Framework entwickelt. Von Microsoft gibt es diese Guidlines direkt in der MSDN. Wer immer auf dem neuesten Stand bleiben will, sollte von Zeit zu Zeit bei den Jungs von der Base Class Library (BCL) vorbei schauen.

Ob alles Gold ist, was glänzt bleibt im Raum stehen. Sicher ist jedoch, dass sich viele an diese Guidlines halten und auch der Open-Source-Code in der freien Welt sich stark danach richten. Auf der Microsoft-Plattform Codeplex, aber auch auf SourceForge.net oder auch Community Seiten wie www.codeproject.com sieht man Entwickler aus aller Welt, die diesen Stil verwenden. Nun ich muss sagen, seit dem ich es auch so praktiziere hat sich mein Verständnis für fremden Code der sich nach den gleichen Richtlinien gestaltet erheblich verbessert. Der Code wird meiner Meinung nach einfach interoperabler.

Meine klaren Empfehlungen: Richtlinien im Team entwickeln, die sich an den bestehenden im Markt anlehnen. Somit wird auch zugelieferter Code von außen veständlicher (falls Projekte extern vergeben werden).

Verständlicherer Code und bessere Verständlichkeit in der Teamkommunikation liefern Entwurfsmuster. Ob einfache Designpatterns wie Gang Of Four (schön zusammengefasst auf http://dofactory.com/) oder Enterprise Patterns, wie sie in den Enterprise Application Blocks oder Frameworks wie Spring.NET zu finden sind; jeder ernstzunehmende Entwickler sollte sich lieber früher als später damit beschäftigen. Zu Patterns wird es an anderer Stelle noch mehr geben.

Published Montag, 19. Mai 2008 14:11 von Rainer Schuster

Kommentare

# re: Design-Guidlines

Montag, 19. Mai 2008 20:38 von Jan Welker

Hallo,

wer sich für dieses Thema interessiert und in der Nähe von Koblenz wohnt, sei dieser Vortrag ans Herz gelegt.

weblogs.asp.net/.../6200832.aspx

Jan

Kommentar abgeben

(verpflichtend) 
(verpflichtend) 
(optional)
(verpflichtend)