Verbessere dein Softwaredesign...

Profile of "Uzimaster"

Dear visitor, welcome to WoltLab Bugtracker. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Uzimaster

Moderator
- "Uzimaster" is male
- Register now!
You have to register first, to connect to this user.

Rating:

by Uzimaster, Friday, May 21st 2010, 1:56pm

In den letzten Tagen habe ich meine Zeit damit verbracht, eine Endanwendung für das WCF zu überarbeiten, die noch für das WCF 1.0 konzipiert wurde.

Das an sich ist ja kein Problem. Dabei fiel mir aber mal wieder auf, dass es schwer ist, den Code zu verstehen, wenn dieser nicht ordentlich dokumentiert wurde.

Desweiteren sind Designpatterns eine nette Sache. Hier kann ich nebenbei einmal ein Buch empfehlen:
-> http://www.amazon.de/PHP-Design-Patterns…74389545&sr=8-1

Aber nun zum Thema zurück: Softwaredesign

Was gilt es beim Programmieren zu beachten? Einfach einmal darauf losschreiben oder vorher es planen?
Na ja, vielleicht sollte man sich kurz Gedanken darüber machen, was man eigentlich vorhat.

Zumindest sollte man sich über eines im Klaren sein: Alles, was man so programmiert, sollte sicher, schnell, erweiterbar und stabil sein.

Wie erreichen wir das alles?

Punkt 1: Kapsel den Zugriff auf Daten

Alle Daten sollten in Klassen gekapselt werden. Vergesse nicht die Methoden, um diese Informationen auch abfragen zu können.

Punkt 2: Zentralisiere Abläufe in einer Methode

Wiederkehrende Abläufe sollten in eine Methode gekapselt werden. Das vermeidet einen doppelten Code, erleichert Änderungen und macht das Ganze noch
übersichtlich.

Punkt 3: Wähle sinnvolle Klassen- und Methodennamen

Klassen- und Methodennamen, bei denen man nicht direkt erkennt, was sie bedeuten sollen, sind so deplatziert wie Schokolade auf einer Pizza.
Wenn man sich beispielsweise einen Variablennamen ausdenken muss, kann man sich folgende Fragen stellen:
- Welchen Zweck hat die Variable?
- Wie wird sie verwendet?

Anregung für Klassennamen gesucht? -> http://www.classnamer.com/

Punkt 4: Teile dein Projekt in so viele Module wie nötig, aber so wenig wie möglich

Jedes Modul sollte die Lösung eines Problemes sein. Dabei ist aber darauf zu achten, dass jedes Modul genau eine Aufgabe hat.
Genauso sollte es auch zu jeder Aufgabe ein Modul geben. Im WoltLab Community Framework kann man dies ganz gut nachzuvollziehen.

Punkt 5: Abhängigkeit zu anderen Objekten

Wenn deine Klasse andere Objekte benötigt, sollten diese nicht von der Klasse selber erzeugt werden. Das führt nur zu engen Abhängigkeiten, so dass sich einzelne Implementierungen nur schwer austauschen lassen. Übergebe benötigte Objekte über den Constructor oder Setter-Methoden.
Das bedeutet zwar ein wenig mehr Quellcode, aber letztlich verbessert es die Qualität.

Punkt 6: Mache dich mit Entwurfsmustern vertraut

Es gibt ziemlich viele Entwurfsmuster, zu allen kann man im Internet diverse Informationen finden. Bachte hierbei auch meinen Buchtipp.

Ansonsten hilft Google immer gern weiter.

Besonders wichtig sind für uns die Erzeugungsmuster sowie die Strukturmuster. Bei den Erzeugungsmustern zählen das Singelton-Muster sowie das
Factory-Muster zu den wichtigsten.
Adaptermuster und das Facade-Muster sind bei den Strukturmustern die mit der häufligsten Verwendung.

Entwurfsmuster sind ein so komplexes Thema, das darauf hier nicht eingegangen werden kann. Wie ich schon sagte, es gibt unzählige Informationen dazu im Internet oder in Buchform.

Punkt 7: Erfinde das Rad nicht neu

Bevor man an einer Problemlösung arbeitet, schaut man sich um, ob das selbe Problem nicht schon irgend woanders gelöst wurde. Besser wäre es doch, eine bestehende Lösung mit Verbesserungsvorschlägen voran zu bringen.

Punkt 8: Schreibe nur Code, der auch verwendet wird

