Category Archives: Sicht des Software-Nutzers

Auftraggeber und Benutzer einer Software haben eine andere Sicht und eigene Vorstellungen und Wünsche in Bezug auf den Entwicklungsprozess.
Wichtig ist zu verstehen, was hierbei realistisch und sinnvoll ist, während gleichzeitig Einschränkungen und falsche Annahmen erkannt werden sollten.

Refactoring, Merkmal professioneller Softwareentwicklung

Als Refactoring bezeichnet man die Veränderung von Quellcode, ohne dass sich das Verhalten der betroffenen Software nach außen ändert. Der geneigte Kunde, Auftraggeber oder Nutzer fragt sich daher oft, was das Ganze soll. Die Antwort ist einfach, aber nicht trivial: Durch Refactoring wird bestehender Code für Entwickler besser verstehbar und ist daher besser wartbar. Zukünftige Veränderungen werden hierdurch leichter, oft sogar überhaupt erst sinnvoll möglich. Warum aber schreiben Entwickler Software dann nicht von Anfang an so?

Stellen Sie sich vor, Sie schreiben einen wichtigen Brief, einen Artikel oder gar ein ganzes Buch. Sie werden mit einem Entwurf beginnen und sich nach und nach an die endgültige Fassung heran tasten. Ihnen ist klar, dass es unmöglich ist, die endgültige Version in einem Rutsch zu schreiben. Und selbst nach Fertigstellung werden Sie hier und da noch Stellen finden, mit denen Sie unzufrieden sind oder die Sie heute anders schreiben würden.

So verhält es sich auch mit der Softwareentwicklung. Man beginnt mit einer ersten Planung, welche die Strukturen der Software darstellen. Sobald diese fest stehen, werden die einzelnen Bestandteile erstellt und zu einer lauffähige Software zusammen gebaut. Hierbei neigt man dazu, relativ große und unübersichtliche Codeblöcke zu schreiben, welche man im Moment hervorragend überblickt. Kommt man aber nach zwei Wochen wieder an diese Stelle, weiß man kaum mehr, worum es geht oder was die Software an dieser Stelle tut. Geschweige denn, wer “diesen Wust verzapft hat”… 😉

Als Autor muss man also nach der ersten Fertigstellung des jeweiligen Softwarebereichs (oder eben des Abschnitts im Buch), diesen überarbeiten, so dass er auch in Zukunft und von anderen Entwicklern leicht verstanden werden kann. Ebenso achtet man darauf, dass man eine ordentliche Struktur hinterlässt. Sie würden sicherlich auch kein Buch gutheißen, indem zusammengehörende Informationen über verschiedene Kapitel verstreut sind und welches nur schwer und holprig zu lesen ist.

Der einzige Grund, kein Refactoring durchzuführen ist, wenn bestehende Software einwandfrei funktioniert und nicht mehr verändert wird. Dann liest auch niemand mehr den Quellcode oder muss diesen bearbeiten. Da wir Software aber wiederverwenden können wollen, ist dies eigentlich nie gegeben und Refactoring gehört zu einem professionellen Workflow immer dazu.

Nun habe ich diesen Artikel noch einige Male gelesen, verändert und hoffe er ist halbwegs verständlich. Sie werden aber bestimmt noch den einen oder anderen Fehler finden und stolpern vielleicht über manche Formulierung. Verstehen Sie, was gemeint ist… ?

Blog: Hohe Ansprüche, wenig Resultate

Mal wieder war es soweit. Ein Treffen zwischen Auftraggeber und Softwareentwickler stand an. Je zwei Teilnehmer beider Seiten sollten alle noch offenen Fragen klären.

Die Auftraggeber hatten extra einen wichtigen Termin verschoben und eineinhalb Stunden für das Treffen reserviert. Nach hinten war auch noch Luft, daher war es nicht ganz so schlimm, dass sie erst um 13:15 vor Ort eintrafen. Der vorige Termin hatte wieder einmal etwas länger gedauert.

Das Entwicklerteam wartete seit 13:00 Uhr im Besprechungsraum, nahm die Entschuldigung für die Verspätung dankend an und öffnete einige Dokumente, welche mittels Projektor an die Wand geworfen wurden. Es ging los, die Stimmung war gut.

Zwei Stunden später, die Situation ist hektisch, die Sicht der Auftraggeber:

Die beiden Entwickler waren knapp mit der Hälfte der im Vorfeld als E-Mail versendeten Punkte ihrer Liste fertig. “Punkte” war sowieso das falsche Wort – “Kapitel” oder “Abhandlungen” wäre treffender. Einer der Auftraggeber war gerade gegangen, sie hatten sich entschieden, dass den nächsten Termin auch einer alleine bewältigen könnte. “Wie lange soll das noch dauern?” dachte der Verbliebende. “Warum machen die Beiden es so kompliziert?” Er konnte sich kaum noch konzentrieren – die Flut von Detailfragen empfand er als unnötig und übertrieben. Gleichzeitig hatten er mit seinem Partner versucht noch zwei kleine Änderungen einzubringen, von denen eine mit sichtlichem Unmut akzeptiert wurde, die andere aber gleich als “jetzt nicht machbar” auf später verschoben wurde. Eigentlich gab es nur noch die eine unausgesprochene Frage:

“Warum kostet das alles soviel Zeit und Geld? Wie sollen wir so unsere Pläne verwirklichen?”

Das kommt Ihnen bekannt vor? Hier geht es zu Lösungsvorschlägen!