Wo lohnt sich Code Refactoring?
Guest User
Wenn ein Code einfach und leicht verständlich ist, können neue Features schneller und mit weniger Bugs implementiert werden. Wachsende Softwaresysteme neigen dazu mehr Komplexität anzuhäufen. Frederik Brooks differenziert in seinem Artikel "No Silver Bullet" zwischen zwei verschiedenen Arten von Komplexität: Essenzielle Komplexität, eine unvermeidliche, der Problemdomäne inhärente Komplexität und versehentliche Komplexität, eine unnötige Komplexität, die durch schlechtes Design entsteht und entfernt werden könnte.
Bei der Implementierung neuer Features oder bei Fehlerbehebungen muss ein bestimmter Teil des Codes verstanden werden. Dabei muss sowohl die essenzielle als auch die versehentliche Komplexität berücksichtigt werden. Um künftig die Kosten für eine Änderung oder Erweiterung des Codes zu senken, kann die versehentliche Komplexität entfernt werden.
Wann lohnt sich Code Refactoring, um die versehentliche Komplexität zu beseitigen?
Angenommen wir haben ein Stück Code mit versehentlicher Komplexität und dasselbe Stück Code, bei dem wir die versehentliche Komplexität eliminiert haben, wie in Abbildung 1 dargestellt. Es lohnt sich nur dann, ein Stück Code zu refactoren, wenn sich diese beiden Linien während der Laufzeit des Projekts kreuzen.
Um ein Code zu finden, dessen Refactoring sich lohnt, können wir zunächst die komplexen Teile des Codes finden und dann evaluieren wie oft sie gelesen werden.
Auffinden von komplexen Codes
In einer Codebase mit nur wenigen hundert Codezeilen kann der Code einfach komplett gelesen werden, um die Teile zu finden, die unnötig komplex sind, während dies in großen Codebases mit Hunderttausenden von Codezeilen nahezu unmöglich ist.
Es gibt Werkzeuge, die einen komplexen Code durch automatisches Scannen großer Mengen von Codes finden. Sie tun dies, indem sie Eigenschaften des Codes messen, die mit erhöhten Kosten bei der Implementierung neuer Features oder der Behebung von Bugs korrelieren, wie z.B. der Umfang der Kopplung, die Größe der Methoden oder dem Anteil der Duplizierung.
Ein Code finden, der oft gelesen wird
Wir wissen, dass ein Code, der sich in der Vergangenheit oft geändert hat, sich wahrscheinlich auch in der Zukunft oft ändern wird. Anhand der Daten aus dem Version Control System kann abgeschätzt werden, wie oft auch in Zukunft ein Stück Code noch geändert werden muss.
Kombinieren der Daten
Abbildung 2 zeigt jedes Stück Code als Kreis dargestellt. Der Code in der oberen rechten Ecke ist ein komplexer Code, der häufig geändert werden muss. Dieser Code lohnt sich zu refactoren da er bei der Wartung und Weiterentwicklung viel Kosten verursacht.
Indem wir einen langfristigen Blick auf den künftig erforderlichen Wartungsaufwand werfen und unser Code-Refactoring systematisch angehen, können wir die Wartungskosten erheblich senken. Durch die erhöhte Transparenz unseres Codes sparen wir Zeit und Geld, so dass wir uns auf das konzentrieren können, was wirklich wichtig ist und unsere Gehirnzyklen für die wesentlichen Komplexitäten des Lebens verwenden können.
