Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).
Refactoring: Warum es so WICHTIG für GUTEN CODE ist
Das Wichtigste aus dem Video
Tipp auf eine Zeit – das Video springt genau dorthin.
Transkriptautomatisch erstellt · 99 Zeilen
- Na, wie oft habt ihr euch schon an euer Projekt von vor zwei Wochen gesetzt und keine Zeile Code mehr wiedererkannt? Das ist schlechte Codequalität und tatsächlich das normalste der ganzen Welt.
- Projekte starten ja oft wild, mit tollen Ideen und man möchte möglichst schnell zu einem Ergebnis kommen. Nach ein paar Sprints, also kurzen Codeschreibeintervallen sozusagen, merkt man dann aber,
- dass es immer schwerer wird, sich da durchzubeißen. Man weiß nicht, was welche Funktion eigentlich macht und man muss ständig etwas anpassen.
- Auch nicht in der Datei, in der man gerade eigentlich arbeitet. Das passiert also in großen Unternehmen wie auch in privaten kleinen Projekten.
- Wir haben uns ja schon in einer ganzen Serie angesehen, wie man Code eigentlich wirklich clean halten kann. Wie er besser lesbar und besser wartbar ist.
- Aber tatsächlich klappt es auch oft genug mit diesen Tricks auch nicht. Eine große Aufgabe bei der Programmierung ist daher das Refactoring und darum geht es heute.
- Wo wir aber gerade dabei sind, auch in großen Unternehmen ist Refactoring ein häufiges Thema und daher habe ich euch heute einen Partner mitgebracht, der euch unbedingt möchte.
- Bosch. Klar, Refactoring ist nicht alles, was ihr bei ihnen machen werdet,
- aber unter uns, ihr werdet das Wissen aus diesem Video auf jeden Fall brauchen. Bosch ist vielleicht nicht unbedingt als IT-Arbeitgeber bekannt,
- für die, die aber aufmerksam die Coding-Challenges verfolgt haben, ist klar, dass Bosch unfassbar viel IoT, vor allem im Automotive-Bereich macht.
- Deswegen veranstalten sie auch eine spezielle Messe für alle Bewerber, wo ihr euch alles mal genau ansehen könnt, Fragen stellen könnt,
- mit potenziellen zukünftigen Kollegen über ihre Arbeit sprechen könnt und schauen könnt, ob das für euch wirklich alles passt.
- Dazu müsst ihr euch allerdings schon richtig bewerben, also naja, zumindest einen Lebenslauf hochladen müsst ihr.
- Das könnt ihr bis zum 15.03. noch machen. Alle Infos sind unten natürlich verlinkt. Und ich darf dann tatsächlich auch während der Messe auch wieder einen Coding-Challenge-Stream machen,
- der auch hier auf dem Kanal ausgetragen wird, was mich natürlich extrem freut. Der findet 10 Tage später, also am 25.03. im Livestream statt auf diesem Kanal
- und aktiv teilnehmen können diesmal nur die offiziellen Bewerber von Bosch. Allerdings könnt ihr als meine Community selbstverständlich danach
- trotzdem alle Aufgaben nochmal für euch lösen oder sie einfach so lösen. Dabei wünsche ich euch natürlich jetzt schon viel Spaß und viel Erfolg.
- Okay, dann lasst uns anfangen mit Refactoring. Für eine Definition davon möchte ich mal ganz kurz hier Martin Fowler zitieren.
- Allerdings übersetzt natürlich. Refactoring ist der Prozess, ein Software-System zu ändern,
- so dass sich das externe Verhalten des Codes nicht ändert, sich aber dennoch die interne Struktur verbessert.
- Es ist eine disziplinierte Möglichkeit, den Code aufzuräumen, die die Chance minimiert, Bugs einzuführen.
- Zusammengefasst ist Refactoring das Verbessern des Codes, nachdem er geschrieben wurde. Ich denke, das trifft den Nagel auf den Kopf.
- Ich möchte also durch Refactoring besser lesbaren und wartbaren Code haben, ohne sein Verhalten eigentlich zu ändern.
- Aber was bringt mir das denn jetzt? Häufig schreibt man einem Stück Code mehrere Entwickler.
- Das heißt, nicht nur ihr müsst mit eurem unlesbaren Stück zurecht kommen, sondern auch eure Kollegen und vor allem auch jemand ohne euch.
- Denn es garantiert ja niemand dafür, dass ihr für immer in diesem Betrieb bleibt. Es geht aber nicht nur um Dinge wie Variablen-Namen oder Funktions-Namen,
- sondern auch um die gesamte Struktur des Projektes. Durch Refactoring habe ich unabhängige logische Teile einer Funktion
- wirklich als unabhängige Funktion geschrieben, die ich dann auch leichter wiederverwerten kann.
- Dadurch kann ich nicht nur Fehler besser finden, sondern auch neue Features leichter erstellen.
- Ich kann leichter die Laufzeit messen und in kritischen Bereichen optimieren. Ungenutzter Code fällt auch leichter auf
- und dadurch kann zudem noch Speicher eingespart werden. Kurzum, eure Code-Qualität, die ja durchs Refactoring gesteigert wird,
- macht mehr Features schneller möglich, verringert Abstürze, macht Sicherheitsprobleme dadurch offensichtlicher
- und verbessert die Performance, auch wenn ihr allein an einem Projekt arbeitet. Das sind doch eigentlich alles ziemlich gute Argumente.
- Kurz einführen möchte ich auch den Begriff der Technical Debt, der technischen Schuld, die eine Metapher dafür ist,
- dass Manager von Projekten oft an der falschen Stelle Geld einsparen. Häufig fehlt die Zeit für sauberen Code,
- ein neues Feature muss bis zu einer Deadline zum Beispiel eingehalten werden und Geld für neue Entwickler ist auch einfach nicht da.
- Auch vermeintlich günstige Entwickler, die nur für das Projekt bezahlt werden, jedoch nicht so sehr auf die Code-Qualität achten,
- produzieren diese technische Schuld, wie man so schön sagt. Man schiebt also absolut notwendige Maßnahmen wie Refactoring einfach auf
- und erhält einen riesen Schuldenhaufen, der es immer schwerer macht, neue Features zu entwickeln.
- Laut Roger Pressman kann sich sogar der Aufwand für neue Features um das 60- bis 100-fache steigern, wenn man kein Refactoring durchführt.
- Das heißt, ein Feature, das mit sauberem Code eine Stunde gebraucht hätte, braucht ohne Refactoring bis zu 100 Stunden Arbeit.
- Privat ist das natürlich höchst frustrierend, für Firmen sind das aber zweieinhalb Entwickler und eine ganze Woche Arbeit
- für eine Aufgabe, die eine Person in einer Stunde machen könnte. Der Druck auf die Entwickler für neue Features steigt dadurch noch mehr
- und sie haben noch weniger Zeit fürs Refactoring. Das ist eine waschechte Teufelsspirale, die ein Projekt wirklich kippen kann.
- Okay, aber wie messe ich jetzt, wie gut Code refactored wurde und ob er das vielleicht sogar ganz dringend nötig hat?
- Hier wird es jetzt ein kleines bisschen schwerer, denn Codequalität ist in Teilen etwas Subjektives
- und wir hassen Subjektivität normalerweise. Aber wie gesagt, nur in Teilen.
- Es gibt Möglichkeiten, etwas konkret zu messen und die können euch zeigen, welche Stelle in eurem Code es am dringendsten nötig hat.
- Linter zum Beispiel geben euch schnell Aufschluss darüber, dass eure Einrückung nicht gut ist
- und dass zum Beispiel eine Funktion mehr als 350 Zeilen lang ist und damit definitiv zu lang ist.
- Die sogenannte Cyclomatic Complexity ist ebenfalls eine tolle Metrik. Sie gibt an, wie viele linear unabhängige Pfade durch euren Source Code möglich sind
- und wird über den Kontrollflussgraphen berechnet. Sinkt diese, ist das auch wieder ein gutes Zeichen.
- Eine weitere wichtige Metrik könnt ihr über Tests finden, die ihr dazu natürlich erstmal en masse braucht.
- Refactoring sollte nun im besten Fall dazu führen, dass erstmal mehr Bugs gefunden werden.
- Das ist vielleicht eher etwas Schlechtes, aber die Bugs zu reparieren, das führt dann dazu,
- dass natürlich insgesamt weniger Bugs in euren Projekten drin sind. Sprich, während des Refactorings repariert man automatisch sehr viele Bugs.
- Zudem sollte sich die Anzahl der Unit Tests natürlich extrem erhöhen. Im Normalfall habt ihr nämlich nach dem Refactoring mehr Funktionen,
- die auch aluunabhängig getestet werden können. Das macht euer gesamtes Software-System viel robuster.
- Jetzt ist aber natürlich die Frage, wie? Das Video hier will euch nur einen kleinen Überblick geben.
- Wenn ihr wirklich tiefer in die Materie allerdings eintauchen wollt, dann sagt mir bitte Bescheid, dann hänge ich hier noch mehr Videos ran.
- Die erste Möglichkeit Refactoring zu betreiben ist RedGreenRefactor. Das klappt nur in Kombination mit Test Driven Development,
- was ein eigenes Video bekommen wird und hier nur ganz kurz erwähnt sei. Bei Test Driven Development, kurz TDD,
- wird kurz gesagt erst der Test geschrieben und dann der Code. Bei RedGreenRefactor wird das Ganze um eine dritte Stufe erweitert.
- Red heißt also, schreib deinen Test. Der muss natürlich jetzt failen, weil es gibt ja noch keinen Code.
- Der wird also am Anfang rot, deswegen Red. Green bedeutet, schreib den Code zu dem Test,
- dass der Test eben erfolgreich durchläuft, sprich, dass das Testergebnis grün ist.
- Und Refactor heißt, schau durch deinen Code durch und direkt nachdem du ihn geschrieben hast,
- überleg dir, ob du irgendwo was optimieren kannst, ob du was auslagern kannst.
- Also gibt es zum Beispiel Funktionen, die du auslagern kannst? Gibt es andere Codes, zum Beispiel?
- Hier nochmal kurz der Verweis an meine Clean Code Reihe, die ihr euch in diesem Zusammenhang definitiv nochmal anschauen solltet.
- Es gibt eine Reihe von Mustern, die man hierzu verwenden kann, so eben auch Compose Method, wo ihr versucht, eine Methode zu erstellen,
- die dann an mehreren Stellen genutzt werden kann. Auch sehr wichtig ist Branch by Abstraction,
- wo noch eine zusätzliche Schicht in eure Architektur eingezogen wird, um den nicht ganz so tollen Code besser zu abstrahieren
- und Refactoren zu können. Wir schauen uns das aber gerne nochmal in kommenden Videos genauer an
- und sprechen dann wirklich in der Codeebene darüber. Auch durch Tools kann man sich das Leben beim Refactoren,
- also bei dem eigentlichen Vorgang, sehr viel leichter machen. Die meisten gängigen IDEs bieten euch alle möglichen Hilfestellungen an,
- um den Prozess ebenso leicht wie möglich zu machen. Werfen wir hierzu mal ganz kurz einen Blick in IntelliJ
- bzw. alle JetBrains IDEs, mit denen ich ja immer arbeite. Tippt ihr dort zum Beispiel STRG, ALT, SHIFT und T an,
- ja, vier Tasten auf einmal, bekommt ihr wie hier zu sehen ein Untermenü mit allen Optionen, also zum Beispiel Umbenennen einer Variable,
- eine Funktion, eine Variable, Konstante oder sowas zu extrahieren oder sogar eine eigene Klasse für etwas zu erschaffen.
- Auch das müsste ich allerdings mal im Detail in einer Serie vielleicht zu der IDE selbst zeigen.
- Vielleicht macht das ja auch sogar Sinn. Trotz all der Unterstützung und vor allem trotz all der Notwendigkeit
- liegen die Probleme allerdings häufig woanders. Ihr als Entwickler habt ja durchaus auch ein Interesse daran,
- dass ihr Refactoring betreiben könnt. Sonst wird euer Job frustrierend, um nicht zu sagen nervtötend.
- Aber häufig bleibt dann auch die Frage, wo soll ich überhaupt anfangen? Kann ich das zeitlich schaffen oder muss ich ein neues Feature
- wirklich per Deadline liefern? Gibt es vielleicht auch wirklich regelmäßig einen Sprint,
- der nur zum Refactoring eingeplant ist? Haben meine Kollegen da überhaupt auch Bock drauf?
- Und wird Codequalität auch wirklich im Team und bei Reviews durchgedacht? Gerade wenn das Management oder die Senior Entwickler
- den Wert von Coderefactoring nicht unbedingt so wertschätzen oder kennen, kann das ein Problem sein.
- Und eher früher als später landet man dann bei Legacy Code mit dem Kommentar Ich habe keine Ahnung warum das läuft, aber wenn ich es lösche,
- klappt gar nichts mehr. Bitte bloß nicht anfassen. Das habe ich tatsächlich so schon mal in Code gesehen.
- So etwas ist zwar witzig, führt aber auf lange Frist dazu, dass euer privates Projekt vereingelassen wird
- und Projekte sogar in großen Unternehmen einfach eingestampft werden oder komplett neu geschrieben werden,
- weil sie einfach zu teuer und festgefahren sind. Daher lasst mich hier nochmal ganz kurz auf Bosch aufmerksam machen.
- Die haben mir gegenüber mehrfach schon betont, wie wichtig ihnen Codequality ist.
- Falls ihr also gerne Hardware nahe arbeitet und Erfahrung mit C++ mitbringt, bewerbt euch direkt nach diesem Video und dann hören bzw. sehen wir uns
- spätestens beim Coding Turnier wieder. Bis dahin könnt ihr schon mal auf the-morphikes.cc ein bisschen üben gehen.
- Wir haben auch ein paar neue Challenges für euch und ich wünsche euch allen viel Spaß dabei.
- Ciao.
Zum Nachlesen
RefactoringRefactoring ist ein zentraler Bestandteil der Agilen Softwareentwicklung. Dort wird meist von „kontinuierlichem“ Refactoring oder „kompromisslosem“ Refactoring …
CodequalitätCodequalität ist ein Teilaspekt von Softwarequalität, mit dem insbesondere nicht-funktionale Anforderungen wie Konformität, Verständlichkeit, Analysierbarkeit, …
Technische SchuldenAlistair Cockburn zeigt auf, dass das Aufnehmen von technischen Schulden einem der Grundwerte der agilen Softwareentwicklung, dem der aufrechterhaltbaren …
Clean CodeClean Code ist ein Begriff aus der Softwaretechnik, der durch das gleichnamige Buch von Robert Cecil Martin populär wurde. Als „sauber“ (clean) bezeichnen …