Refactoring: Angstbegriff für die Einen. Permanente Motivation für die Anderen. Der ultimative Endgegner bei alten wie auch neuen Codebasen. Refactoring bringt alles auf den neuesten Stand. Das ist doch gut, oder?
Fast jeder Developer ist schon mal in die Falle des endlosen Refactorings verfallen. Hier noch eine neue Lib. Da etwas noch generisch machen. Diese Zeile mit der “geilsten Pipe” ersetzen, die man gerade erdacht hat. Und das kann man ja auch noch performanter…
Refactoring ist Fluch und Segen, weil Refactoring zumeist nicht genau bestimmt wird. Was ist Refactoring? Ein paar Code Smells? Eine nicht mehr wirklich praktizierte Programmiersprache? Ein nicht mehr gepflegtes Betriebssystem? Alles potenzielle Fälle für “Refactorings”. Also ist die Definition nicht so einfach. Ach, einfach erstmal anfangen…
Und dann erlebt man Refactorings, die parallel zum Live System über die Jahre entwickelt werden und entweder unter Schmerzen einfach scharf geschaltet werden oder einfach nie online gehen. Denn wie kann ein “Re”factoring jemals der Gegenwart gleich sein? Kann Refactoring überhaupt ein “Plan” sein?
Torben und Savas haben schon einige Refactorings selbst gemacht, sich verlaufen, oder sie betreut. Was sind ihre spannendsten Erinnerungen an Refactorings und welche Fallen verstecken sich im Projektmanager Angstbegriff “Refactoring”?
Solltet ihr Feedback zum Podcast oder speziell dieser Folge haben, schreibt uns an codebarn@zackbummfertig.tv oder findet uns auf LinkedIn. Und passende Sticker zu unseren Podcastthemen findet ihr unter https://loet.bar/.
Weiterführende Links:
