Diskussion:Refactoring

message: Ich habe den Baustein reingesetzt, weil der Artikel den Begriff nicht erklärt. Die einzige "Erklärung" ist "refactoring = Umgestaltung"; sonst nennt der Artikel nur Vorteile und Risiken des Refactoring. Das versteht doch keiner! --Langec ☎ 01:17, 24. Feb 2005 (CET)
replies: text: Ich habe eine Erklärung von Refactoring über die Vorgehensweise gegeben. Sicherlicht nicht das beste und noch verbesserungswürdig, aber ich glaube nicht, dass der Artikel jetzt noch den Vermerk "unverständlich" verdient :) --ChristianHujer 04:56, 14. Mär 2005 (CET)
replies: text: Ich find's gut, danke! --Langec ☎ 10:45, 14. Mär 2005 (CET)
thread_title:  Unverständlich 

message: Ich habe folgenden Text wieder entfernt:
:Im allgemeinen ergibt sich die Notwendigkeit zum Refactoring, wenn über Jahre hinweg an einem Code an vielen Stellen Ergänzugnen vorgenommen wurden - wenn z. B. ein Kunde immer mal wieder eine neue Funktionalität gefordert hat - und der Programmierer diese Funktion ohne Straffung des gesamten Codes implementiert hat. Das führt wie in der Mathematik (Äquivalenzumformung) dazu, daß zu einer bestehenden Funktion immer ein weiterer Term hinzugefügt wird, ohne, daß überprüft wird, ob sich Terme gegenseitig wegkürzen. Beim Refactoring wird also überprüft, ob die innere Struktur des Quellcodes verschlankt werden kann, was die Wartbarkeit erhöht, das Risiko von Seiteneffekten bei der Implementierung neuer Funktionen reduziert und der geschätzte Aufwand zur Implementierung neuer Funktionen leichter beurteilbar wird.
Grund: Refactoring wird aus verschiedenen Gründen gemacht, nicht nur der Verschlankung willen, sondern grundsätzlich zur Verbesserung des Designs. Die gestrichenen Sätze würden nur das Pattern 'extractMethod' oder ähnliche begründen, nicht jedoch die vielen anderen Refactoring-Pattern. Zudem wird Refactoring idealerweise nicht nach Jahren angewendet, sondern permanent bei der Weiterentwicklung der Software. Laut Fowler soll man sogar an einem Arbeitstag zwischen Refactoring und Implementieren neuer Features hin- und herwechseln. Daher sind die Grundaussagen der obigen Textstelle eher falsch. Falls der Autor etwas anderes aussagen wollte sollte er es nochmal mit einer anderen Formulierung probieren oder hier darüber diskutieren. -- Dishayloo [ +] 23:24, 19. Mär 2005 (CET)
replies: text: Ich bin mit der Löschung völlig einverstanden. Die Erklärung rückte Refactoring in ein falsches Licht. Als Extreme Programmer lehne ich es entschieden ab, die Notwendigkeit für Refactoring auf den Kontext eines "über Jahre hinweg" gewachsenen Codes zu begrenzen oder einen Bezug zu solchem herzustellen, der eine solche Beschränkung beim Leser eventuell impliziert. Refactoring sollte vom ersten Tag an ständig und regelmäßig und meist gestützt von Unit-Tests durchgeführt werden. Wenn man das über Jahre hinweg nicht gemacht hat und einem dann auffällt, dass man Refactoring braucht, kann man den Code meist nur noch wegschmeißen. Auch möchte ich bestätigen, dass Refactoring nicht grundsätzlich der Verschlankung dient. Oft wird Code durch Refactoring verschlankt. Aber sämtliche Refactoring-Muster zur Erzeugung neuer Symbole, z.B. durch Zerlegung, wie 'extractMethod', 'extractClass', 'extractInterface' etc. erzeugen größeren Code als vorher - und sind deswegen nicht schlecht, sondern trotzdem sehr häufig anzuwenden. --ChristianHujer 11:11, 23. Mär 2005 (CET)
thread_title:  Entfernter Text 