Es bringt niemandem etwas, wenn man Code schreibt, weil man glaubt, man würde es vielleicht später mal brauchen. Schreibe Code dann, wenn du ihn benötigst.

Punkt 9: Kein Copy&Paste

Doppelter Code ist schlechter Code. Das macht deinen Code nur fehleranfällig und schwer wartbar.

Punkt 10: Suche nicht die perfekte Lösung

Verbringe deine Zeit nicht damit, die perfekte Lösung zu suchen. Nimm die Lösung, die es gut genug erledigt. Perfektionismus verschwendet nur Zeit.
Verschönern kann man immer noch, wenn Zeit ist. Und zudem hat man später auch eventuell wieder was dazugelernt, das man dann anwenden kann.

Punkt 11: Halte deinen Code einfach

Für ein Problem braucht man nicht immer eine komplexe Lösung. Klar, ein Entwickler wird von einer komplexen Lösung magisch angezogen. Man will ja lernen.
Aber wieso eine ganze Firma aufbauen, nur weil man Öl an einem Fahrzeug wecheln will?

Punkt 12: Vier und mehr Augen sehen immer mehr als zwei

Auch wenn man so wie ich schon eine Brille trägt, übersieht man gerne etwas. Also lass deinen Code oder deine Problemlösung von Anderen "gegenlesen".
Häufig kommt man als Außenstehender schneller zu anderen Lösungen, die vielleicht besser oder einfacher sind.

So, ich komme zum Abschluss. All dies sind wichtige Punkte im Alltag eines Programmieres. Ich hoffe, es hilft dem ein oder anderen weiter.

Ich sehe heute aus wie eine Bockwurst, also gebt gerne euren Senf dazu.

This article has been read 4,904 times.

Categories: Tipps und Tricks

Go to the top of the page

Comments (9)

9

by Mr.Cookie (Wednesday, January 5th 2011, 4:43am)

Naja so ganz kann ich dem Autor nicht zustimmen obwohl er im Grunde zwar Recht hat so sind die Aussagen eher pauschal
Teilweise hört sich es an wie "man braucht zwar Uhren aber warum einen Sekundenanzeiger reinbauen wenn man den Minutenzeiger hat" sorry aber dem Pflichte ich nicht bei Lösungen sollten stabil und performant entwickelt werden und nicht "wischi, waschi" hingeklatscht, dazu gehört schon Perfektion und wer ernsthaft programmiert erfindet das Rad auch mal neu um es "lauffähiger" zu machen.
8

by JamesEduard (Monday, September 20th 2010, 11:04am)

It is a good thing that there is an interesting post like you got. It is very intuitive and well-written. It is an educative and learning experience. More interesting post. More power.
7

by Old_Surehand (Thursday, May 27th 2010, 10:54pm)

Deinen letzten Eintrag fand ich super, aber hiermit kann ich wenig anfangen. Das ist so sehr Vogelperspektive, dass man nichts mehr erkennt. "Guck mal, ich hab Clean Code gelesen", aber eigentlich wäre ein eigener Artikel für (fast) jeden Deiner Punkte nötig, damit man ihn überhaupt verstehen kann. Wie kapselt man Daten sinnvoll, was ist "ein Problem", "eine Aufgabe", warum soll ich mich mit Entwurfsmustern vertraut machen? Viel Stoff für die nächsten Blogeinträge....
6

by Jenso (Tuesday, May 25th 2010, 4:45pm)

Auf meine nächste Pizza kommt definitiv Schokolade
5

by Nerat (Sunday, May 23rd 2010, 11:07pm)

Liest sich wie "Programmieren für Dummies".
4

by qivis (Sunday, May 23rd 2010, 10:55am)

"so deplatziert wie Schokolade auf einer Pizza. "
Hm, hat das schon mal jemand probiert?
3

by Keksl (Saturday, May 22nd 2010, 4:30pm)

[quote]Punkt 12: Vier und mehr Augen sehen immer mehr als zwei [/quote]
Wie wahr. Scheinst ja echt ein Intelligenter Fuchs zu sein.
2

by black_kite (Saturday, May 22nd 2010, 12:52pm)

Punkt 12: Vier und mehr Augen sehen immer mehr als zwei

wie wahr, man sieht den den walt vor lauter bäume nicht.
1

by .FitB (Friday, May 21st 2010, 3:31pm)

Schöner Text, nette Tips, aber vieeeel Fachchinesisch für Leute die nicht "wie eine Bockwurst" nur mit Coden beschäftigt sind Vielleicht den ein oder anderen "Glossarlink" hinzufügen?