Forum

Ein toller Artikel von ner tollen Webseite: © Winfried Mueller, www.reintechnisch.de

26.04.2005 :: Design-Grundsätze
Permalink
Ich bin gerade über eine Mail von Patrick Michaud gestolpert, der der Hauptentwickler des PmWiki ist. Er hat sich zu Anfang seines Projektes einige Design-Grundsätze definiert, an denen er sich immer wieder ausrichtet. Das ist eine sehr gute Idee.
Ein Grundsatz für PmWiki hat er in der gestrigen Mail beschrieben: "simple things should be simple and complex things possible". Es ging dabei um die Diskussion, die Wiki-Sprache immer mehr aufzublähen mit allen möglichen Spezialfeatures. Der Grundsatz sorgt jetzt dafür, dass man im Eifer des Gefechts nicht alle möglichen Dinge implementiert, die die Benutzung für Anfänger komplizierter machen. Einfache Dinge, die Anfänger tun, sollen einfach bleiben. Wer kompliziertes machen will, kann das auch tun, jedoch muss er dann auch mit komplizierteren Ausdrücken rechnen. Lieber wird versucht, einfache Dinge einfach zu halten, auch wenn das dazu führt, das komplizierte Dinge etwas komplizierter werden. Er bevorzugt also die Leute, die Anfänger sind. Das ist eine sinnvolle Designentscheidung, braucht es doch bei einem Wiki besonders eine Einladung an Anfänger, damit die Einstiegsschwelle nicht so hoch ist. Ein Wiki braucht ja vor allem Schreiber und daran mangelt es oft. Also muss man denen einen roten Teppich ausrollen.
Das ist übrigens ein weiterer Designgrundsatz von PmWiki - "Mach es den Schreibern möglichst einfach."
Im Eifer des Gefechts verliert man bei Software-Entwicklung das Wesentliche aus den Augen. Wollte man zuerst eine einfach benutzbare Software schreiben, bemerkt man beim Fortschreiten des Produktes gar nicht mehr, dass alles viel zu kompliziert wird, weil man es selber gut kennt und die Komplexität nicht mehr wahrnimmt.
Von daher ist es für jedes Softwareprojekt gut, sich Design-Grundsätze zu suchen und diese schriftlich zu fixieren. Einfache, prägnante kurze Sätze. Der Prozess des Schreibens solcher Grundsätze ist wichtig, weil sich da erstmal herauskristallisiert, was man eigentlich will. Das, was zuvor nur so nebulös im Raum rumschwirrte, wird jetzt klar und prägnant, wird eindeutig und be-greifbar.
Solche Grundsätze sind auch wichtig für ein Team von Entwicklern, damit man sich auf eine gleiche Marschrichtung einschwören kann. Es müssen natürlich Grundsätze sein, die für alle Entwickler annehmbar sind. Nur so kann man sich von ganzem Herzen auf etwas einlassen. Und gute Software entsteht ja nicht daraus, dass Leute ihren Job machen, sondern eher, dass Menschen von ganzem Herzen an etwas arbeiten.
Im Laufe der Entwicklung kann man immer wieder die Grundsätze zur Hand nehmen und sich neu ein-norden. Der Entwicklung wieder zur ursprünglichen Richtung verhelfen. Am besten auch im Team.
Softwareprojekten merkt man es schnell an, ob sie von ein paar Grundsätzen geführt werden oder ob sie sich chaotisch entwickeln. Gute Software braucht Grundsätze, woran sie sich ausrichtet, weil nur so beständig bestimmte Konzepte weiter und weiter wachsen. Wenige starke Konzepte sind viel besser, als ein wilder Haufen schwacher Konzepte, die auch noch permanent wechseln. Der meisten Software mangelt es an gut durchdachten, leistungsfähigen und flexiblen Konzepten. Meist deshalb, weil sich um Design, Design-Grundsätze und Architektur zu wenig Gedanken gemacht wird.
Neben den Design-Grundsätzen für ein konkretes Produkt gibt es natürlich auch noch generelle Grundsätze für gute Software. Jeder wird mit der Zeit durch Erfahrung einiges herausfinden, was grundsätzlich wichtig ist. Und da lohnt es sich, dass mal schriftlich zu fixieren. Um daraus vielleicht ein paar eigene goldene Programmiergrundsätze zu extrahieren.
Grundsätze sind Anker, an denen man sich festhalten kann. Etwas, was man sonst im Alltag aus den Augen verliert.

Stand: 18.07.2005 03:20 Uhr
© Winfried Mueller, www.reintechnisch.de
Copyright dieser Seite
Permalink
Copyright (c) 2004 Winfried Mueller, www.reintechnisch.de
Es wird die Erlaubnis gegeben dieses Dokument zu kopieren, zu verteilen und/oder zu verändern unter den Bedingungen der GNU Free Documentation License, Version 1.1 oder einer späteren, von der Free Software Foundation veröffentlichten Version; mit keinen unveränderlichen Abschnitten, mit keinen Vorderseitentexten, und keinen Rückseitentexten.
Eine Kopie dieser Lizenz finden Sie unter GNU Free Documentation License <http://www.gnu.org/copyleft/fdl.html>.
Eine inoffizielle Übersetzung finden Sie unter GNU Free Documention License, deutsch <http://nautix.sourceforge.net/docs/fdl.de.html>.
In diesem Artikel werden evtl. eingetragene Warenzeichen, Handelsnamen und Gebrauchsnamen verwendet. Auch wenn diese nicht als solche gekennzeichnet sind, gelten die entsprechenden Schutzbestimmungen.
Alle Informationen in diesem Artikel wurden mit Sorgfalt erarbeitet. Trotzdem können Inhalte fehlerhaft oder unvollständig sein. Ich übernehme keinerlei Haftung für eventuelle Schäden oder sonstige Nachteile, die sich durch die Nutzung der hier dargebotenen Informationen ergeben.
Sollten Teile dieser Hinweise der geltenden Rechtslage nicht entsprechen, bleiben die übrigen Teile davon unberührt.