message: Liebe Hauptautoren,
ich würde mich davon trennen, in diesem Artikel "refaktorisieren" mit allen Mitteln als "falsch" darzustellen. Der Hinweis mag bezüglich der Begriffsherkunft passen, aber der alltägliche Gebrauch sollte stärker binden. Etwas salopp ausgedrückt: die Besserwisserei nervt ein bisschen. Gerade die Hinweise auf die mathematischen Analoga schaden mehr als sie nützen. Möglich, dass sich sogar mal das Wort "Refaktorisieren" durchsetzt, das wäre dann ein bisschen wie bei den Backronymen. Mein konkreter Wunsch vorerst: Den Satz Refactoring wird manchmal auch mit der eher unzutreffenden Bezeichnung Refaktorisierung oder mit Refaktorierung übersetzt. Im aktuellen Visual Studio 2005 von Microsoft wird Refactoring als Umgestaltung bezeichnet. aus Abschnitt 0 löschen (mal sehen ob ich mich ein paar Tage lang gedulden kann). 
Gruß --Peu 11:27, 17. Okt. 2007 (CEST)
replies: text: Man könnte auch einfach ganz auf die Übersetzung verzichten. Beispielsweise RAD 7 spricht auch in der deutschen Version nur von „Refactoring“ und „Refactoring durchführen“. Den oben genannten Satz darfst du von mir aus gerne streichen. --jpp ?! 12:17, 17. Okt. 2007 (CEST)
replies: text: Habe die deutschen Übersetzungen (bei aller Kontroverse - wir haben hier nicht zu richten denke ich, "refaktorisieren" ist bei denjenigen Deutschen SW-Entwicklern, die es verwenden absolut gebräuchlich) Hier nur die Zahlen von Google:
Wort            	Treffer  	
Refactoring     	9 410 000	
Refaktorisierung	936      	
refaktorisieren 	926      	
refaktorisiert  	412      	
Refaktorierung  	380      	
refaktorieren   	397      	
refaktoriert    	442      	
hier zur Ergänzung die Entscheidungen, die die anderssprachigen Wikipedianer getroffen haben:
Wahl               	Anzahl
"Übersetzung"      	7
Umschreibung       	2
englisches Wort    	4
unklar (zh, ja, vi)	3
Auf das suchen nach "Umgestaltung" habe ich verzichtet. Ich würde das mal weiter im Blick behalten, die korrekte deutsche Übersetzung wird sich wohl noch finden müssen. aktuell ist der englische Terminus klar vorn, aber die meisten Veröffentlichungen (im Netz) sind auch englisch, und sie betreffen - siehe erster Diskussionsansatz - nicht nur SWE. --Peu 09:10, 24. Okt. 2007 (CEST)

text: Ich denke, dass du im Artikel jetzt eine gute und pragmatische Lösung gefunden hast. Der entfernte Satz war wirklich etwas oberlehrerhaft. --jpp ?! 10:56, 24. Okt. 2007 (CEST)
replies: text:  Danke, dein Lob wirkt erleichternd --Peu 13:36, 24. Okt. 2007 (CEST)
thread_title:  Refaktorisieren noch mal 

message: Im Text steht ja:
'Weiterhin gilt das Prinzip der kleinen Änderungen. Wenn man nur wenig verändert, so kann man hoffen, auch nur wenig zu zerstören, falls man durch das Refactoring Fehler einträgt (dieses Argument wird allerdings durch die Tatsache geschmälert, dass es sich bei Digitalrechnern um maximal unstetige Systeme handelt, in denen kleine Ursachen sehr wohl große Auswirkungen haben können).'
Diese Aussage ist mathematisch nicht haltbar. Ich vermute die Argumentation dahinter ist, dass eine ganzzahlige Funktion, die sich ändert ja Sprünge macht. Auf den reellen Zahlen ist sie tatsächlich unstetig, auf den ganzen Zahlen ist sie aber stetig!
Maximale Unstetigkeit gibt es ohnehin nicht. Wenn man so will, kann man beliebig unstetige Systeme konstruieren - wobei kontinuierliche Systeme da deutlich mehr Spielraum geben.
Also entweder gehört das unter die Kategorie Theoriefindung oder ... --Haize 14:34, 28. Jun. 2008 (CEST)
thread_title:  Digital=maximal unstetig 

message: Ist nicht einer der großen Vorteile eines Refactoring, dass das Programm (oder die Website) danach u.U. schneller läuft oder weniger Ressourcen braucht? 
Kann ich das dem Abschnitt "Vorteile" hinzufügen? -- Jesus Presley 15:38, 10. Aug. 2011 (CEST)
thread_title:  Vorteile: "Performance" ergänzen? 

message: Die Anwendung der von der IDE bereitgestellten automatisierten Refactorings verbessert sowohl die Geschwindigkeit wie auch die Zuverlässigkeit der Änderungen. Ich denke, es kommt im gesamten Artikel und besonders in diesem Abschnitt nicht genug zur Geltung, dass die Möglichkeiten der IDE bevorzugt genutzt werden sollten. Daher schlage ich vor, den letzten Absatz in diesem Abschnitt zu teilen. --TT (Diskussion) 10:40, 27. Jan. 2016 (CET)
thread_title:  Risiken und deren Handhabung: automatisiert Refactorings