\chapter{Einleitung}
In dieser Arbeit soll genauer untersucht werden, was Refactoring tatsächlich an Code verändert, welche Möglichkeiten es gibt ein bestimmtes Verhalten überhaupt darzustellen.
Als Grundlage dieser Arbeit gilt das 11. Kapitel aus dem Buch \textit{„five lines of code“} von Christian Clausen \cite{fiveLines.2023}.
Dieses wurde im Rahmen des Seminars „Refactoring“, bei Professor Dr. Georg Hagel, untersucht und für diese Arbeit aufgearbeitet. 
Das Kapitel des Buchs kann zwar eigenständig gelesen werden, aber ein grundlegendes Verständnis von Refactoring ist trotzdem erforderlich.\\
Außerdem wird erläutert, in welchen Situationen auf ein Refactoring verzichtet werden sollte und welche Gründe es dafür gibt.\\
Anschließend sollen einige Maßnahmen vorgestellt werden, mit denen Sicherheit erlangt werden kann, dass Code ordnungsgemäß funktioniert.
Gerade nach einem umfassenden Refactoring spielt dies eine große Rolle. 
Abschließend werden einige Fälle vorgestellt, in denen Refactoring aus verschiedenen Gründen häufig nicht durchgeführt wird und es wird gezeigt wieso dies der Fall sein sollte.
\chapter{Strukturen in der Softwareentwicklung}
Bevor man sich mit den Strukturen in der Softwareentwicklung auseinandersetzen kann, ist es wichtig, sich erneut vor Augen zu führen, was Software eigentlich ist.\\
"\emph{Software modelliert einen Teil der Welt. Die Welt - und unser Verständnis davon - entwickelt sich, und unsere Software muss sich entwickeln, um ein akkurates Modell zu sein.}" \citep[S. 311]{fiveLines.2023}\\
Dies heißt außerdem das Software nie fertig ist, da sie sich immer an die Ständig ändernde Welt anpassen.\\
Code bildet also verschiedenste Gegebenheiten aus der Realität ab. Darunter zählen Informationen, Zusammenhänge und ganze Abläufe.
Zusammen ergibt sich dadurch eine Struktur, ein wiedererkennbares Muster, welches sich sowohl in der echten Welt als auch in der Software finden lässt. \citep[S. 311]{fiveLines.2023}
\subsubsection{Verschiedene Arten von Strukturen}

Es gibt verschiedene Bereiche in der Softwareentwicklung, in denen Struktur eine Rolle spielt.
Es ist möglich diese an zwei Achsen einzuteilen.
Zum einen gibt es einige Faktoren welche den Menschen, also die Softwareentwickler direkt betreffen, oder aber den tatsächliche Code.\\
Auf der zweiten Achse wählt Clausen den Wirkungsbereich als Einteilung \citep[S. 311]{fiveLines.2023}.
Die folgende Tabelle zeigt das Ergebnis der Einteilung.


\begin{table} [ht]
	\centering
	\begin{tblr}{
		vline{2} = {-}{},
		hline{2} = {-}{},
	}
			& Teamintern           & Teamübergreifend           \\
	Code     & Daten und Funktionen & externe APIs               \\
	Menschen & Hierarchie, Prozesse & Verhalten, Domänenexperten 
	\end{tblr}
	\caption{Strukturkategorien \cite{fiveLines.2023} (korrigierte Form)}
	\label{tab:Auswertungskategorien}
\end{table}


Melvin E. Conway stellt bereits 1968 Beobachtungen an, dass es eine gewisse Symmetrie zwischen der Arbeitsweise von Entwicklerteams und den Zusammenhängen der tatsächlichen Systeme gibt. \cite{conway.1968}
\par
Auch das Nutzerverhalten kann bestimmte Strukturen vorgeben, da diese ein immer gleiches Verhalten erwarten.
Auch wenn einige Abläufe optimiert oder umstrukturiert werden können, ist es nicht immer sinnvoll dies zu tun, da dann ggf. Nutzer neu geschult werden müssen.\citep[S. 312]{fiveLines.2023}
