Titelaufnahme

Titel
Refactoring und seine Kennzahlen
Weitere Titel
Refactoring and Its Parameters
VerfasserSackl, Daniel
GutachterRadinger-Peer, Wolfgang ; Müllan, Gerald
Erschienen2013
Datum der AbgabeSeptember 2013
SpracheDeutsch
DokumenttypBachelorarbeit
Schlagwörter (DE)Analyse / Code / CodePro AnalytiX / Design / Eclipse / Halstead / Java / Kennzahlen / Klassen / Lines of Code / Maintainability-Index / McCabe-Metrik / Messung / Methoden / Metrics / Modifikationen / Objekte / Optimierung / Programm / Refactoring / Softwareentwicklung
Schlagwörter (EN)Analyse / Code / CodePro AnalytiX / Design / Eclipse / Halstead / Java / Kennzahlen / Klassen / Lines of Code / Maintainability-Index / McCabe-Metrik / Messung / Methoden / Metrics / Modifikationen / Objekte / Optimierung / Programm / Refactoring / Softwareentwicklung
Zugriffsbeschränkung
 _
Klassifikation
Zusammenfassung (Deutsch)

In dieser Arbeit wurde dargestellt, was Refaktorisierung ist und mit welchen Kennzahlen man es veranschaulichen kann. Die Refaktorisierung ist ein Tool zum Strukturieren von Code und sorgt für die nötige Klarheit. Das Problem besteht dabei darin, dass ein refaktorisierender Programmierer keine neuen Funktionen hinzufügen kann. Außerdem hat die Refaktorisierung keinen augenblicklichen Einfluss auf den Code. Der Erfolg setzt erst zu einem späteren Zeitpunkt ein.

Da der Kunde von der Refaktorisierung selbst kein klares Ergebnis sieht, wird es oft stiefmütterlich behandelt. Trotzdem führt sie dazu, dass Fehler leichter gefunden und zukünftige Funktionen schnell implementiert werden. Es gibt aber auch Punkte, welche eine Refaktorisierung erschweren:

 Datenbanken

 Änderungen an den Schnittstellen

 Ein von Grund auf falsches design

Es gibt verschiedene Arten von schlechtem Code. So kann es vorkommen, dass man duplizierten Code in seinem Programm findet, hauptsächlich bei der Arbeit mit Copy and Paste, um Zeit zu sparen. Lange Methoden oder große Klassen erschweren die Verständlichkeit.

Mit einigen konkreten Vorgehensweisen kann man wieder eine straffe Struktur in seinen Code bringen. Als Beispiel hierfür sei das Aufteilen von großen Methoden in mehrere kleine angeführt. Dies trägt nicht nur zur Übersicht bei, es macht auch so manchen Kommentar überflüssig und erhöht die Chance, einzelne Methoden wiederzuverwenden.

In der Softwareentwicklung gibt es 3 Kategorien wie Kennzahlen eingeteilt werden können. Dies erfolgt nach der Quantität, Qualität und Komplexität.

Bei quantitativen Kennzahlen handelt es sich um Mengenzahlen. Zum Beispiel wie viele Lines of Code ein Programm hat.

Bei Qualitativen Kennzahlen geht es um die Definierung von Normen und wie sich ein Nicht-Einhalten auf die Qualität des Codes auswirkt.

Die Komplexität gibt an, wie viele Beziehungen ein Element zu einem anderen hat.

Ziele einer Messung können sein:

 Der Anwender möchte eine vorhandene Anwendung migrieren und möchte wissen wie umfangreich dies ist

 Der Anwender möchte wissen wie hoch der Wartungsaufwand ist

 Der Anwender steht vor einer Neuentwicklung und möchte wissen, wie groß und wie komplex die alte Anwendung war

 Der Anwender hat Probleme und möchte die Anwendung analysieren

 Verschiedene Systeme sollen verglichen werden

 Kosten und Nutzen verschiedener Strategien

 Gesundheitszustand eines Systems feststellen

 Veränderung der Quantität nach einer Refaktorisierung

 Veränderung der Komplexität nach einer Refaktorisierung

Die Quantität lässt sich einfach an Hand der Linces of Code messen. Wobei diese Art der Messung nicht mehr zeitgemäß ist.

