[linux-l] Re: refactoring

Steffen Dettmer steffen at dett.de
Mi Nov 12 09:23:05 CET 2003


* olafBuddenhagen at web.de wrote on Wed, Nov 12, 2003 at 08:01 +0100:
[..."Refactoring" Buch...] 
> Ich würde ja gerne was in dieser Hinsicht dazulernen. Nur frage
> ich mich: Gibt es da wirklich etwas was man aus solch einem
> Buch lernen kann?

Ich denke, *kann* auf jeden Fall. Durch Beispiele geht's oft
anschaulich, gibt sicherlich weitere Möglichkeiten.

> Da war eine lange Liste mit konkreten Vorschlägen was man
> umbauen soll. Da waren so geniale Dinge dabei wie: Auslagern
> eines Codeblocks in eine Funktion...  Ganz toll. 

Na ja, so losgelöst sagt das nicht viel. Gehört mehr dazu, klar,
aber dieses Detail selbst, was soll man da noch erklären? "Mache
Funktionen" ist ne Regel, die fand ich so recht klar.

> Ich habe die ganze Liste durchgesehen, und ich glaube nicht
> eine Sache gefunden, die mir nicht absolut trivial schien.

Ja, vermutlich verwendest Du eh schon "unterbewußt"
solche Methoden: Sicherlich hast Du schon Funktionen aufgeteilt,
Strukturen geändert etc. pp..

Das mit dem Auslagern von Funktionen ist trivial, ja, aber ich
kenne mehrere Entwickler, die es trozdem nicht wirklich machen.
Kann man also nicht oft genug sagen. Ich möchte dann gleich mal
hinzufügen, daß das auch für Module gilt: hier muß man auch
aufteilen. Ein Modul mit 100 Funktionen ist immer ein arger Grund
zur Skepsis...

Klar, auch alles trivival.

> Die Erklärungen, wann und warum man bestimmte Sachen machen soll, mögen
> ja vielleicht für einen wenig erfahrenen Programmierer noch hilfreich
> sein. (Obwohl ich mich frage ob man sowas nicht erst versteht wenn man
> es "am eigenen Leibe" erfährt...)

Ja, vermutlich. Aber muß nicht unbedingt ne extrem schwerzhafte
Erfahrung sein, find ich. Wenn man es "richtig" macht und am Ende
die Rechnung aufgeht, empfinde ich das als ein sehr erhebendes
Gefühl. Ein Design hat sich erst wirklich bewiesen, wenn das
erste refactoring durch ist :) Kommt natürlich drauf an, wie man
arbeitet, klar.

> Aber das schärfste waren ja die Erklärungen *wie* man einen
> Codeblock in eine Funktion auslagert... Das fand ich einfach
> nur noch albern.

mmm... Könnte ich jetzt nicht schreiben, würde bestimmt was
vergessen. Variablen müssen Parameter werden, klar. Sind
sicherlich noch 100 Kleinigkeiten, alle trivial, aber ich weiß
sie trozdem gerade nicht.

Aber klar, wenn in so einem Buch nur solch zweifelhafte (wenn
auch IMHO nicht unbedingt überflüssigen) Listen stehen, erscheint
die Investition nicht sinnvoll.

> Ich meine, was den meisten Leuten wahrscheinlich fehlt ist die
> Einsicht, dass es sich überhaupt lohnt Refactoring zu machen;
> und dabei kann ein Buch vielleicht helfen. Aber *wie* man das
> macht, kann man sowas aus einem Buch lernen?

Ja, seh ich auch so! Die Frage ist, warum wird oft nicht
angepaßt, wenn eigentlich schon klar ist, daß das aktuelle nicht
ideal oder gar Mist ist? Ich denke, da liegt viel an fehlenden
Unittests: man traut der Sache nicht und will nix anfassen. Die
entsprechenden Ideen aus XP find ich hier sehr gut und sehr
hilfreich.

> Nach meinem Verständnis geht es im Prinzip um nichts anderes,
> als den Code regelmäßig aufzuräumen, so dass man ständig
> saubere Lösungen hat.

Jo, genau. Ich glaube, nur so kommt man zu *reifem* Code. Ich
glaub, kein Mensch schreibt eine 10K+ Komponente auf Anhieb
richtig und gut. Wenn man das schon vorher weiß, sollte man ja
nicht überrascht sein, und das leicht durchführen können. Na, man
weiß ja, was in der Praxis oft los ist :)

> Im Endeffekt kommt es doch darauf hinaus zu erkennen, was eine
> saubere Lösung ist. Und für sowas kann man doch eigentlich nur
> durch Erfahrung ein Gefühl bekommen, denke ich...

Ja, das auch. "sauber"... dehnbar, klar. Ich denke,
Wiederverwendbarkeit hängt auch damit zusammen.
Wiederverwendung macht Code reifer, find ich. Die Doku muß da
sein, Fehler fallen auf, Tests werden nachimplementiert, kurz,
man hat Zeit an was "fertigem" zu arbeiten. Fertig aus
Geschäftssicht heit "geht", ist eben ein anderes "fertig" als ein
auf Sauberkeit bedachter Entwickler verwendet...

> > Aber 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.
> 
> Das kann ich so nicht bestätigen. Tatsächlich ist es oft so das
> Dinge ja so logisch und selbstverständlich scheinen... Und erst
> wenn man sie benutzen will, merkt man, dass man eigentlich nix
> gelernt hat.

Sagen wir mal: beides richtig (auch das, was Du zitiert hast).
Bei dem Zitat wird ja nicht gesagt, das jedes Buch, in dem einem
alles logisch erscheint, gut ist.

> Tatsächlich ist das wesentliches Erkennungsmerkmal von
> Coputerzeitschriften "für Dumme": Erklärungen die so stark
> vereinfacht sind, dass sie Null Information enthalten, oder
> einfach nicht mehr stimmen. 

mmm... Null? Du meinst, für Dich? Für ne Sekretärin wird da noch
was neues drin stehen, oder? Ich geb zu, ich kenn solche
Zeitschriften nicht.

> Die Leute, die solchen Schund lesen, sind alle überzeugt, dass
> es dort ganz toll erklärt wird, und sie alles verstehen. Wissen
> nur dummer Weise nicht, dass das meiste was sie dort "erfahren"
> haben, mehr oder weniger falsch ist... 

Na, das ist vermutlich übertrieben, man muß natürlich die Sichten
beachten. Für eine Sekretärin-Sicht find ich es z.B. OK wenn man
ihr sagt, /bin kann man nicht schreiben. Ist natürlich falsch und
konfigurierbar etc. pp., aber für ne Seketärin und den Alltag ist
es irgendwie gefühlt-richtig :) 

> Andererseits gibt es doch einiges was spieziell ist an der
> Programmierung unter Unix und GNU/Linux sowie an freier
> Software; 

Interessantes Thema. An was denkst Du da so? Kann man nicht
vieles davon auf die Wirtschaft übertragen? Wäre das sinnvoll?

oki,

Steffen

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




Mehr Informationen über die Mailingliste linux-l