Diskussion:Refactoring

Existiert dieses Wort überhaupt?

Existiert dieses Wort überhaupt? Außer natürlich bei "Nicht-Übersetzern". Habe das bisher noch nie gehört, auch im Zusammenhang mit Software nicht. Im Duden steht's auch nicht. Da fällt mir spontan "redigieren" und "überarbeiten" ein. --Vulture 11:31, 1. Nov 2003 (CET)

Hmm, im Englischen gibt es den Begriff Refactoring. Der ist in der Softwareentwicklung bekannt, deutsche Bücher nennen das Refaktorisierung. Nun habe ich auf der englischen WP gefunden, dass man den Begriff auch auf natürliche Texte anwenden kann. Allerdings, wenn Du so fragst, gilt das wahrscheinlich nicht für die deutsche Sprache. Vielleicht sollte ich den Anteil für natürliche Texte streichen, nur die Softwareentwicklungsbedeutung beibehalten. Das wird das Beste sein. Kennt doch jemand noch weitere Bedeutungen für Refaktorisierung im Deutschen, kann er diese ergänzen. -- Dishayloo 12:22, 1. Nov 2003 (CET)

Die Übersetzung gibt es leider , aber sie ist blanker Unfug. Refactoring hat meines Wissens was mit Factory, Fabrik, und nicht mit factor, Faktor zu tun. Aus dem lateinischen facere (machen) hinter der "re-factory" müsste, wenn man es denn unbedingt übersetzen will, ein deutsches "Refakturierung" entstehen (wie in "Manufaktur"), was allerdings auch ein Fachbegriff aus der Finanzbuchhaltung und dem Steuerrecht ist. Das Wort "Refaktorisierung" wäre jedoch bestenfalls eine Rückzerlegung in Faktoren (von "Faktorisierung") in der Mathematik, falls es dort sowas gibt. Uli 12:34, 1. Nov 2003 (CET)

Uli, ich hatte schon an anderer Stelle darauf hingewiesen, dein Tonfall ist nicht gut. Etwas mehr Freundlichkeit lässt sich im Umgang mit Menschen schon erwarten. Auf diese Art wirst Du auch in Zukunft immer wieder Streit herausfordern.

In allen deutschen Büchern, fand ich bisher immer beide Verwendungen, also 'Refaktorisierung' und 'Refactoring'. Ich habe mich für die deutsche Variante als Artikeltitel entschieden, weil die deutsche Variante zu nehmen, in der deutschen WP üblich ist. Aber 'Refactoring' habe ich als Redirect angelegt.

Zur Herkunft: Ein Wort 'factoring' gibt es im Englischen ursprünglich nicht. 'factorize' hat mit Faktoren zu tun. 'factory' ist das einzige ähnlich klingende Wort, das grundsätzlich eine etwas andere Bedeutung hat.

Zitat: The word 'factor' traces back to the Latin word for 'maker'. In other words, things are made up of their factors. To factor something is to find what it's made of, its component parts. To refactor is to find a different set of component parts that make the same thing. Deeper understanding (and control) comes from finding different part-whole relationships in the same problem. Or as James' (of giant peach fame) parents would say "Try looking at it a different way." Factoring and refactoring are essentially analytical, but without the stigma of paralysis attached. The part-whole discovery exists in both, but in current usage, analysis connotes something akin to planning, while refactoring connotes a post-build cleanup. A sort of thinker-doer dichotomy, on the surface anyway. -- WaldenMathews [1]

Auch die englische WP findet die Wortherkunft bei Faktoren und nicht bei der Fabrik. Da der Interwiki-Link existiert, wäre es nicht allzu schwer gewesen, das herauszufinden. Deines Wissens heisst in dem Fall wohl eher, dass Du Dir das gedacht hast, weil es Dir plausibel erschien. Das ist aber kein Wissen. Es hätte sich schon gelohnt, das eher als Frage zu formulieren, so mache ich das auch immer in Diskussionen, wenn ich es nicht sicher weiss. Daher ist auch die Übersetzung kein Unfug. (Auch wenn das meiner Meinung nach, bei neuen Begriffen eh keine Rolle spielt, ob die Übersetzung korrekt ist, man etabliert den Begriff ja sowieso erst.) -- Dishayloo 16:22, 1. Nov 2003 (CET)

Nicht gleich beleidigt fühlen, der "Sprachpuristenunfug" galt nicht Dir, sondern den ursprünglichen Übersetzern. Wobei ich Ihnen nach Deinem Hinweis zu Gute halten muss, dass sie gar nicht so falsch übersetzt haben, sondern auf eine offenbar gängige Volksetymologie (Refactoring hätte was mit dem mathematischen factoring (bzw. "factorization"(!)) zu tun) reingefallen sind.