Mit der Halstead Methode lässt sich die Komplexität messen. Wobei hier nur mehr die Volumens- und Komplexitäts-Formel gültig sind. Die Korrektheit der Aufwandsformel wurde wiederlegt.

Die Qualität kann man mithilfe des Maintainability-Index bestimmten, welcher sich aus dem Volumen pro Modul, der zyklomatischen Komplexität pro Modul und der Anzahl an Codezeilen pro Modul zusammensetzt.

Mit Eclipse bekommt man als Entwickler ein leistungsfähiges Tool an die Seite gestellt, welches von IBM ins Leben gerufen wurde. Es bietet von vornherein die Möglichkeit der Refaktorisierung und ist seit einiger Zeit Open-Source.

Da es sich bei Eclipse um ein RCP Tool handelt, gibt es genug Plugins zur Generierung der Metriken. Die Installation der verschiedenen Plugins sollte trotz Marktplatz komplizierter als gedacht sein. Am Ende wurden die Metriken mit Metrics und CodePro AnalytiX erhoben.

Anhand eines Beispiels der Firma SPIRIT Business & Finance Solutions GmbH konnte ich klar veranschaulichen, dass eine Refaktorisierng nicht nur Spielerei ist, sondern erheblichen Einfluss auf die Komplexität, Quantität und Qualität hat.

Des Weiteren wurde auch ersichtlich, dass die zwei verwendeten Tools bei denselben Metriken unterschiedliche Ergebnisse lieferten. Im Umkehrschluss heißt dies, dass man Metriken unterschiedler Programmen nicht miteinander vergleichen kann. Man sollte daher bei Messungen immer bei ein und demselben Tool bleiben.

Zusammenfassung (Englisch)

This bachelor thesis shows what refactoring is and what indicators can illustrate it. Refactoring is a tool for organizing code and provides the necessary clarity. The problem with refactoring is that a programmer who is refactoring cannot add new features. Moreover, refactoring has no immediate effect on the code; achievement can be observed at a later on.

The customer does not get a clear result of refactoring, it often gets neglected. Nevertheless, refactoring means that errors can be found easier and future functions are implemented quicker. However, there are also some points which make it difficult to refactor:

Databases

Making changes to the interface

Wrong design

There are various kinds of bad code. Therefore, it can happen that we find duplicated code in our program. This happens mostly when you have worked with copy and paste to save time. Long methods or large classes make it difficult to understand what code is doing.

With a few specific procedures we can tighten a decayed code structure again. For example, by splitting large methods into several small ones. This not only contributes to the overview, it also makes some comments superfluous and increases the possibility to reuse several methods.

Software development metrics can be divided in 3 categories. These are quantity, quality and complexity.

Quantitative metrics are an indicator for an amount. For example, how many lines of code a program has.

When it comes to the qualitative metrics, you have to define standards and how they affect the quality if you do not adhere to them.

The complexity metric indicates how many relationships one element has to another one.

Goals of a measurement can be:

 The user wants to migrate an existing application and want to know how extensive this is

 The user wants to know how much the maintenance is

 The user stands in front of a new development and would like to know how big and how complex the old application was

 The user has a problem and wants to analyse the application

 Different systems should be compared

 Costs and benefits of different strategies

 The user wants to determine the health of a system

 How the quantity changes after a refactoring

 How the complexity changes after a refactoring

The quantity can be easily measured with reference to the Linces of code. But this type of measurement is no longer up to date. You can use the Halstead method to measure the volume and complexity. The formula for the effort was disproved.

The quality can be determined by using the Maintainability Index. Which is composed of the volume for each module, each module of the cyclomatic complexity and the number of lines of code per module.

By working as a developer with Eclipse you get a powerful tool, which was released by IBM. It deals a priori with the ability to refactor. Since a few years it has been open-source. Eclipse is a RCP tool; as a result, there are a lot of plugins to generate the metrics. The installation of various plugins should be more complicated than expected despite marketplace. All the metrics were collected with Metrics and CodePro AnalytiX.

SPIRIT Business & Finance Solutions GmbH provided me an example code. So I could illustrate that refactoring is not only playing but has significant impact on the complexity, quality and quantity.

Furthermore, it was also apparent that the two tools I used were showing different results for the same metrics. Conversely, this means that you cannot compare metrics from different programs. You should always stay with the same tool.