[linux-l] Re: refactoring

Steffen Dettmer steffen at dett.de
Mo Nov 17 09:50:16 CET 2003


* olafBuddenhagen at web.de wrote on Wed, Nov 12, 2003 at 08:25 +0100:
> On Fri, Nov 07, 2003 at 08:45:04AM +0100, Steffen Dettmer wrote:
> > Zwei Möglichkeiten seh ich hier: entweder bist Du überrascht, wenn Du
> > mal so ein Buch liest, oder einfach nur zu beneiden ;)
> 
> Diese Möglichkeiten will ich nicht verneinen, aber es gäbe noch eine
> dritte: Das Buch enthält tatsächlich nichts nützliches...

Tja, was beleibt, ist die eigentliche Frage :-)
 
> Wie auch immer, jetzt bin ich kein bisschen schlauer.

:-)

> > Also, "Programmierer" (im Gegensatz zu Softwareentwicklern) machen
> > wohl kaum refactoring, weil die ja einfach nur ein Modell in eine
> > Programmiersprache übersetzen. Sie beschäftigen sich ja nur mit der
> > Implementierung.
> 
> Refactoring kann *nur* ein Programmierer machen. 

Ich schrieb: '"Programmierer" (im Gegensatz zu
Softwareentwicklern)"', um das abzugrenzen. Also ein
Programmierer (der nicht Softwareentwickler ist), ist jemand, der
eine detailierte Spec in einer anderen (formalen, ...) Sprache
schreibt, mehr nicht. Also vielleicht ein Inder, der gar nicht
weiß, was er da eigentlich schreibt. Da sich refactoring ja
i.d.R. auf das Design auswirkt, kann er das also nicht machen,
außerdem kann es sein, daß aus seiner Sicht externe
Schnittstellen betroffen sind. Na gut, sowas hat man immer, klar
:)

> Überhaupt widerspricht evolutionäre Softwareentwicklung
> prinzipiell dem Top-Down-Entwurf; ich denke nicht dass sich
> diese Konzepte irgendwie vereinen lassen. 

Nein, find ich nicht. Der Übergang ist fließend, der "richtige"
Punkt ist sicherlich Projektabhängig. Da kommt man vom iterativen
Modell übergangslos zum XP-Modell, in dem man die
Iterationszeiten verkürzt, die Techniken der Verfeinerung etc.
eben "nebenläufig" macht etc, was oft effizienter ist, aber nicht
der einzig mögliche Weg.

> Eine Unterscheidung in Programmierer und Designer macht da
> überhaupt keinen Sinn.

Na doch, ein Programmierer kann z.B. kein XP machen, weil da
Design geändert werden muß, per Definition, also muß man da schon
einen allgemeinen Entwickler haben.

> Sicherlich, in jedem Team wird es Leute geben die einem
> besonders guten Überblick haben, und bei weitreichenden
> Designänderungen die Entscheidungen treffen. Aber die
> Initiative für sowas kann nun mal nur von Leuten kommen, die
> selbst an dem Code arbeiten; und die Umsetzung sowieso.

Nee, seh ich nicht so, und außerdem find ich es gut, wenn es in
etwa mindestens teilweise die gleichen Leute sind, damit man das
Wissen jederzeit teilt und Rückflüsse hat.

> > Richtige Softwareentwickler, also die Designs aus
> > Spezifikationen entwerfen etc. haben damit vermutlich immer
> > mehr oder weniger "Probleme" - z.B. weil man oft erst
> > hinterher weiß, was richtig gewesen wäre.
> 
> Genau das ist der Grund wieso klassisches "Software
> Engineering" nicht funktioniert, nie funktioniert hat, garnicht
> funktionieren *kann*. Naja, einer der Gründe.

"nicht funktionieren *kann*"... Das sind so unbewiesene,
pauschale Aussagen, nervig. Es *kann* sehr wohl funktionieren,
und das hängt sehr vom Projekt ab. Wenn es darum geht, eine
Zielsteurung für eine Marsmission zu programmieren, wird man sehr
viel eher in die Richtung klassisches Software Engineering
kommen. Das geht los damit, daß die Programmierer später die
grundlegenden Spezifikationsdetails nicht verstehen, weil die
Physik dahinter zu kompliziert ist. Das geht weiter damit, daß
Fehler so unheimlich sauteuer sind, daß man auch viel Geld für
die Entwicklung ausgeben muß/kann. Vielleicht hat man hier ein
Projekt, dessen Design vergleichsweise einfach ist, dessen
Komplexität aber daher kommt, das man intern mehrfach mit
verschiedenen Algorithmen rechnen muß. Da man nur einen Versuch
einer Marsmission bezahlen kann, und dann schon alles fertig sein
sollte, ist XP hier vermutlich weniger geeignet. Zudem kann man
XP weniger gut teamübergreifend verwenden (z.B. "zwei Teams
entwickeln zu ähnlichem Ergebnis"), weil vermutlich zwei ganz
andere Sachen rauskommen usw. Aber da man auch hier Korrekturen
am Design machen und nachpflegen kann und muß, ist das im Prinzip
auch schon wieder evolutionär oder iterativ, würde aber wohl
niemand so nennen, weil das nicht das Ziel sondern ein eigentlich
ja unerwünschter Nebeneffekt ist... Na ja, wie auch immer :) Es
hängt eben immer vom Projekt ab (um auch mal so ne pauschale
Aussage zu machen) :-)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l