Ich geb zu, so ganz sicher war mein "Wissen" nicht, aber ich hab seit gestern nochmal recherchiert: Der Ausdruck wurde zum ersten Mal "offiziell" in einer Arbeit von Johnson und Opdyke 1990 gebraucht ("Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In: Proceedings of Symposion on Object-Oriented Programming Emphasizing Practical Applictaions (SOOPPA), September 1990)). 1992 hat Opdyke dann seine Dissertation über das Thema abgeliefert. Beide Arbeiten finde ich leider nicht im Internet, aber zwei oder drei spätere. Die erwähnen das mathematische Analogon mit keinem Wort, wohl aber eine "Software Refactory", auf die das ganze rauslaufen soll. Ein gewisser Martin Fowler hat ein Buch über refactoring geschrieben, und das gemacht, was am naheliegensten ist, wenn was nicht klar ist: Er hat nachgefragt, und zwar bei Opdyke (und mir damit erspart, jetzt selber ne mail zu schreiben). Die Antwort findest Du unter [2], aber ich zitier das jetzt mal eben:

The one definite answer I got was from Bill Opdyke, who did the first thesis on refactoring. He remembered a conversation during a walk with Ralph Johnson. They were discussing the notion of Software Factory, which was then in vogue. They surmised that since software development was more like design than like manufacturing, it would be better to call it a Software Refactory. Refactory has gone on to be the name for the consulting organization that Ralph and his colleagues use

Dem ist dann wohl nichts mehr hinzuzufügen. Außer vielleicht, dass man jetzt noch rauskriegen müsste, wer das Analogon mit der Mathematik (das ja nur ein halbwegs passendes ist, refactoring kann nämlich auch heißen, Klassen zusammen zu fassen, im Analog: Terme auszumultiplizieren) aufgebracht hat. Ach so, und das ganze natürlich in den Artikel einzubauen, wenn Du nichts dagegen hast. Uli 12:18, 2. Nov 2003 (CET)

(Nachtrag: Opdykes Dissertation gibt's doch online, die engl. WP hat den Link. Ich musste das ganze nur nach *.ps.gz (statt *.ps.Z) umbenennen, und die ps Datei mit ps2pdf nach pdf konvertieren. Ghostview mochte das Ding nicht). Uli 12:40, 2. Nov 2003 (CET))

Hmm, scheint ja doch auf eine Herkunft von 'factory' herzukommen. Deine Recherche scheint näher an die Quellen heranzureichen als meine.

Gegen Erweiterung des Artikels habe ich natürlich nichts einzuwenden. -- Dishayloo 13:38, 2. Nov 2003 (CET)

Was spricht eigentlich dagegen dass wir das wort sinngemäß auch im deutschen nachkreieren? Besser wir als ein haufen von leuten die das deutsch verlernen. :( Also wenn man den gedanekngang von dem herrn Opdyke auf deutsch nachvollziehen würde sähe das wohl so aus: software-fabrik, software-refabrizierung, refabrizierung. ;)

Klingt zwar immer noch suboptimal von der menge der silben her... aber man könnte ja mit "refabben" abkürzen oder so... klingt gar nicht mal so schlecht wenn man's ein paar mal gehört hat...

Natürlich sind bessere vorschläge immer willkommen. Vorausgesetzt sie sind wirklich besser. ;)

Der Vorgang in einer Fabrik heißt im Deutschen Fabrikation. Dementsprechend hießen „Refactoring“ im Deutschen also „Refabrikation“, was meiner Meinung nach nicht schlecht klingt. --Phst 19:06, 12. Nov. 2006 (CET)

Unverständlich

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)

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)

Ich find's gut, danke! --Langec ☎ 10:45, 14. Mär 2005 (CET)

Hallo, ich finde es gut, daß der Fachbegriff Refactoring, der unübersetzt im Deutschen weiterverwendet wird, in seiner im Deutschen spezialisierten Bedeutung in der Wikipedia erklärt wird und nachgeschlagen werden kann. Am Artikel möchte ich jedoch kritisieren, daß die Häufigkeit des Wortes OCaml und seine Bedeutsamkeit in keiner Relation stehen. "Schleichwerbung" für persönliche Favoriten?

Entfernter Text

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)

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)

"Refaktorisierungen"

Ich habe mal die kleine peinlichkeit beseitigt, dass am anfang des textes zweimal davor gewarnt wird dass "refaktorisierung" unzutreffend wäre, und das wort danach trotzdem noch sechs mal zur verwendung kam. ;)

