Refactoring vs. Restrukturierung

Ich habe das Gefühl, dass der Begriff Refactoring mittlerweile bei einigen entscheidend verbreitet ist und deshalb möchte ich mich in diesem Video etwas nähern und dem Begriff der Restrukturierung gegenüberstellen. Um dies zu tun, betrachten wir erst einmal zwei unterschiedliche Arten von Quellcode. Am einfachsten ist immer der Umgang mit neuem Code. Neuer Quellcode, der wird von keinem anderen verwendet, außer demjenigen, der ihn schreibt, und daher kann er auch leicht verändert werden. Wenn mir hier ein Variablennamen nicht gefällt, dann ändere ich den halt. Das dürfte keine weiteren Auswirkungen auf andere haben. Anders ist es natürlich bei Code, der schon verwendet wird und bei dem man möglicherweise nicht mehr ganz weiß, was er eigentlich tut. Die gesteigerte Form davon ist der Legacy Code, wobei nicht ganz sicher ist, was mit Legacy hier unbedingt gemeint ist. Es gibt viele unterschiedliche Arten von Definitionen rund um Legacy Code. Persönlich mag ich es eigentlich eher als Bestandscode zu übersetzen. Das ist gut, der halt einfach da ist und der tut eigentlich auch das, was er soll, also meistens. Das große Problem ist nur, dass er nicht mehr ganz verstanden wird. Michael C. Feathers hat es deshalb auch so geschrieben, dass man Angst davor hat, den Code zu verändern, weil z.B. keine Tests vorliegen. Jede Änderung, die man macht, könnte zu möglichen Problemen führen. Refactorings sind auf der einen Art Möglichkeiten, um Legacy Code beherrschbar zu machen, weil sie dafür sorgen, dass er so strukturiert wird, dass man ihn wieder versteht. Um ihn aber strukturieren zu können, muss man ihn verstehen. Und schon hat man ein kleines Problem, denn allzu schnell widerspricht man der ursprünglichen Definition von Refactorings, die da sagt, dass ein Refactoring eine strukturelle Veränderung ist, aber keine Verhaltensänderung. Und so kann es sein, dass ein veränderter Variablenname oder eine extrahierte Klasse mit einmal den Build brechen lässt, das Deployment kaputtmacht und dafür sorgt, dass die Produktion für einige Stunden still steht. Das Ganze wird noch dadurch verschärft, dass Refactorings sich ganz schnell zu Restructurings auswachsen. Die ursprüngliche Definition von Refactoring sagt auch, dass es eine kleine Code-Änderung ist. In Bestandscode kann diese Veränderung aber dazu führen, dass man eben nicht nur eine kleine Veränderung macht, sondern noch eine und noch eine und noch eine. Und das addiert sich dann eben zu einer großen Restrukturierung um. Dabei ist wichtig zu beachten, dass solche Restructurings, solche strukturellen Anpassungen eben gleich zu setzen wären mit anderen strukturellen Anpassungen wie Migration, Portierung oder Sanierung. Bei einer Migration weiß jeder, dass das nicht so einfach passieren kann, dass man Daten von einem Datenbankmanagementsystem in ein anderes z.B. überträgt. Während Kollege Meier aber anfängt zu entwickeln, den Code leicht anpasst und immer weiter anpasst, merkt man die Auswirkung seitens Tuns meistens erst, wenn er das Ganze dann committet hat in den Master-Branche, der allen zur Verfügung steht und möglicherweise auch ausgerollt ist. Der Schaden ist dann schon angerichtet. Also Refactoring wird zwar gern umgangssprachlich genutzt, um eine Code-Restrukturierung zu bezeichnen, was auch komplett richtig ist, aber Refactorings können sich ganz schnell zu großen Restrukturierungen auswachsen. Und wenn man da den Punkt verpasst, an dem man aufhören sollte, zu refaktorisieren, dann kann das sehr große und sehr negative Auswirkungen haben. Jetzt habe ich aber tatsächlich den Bogen ein bisschen weit gespannt. Für mich war wichtig, dass Sie begreifen, wo ist der Unterschied und was wollen Sie eigentlich. Wollen Sie einfach nur ein bisschen Code verändern, dann tun Sie das und diskutieren Sie nicht es lange herum, insofern das eine Verbesserung darstellt und auch das Verständnis innerhalb Ihres Teams trifft. Machen Sie Ihre Anpassungen, solange die sich nicht allzu weit auswirken, und machen Sie lieber kleine Anpassungen als große. Irgendwann in dem Software-Lebenszyklus Ihrer Anwendung kommen Sie aber an den Punkt, dass größere Umbaumaßnahmen unbedingt notwendig sind. Dann planen Sie diese auf, sagen Sie, was Sie machen wollen, welche Risiken damit verbunden sind, und dann machen Sie einen Plan mit den entsprechenden Entscheidern, um diese Ziele zu erreichen und die Risiken zu minimieren.