refactoring (was: Re: [linux-l] OF-CONTEXT: Perl OOP Programmer wanted!)

[Steffen Dettmer]

* Olaf Radicke wrote on Thu, Nov 06, 2003 at 20:54 +0100:
> Am Don, 2003-11-06 um 11.13 schrieb olafBuddenhagen at web.de:
> > Nur was ich mich schon immer frage: Was hat man davon das
> > Buch zu lesen?  Was steht denn da nützliches drin? Kann mir
> > irgendwie in solch einem Buch nix vorstellen was nicht
> > offensichtlich und naheliegend ist...

Zwei Möglichkeiten seh ich hier: entweder bist Du überrascht,
wenn Du mal so ein Buch liest, oder einfach nur zu beneiden ;)

> so ganz nebenbei...daran erkennt man gute didaktische Bücher:
> Das man das Gefühl hat, das doch alles ganz logisch und 
> selbstverständlich ist. 

yep.

> Leider sind die Proger in der BeLUG z.Z. etwas
> unterrepresentiert.

Ist ja auch keine Programmierergruppe ;)

> Den einen kann man nichts erzählen, weil sie es (noch nicht)
> verstehen, und den anderen weil sie es sowieso besser wissen.

Ich fand, gab hier schon ein paar Diskussionen zu solchen Themen,
und auch meistens für mich persönlich sehr interessant. Ich hab
dabei jedenfalls was gelernt, also find ich's gut :)

> Interessant würde ich es mal finden, wenn jemand über sein
> Projekt berichtet und erzählt warum er(sie) sich für diese oder
> jene Lösung eines Problems entschieden hat und welches Konzept
> er dabei verfolgt.

Ja, Erfahrungen zu teilen kann viel helfen.

> Aber richtige Programmiere haben ja keine Problem. 

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. 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. Oder weil man
refactoring aufschiebt und am Ende ist's noch schlimmer. mmm...

Ich finde in diesem Zusammenhang die XP Ideen sehr interessant.

> Problem stellen immer nur die Kollegen, deren Code, der Chef,
> der Auftraggeber und die User da.              

Ja, und zuwenig Zeit :-)

> Und so priemelt jeder für sich alleine rum. 

... was meiner Meinung nach zu obrigen Problemen führt.

oki,

Steffen

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