Ich weiss dass "Refactorings" auf deutsch irgendwie nicht gut klingt... Also wenn jemand eine bessere lösung hat... (aber bitte nicht wieder die "refaktorsierungen" ;)

--212.100.51.124 07:34, 21. Nov 2005 (CET)

Wenn der Begriff refactoring von factory = Fabrik kommt, könnte die deutsche Bezeichnung (angelehnt an: Fabrikation) dafür vielleicht Refabrikation heißen (Refabrizierung hätte irgendwie einen Beigeschmack). Falls sich der Begriff einbürgert könnt ihr sagen, der Begriff sei 2006 erstmals in diesem Zusammenhang (in der Wikipedia) genannt worden. Von: mir  :-). 2006 Mär 09. : 20:39 h

Funktionalität verringern versus verändern

Hier mein Senf, um einem Bearbeitungskrieg vorzubeugen: Refactoring verändert per Definition niemals die Funktionalität. Im Rahmen von Extreme Programming wird jedoch Refactoring vorbereitend vor Erweiterungen angewendet, um diese zu vereinfachen bzw. zu ermöglichen. --jpp ?! 13:36, 24. Apr 2006 (CEST)

Ich sehe das ziemlich ähnlich. Refactoring verändert erstmal keine Funktionalität. Natürlich verschwimmen die Grenzen teilweise etwas, z.B. wenn eine Methode aus einer Unterklasse in der Klassenhierarchie hochgezogen wird, dann steht sie mehr Klassen zur Verfügung, als zuvor und hat damit auch in gewisser Weise neue Funktionalität gebracht. Grundsätzlich muss aber in der Defintion die Abgrenzung zur normalen Implemenation erhalten bleiben. Diese Funktionalitätserweiterungen sind Nebeneffekte, aber nicht die eigentliche Intention von Refactoring.

Man kann das auch ganz gut bei der testgestützten Entwicklung sehen. 1) Test schreiben, der eine neue Funktionalität aufzeigt 2) Test möglichst schnell zum laufen bringen 3) Refactoren (Redundanzen entfernen). In diesem Verfahren wird das Einbringen neuer Funktionalität durch Refactoring mehr oder weniger explizit unterdrückt, weil neue Funktionalität nur in den Phasen 1/2 eingebracht werden soll.

Was das ganze mit XP zu tun hat, muss mir aber noch jemand erklären. XP setzt Refactoring ein, verändert doch aber die Defintion von Refactoring nicht. Gruß --Sprezz 17:03, 24. Apr 2006 (CEST)

XP hatte ich nur erwähnt, weil es in einem Bearbeitungskommentar genannt worden war und weil es ein wichtiges Anwendungsbeispiel ist. Siehe Versionsgeschichte des Artikels. --jpp ?! 08:33, 25. Apr 2006 (CEST)

Refaktorisieren noch mal

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)

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)

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)

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)

Danke, dein Lob wirkt erleichternd --Peu 13:36, 24. Okt. 2007 (CEST)

Digital=maximal unstetig

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)

Vorteile: "Performance" ergänzen?

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)

Nein, wenn sind das unangestrebte Nebenwirkungen. Siehe Refactoring von Martin Fowler, 2005 Addison-Wesley, Seite 42 der deutschen Übersetzung.

Sonstige Zwecke

Gehört das Fitmachen eines Quelltextes für eine andere Zielplattform dazu? Typischerweise beim Übergang von 32 zu 64 Bit des gleichen Betriebssystems. Bisweilen schleichen sich ungünstige Formulierungen ein, die erst beim Compilieren für die neue Plattform angemeckert werden. Debugging würde ich das nicht nennen, denn vorher waren ja keine Bugs drin. Insbesondere, wenn sich unverhofft Kopfdateien des Betriebssystemherstellers ändern.

Gehören notwendige Quelltext-Änderungen dazu, wenn bspw. eine neue Firmenpolitik plötzlich die maximale Warnstufe vorschreibt und (natürlich) warnungsfreie Übersetzungen? Was alles mit Warnungen versehen wird unterscheidet sich ja von Compiler zu Compiler und von Version zu Version. Was alles getan werden muss, um die Warnungen zu vermeiden macht manchen Quelltext eher schwerer verständlich, besonders für eingefleischte Programmierer.

--Henrik Haftmann (Diskussion) 14:22, 30. Nov. 2012 (CET)

@Fitmachen für andere Zielplattform - kommt darauf an. Wenn du jetzt eine Anforderung hast die SW für 64bit umzuschreiben, dann nennt man das Reengineering. Wenn du aber eine Software, die jetzt für 32bit ist und derzeit nur auf 32bit laufen soll so änderst, dass zukünftige Anforderungen (z.B. 64bit) leichter eingebaut werden können, dann ist das Refactoring.

@Warnings korrigieren - ja ist sicherlich Refactoring. Ziel ist immer die technische Qualität zu verbessern. Es gibt natürlich Warnings, die Blödsinn sind (und deshalb abgedreht werden sollten). Und es gibt Warnings die _nicht_ auf technische Qualität ausgerichtet sind, sondern z.B. auf Performance. Diese zu fixen macht man auch mit Refactoring Techniken, ist aber eigentlich nicht Refactoring, da Refactoring immer technische Qualität zum Ziel hat. --Sebastian.Dietrich ✉ 15:54, 30. Nov. 2012 (CET)

Risiken und deren Handhabung: automatisiert Refactorings

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)

Verständnisprobleme

"Aus diesem Grunde sind funktionale Sprachen (Lisp, Haskell, OCaml, Erlang und so weiter) wesentlich besser geeignet, ein Refactoring durchzuführen, da sie auf einem mathematischen Paradigma der Programmierung basieren. "

Das verstehe ich nicht. Wesentlich besser als was geeignet? Und was soll ich mir unter dem zugrundeliegenden mathematischen Paradigma vorstellen, dass diese Sprachen auszeichnet?

Hier fände ich eine etwas allgemeiner verständliche Erläuterung gut, denn den obigen Text versteht wohl nur jemand mit spezieller Erfahrung in diesen Dingen.

Weiter...

"Bei geänderten Geschäftsprozessen bei Darstellung mittels der Unified Modeling Language UML kann mittels „Refactoring“ der Programmcode geändert werden. Dadurch wird eine robuste und stabile Systemarchitektur geschaffen, da unübersichtliche Änderungen nicht im Code initiiert werden müssen"

Den Sprung vom Programmieren zu Geschäftsprozessen in UML-Darstellung finde ich etwas weit. Auch da fehlt mir irgendwie der Hintergrund.

weiter...

Welchen Bezug hat das "refactor’n" zum Auslagern? Ist das 'nur' das Modewort dafür?

195.145.170.174 11:57, 13. Nov. 2019 (CET)

Ich werde zwar selbst nicht den Artikel verbessern, kann jedoch ein paar Antworten geben:

• „Wesentlich besser als was geeignet?“
  • Gegenstück sind offenkundig die klassischen „imperative Programmiersprachen“ genannten Dingse, bei denen Schritt für Schritt einzelne ausführbare Anweisungen gegeben werden.
• „was soll ich mir … vorstellen“
  • Das ist schwer zu erklären.
  • Die fraglichen Methoden geben gewissermaßen nur die Rahmenbedingungen der Aufgabe vor, und die Software findet die Auflösung von selbst.
  • Dadurch hat man es mit keinerlei Einzelheiten mehr zu tun, sondern muss ggf. nur die Bedingungen aktualisieren.
  • Die Feststellung ist richtig, aber ohne das Wesen der aufgezählten Sprachen bzw. das Lösungsprinzip verstanden zu haben zugegebenermaßen schwer nachzuvollziehen.
  • Dabei kann eine Formulierung des Problems durch eine gleichwertige jedoch irgendwie elegantere und verständlichere Problemformulierung ersetzt werden, und das wäre gerade das Refactoring.
• „Geschäftsprozessen … UML“
  • Das ist im Prinzip auch sowas, allerdings mit einer ganz anderen Methodik.
  • Man legt mit den niedlichen Grafiken und sonstigen Spezifikationen der UML die Problemstellung fest, und dies in der Welt der fachlichen Anwender. Wobei die damit in der Regel nicht glücklich sind und das Modellierungssystem kaum verstehen.
  • Nun kann die Problemstellung verändert werden, und im Idealfall folgt die Programmierung dem automatisch. Man hat also wiederum nichts mit den einzelnen ausführbaren Anweisungen im Programmcode zu tun.
  • Dabei ist die neue Problembeschreibung im Prinzip gleichwertig der bisherigen, aber irgendwie eleganter, schlauer, übersichtlicher, robuster oder was.
• „auslagern“
  • Weiß ich auch nicht, ob das Modewort wäre.
  • Grundsätzlich ist das aber eine Spielart des Refactoring. Es geht in die Richtung Don’t repeat yourself. Heißt: Die konkreten Implementierungen in einzelnen Programmeinheiten werden ausgelagert in eine zentrale Methodik, und diese muss nur noch dort gepflegt und weiterentwickelt werden.

VG --PerfektesChaos 15:37, 13. Nov. 2019 (CET)