Was bringt mir das Code Refactoring?

Eine der größten Entwicklungen zum Beispiel in der Automotive-Industrie war der Entwicklung der Baukasten-Systeme, bzw. Modularer Plattformen. Hierzu wurden alle Komponenten der Produktpalette unter die Lupe genommen und geschaut, wie man diese so gestalten kann, dass sie möglichst vielfältig eingesetzt werden. Das gipfelte nun darin, dass die Vorderachse bei einigen Herstellern von der Kompaktklasse, über die SUVs bis hin zu kleinen Lieferwagen in 8 verschiedenen Modellen zum Einsatz kommt. Gibt es nun große Weiterentwicklungen an dieser Komponente profitieren direkt 8 Modelle davon.

Ich denke, ihr merkt, wo ich hin möchte?
Häufig entsteht Software daraus, dass ein Entwickler auf dem weißen Stück Papier anfängt und los schreibt. Es werden Funktionen ergänzt, Code kopiert und Ausgaben an verschiedenen Stellen eingesetzt. Einige Tausend Zeilen Code später
ist der Spaghetti-Knoten dann perfekt. Jede Änderung birgt nun die Gefahr, dass sie den Code an anderer Stelle zum Einsturz bringt. Die Qualität der Software ist somit stark gefährdet und die Wartbarkeit nicht mehr gegeben.
Code Refactoring ist nun also der Umbau
dieses Legacy Codes in den Modularen Baukasten der Automobilindustrie hier bei uns in der Software-Qualitätssicherung und der Software-Entwicklung.

Was machen wir nun bei Code Refactoring?

Zu erst einmal muss man sich den gesamten Code einmal anschauen und überlegen, in welche Funktionseinheiten man ihn unterteilen kann. Dann fängt man an Nudel für Nudel aus dem Knoten herauszuziehen. Diese herausgelöste Funktionalität kann nun als eigene Komponente separat gepflegt und bei Bedarf immer wieder aufgerufen werden.
Wenn man mit der ersten Runde fertig ist, geht es in die nächste Runde. Hierbei schaut man sich die einzelnen Funktionseinheiten an und schaut, ob es sinnvoll ist diese weiter herunter zu brechen, in noch kleiner Einheiten. Vielleicht habe ich ja in zwei Einheiten eine Funktion, die ich an beiden Stellen verwenden möchte?
Am Ende ist der gesamte Code soweit herunter gebrochen, dass ich viele einzigartige Funktionen und Komponenten als eigene Einheit vorliegen habe. Wenn ich nun eine eingeführte Variable ändern möchte, brauche ich dies NUR EINMAL zu machen.

Durch die Modularität erhöht sich ganz nebenbei die Testbarkeit, denn ich kann die Komponenten losgelöst mit Unittests versehen. Der Software-Test beginnt schon während der Entwicklung und Bugs fallen schneller auf.
Bei Erweiterungen des Funktionsumfangs brauchen wir nicht mehr durch den gesamten Code zu wandern und zu schauen, an welchen Stellen ich die neue Funktionalität mit einbinden muss. Vielleicht lässt sich die eine oder andere Komponente ja auch in einem anderen Projekt verwenden?

Round-up

Unter dem Strich bekommen wir durch Code Refactoring also,
bessere Wartbarkeit für alle beteiligten und Nachfolger
mehr Übersicht, auch für Neueinsteiger im Projekt
Modularität die Zeit spart bei neuen Projekten
– Erhöhung der Zukunftssicherheit
Zeitersparnis bei der (Weiter-)Entwicklung
– Vereinfachung beim Software-Testing

Um es einmal plakativ zu sagen – und mit einem Augenzwickern: Coding as easy as Lego!

Was macht gute Software aus? (AAU – anonyme Apple User zur Qualität)

 

Hallo, ich bin Andreas und ich bin Mac-User!
Was für den einen oder anderen abfälligen Blick im Team sorgt..
Doch, dass ich Apple-Produkte nutze hat einen Grund!
Und der liegt in der Software-Qualität.

Ein kleiner Blick in die Vergangenheit:

2008; nach meinem ersten Jahr der Selbstständigkeit (Vertriebsaussendienst, Road-Warrior) reichte mein 1,6k€ teures Windows-Notebook, nach 2 Jahren imtäglichem Einsatz, den Löffel. Es musste also leistungsfähiger Ersatz her. Da auch das Enterprise-Office-Paket stark angejahrt war, ging die Rechnerei los. Neues Notebook+Office-Paket+X+Y+Z= viel Geld.

Zu dieser Zeit warb Apple mächtig um Umsteiger von Windows, mit Boot Camp und Parallels Desktop. Daher wagte ich das Experiment, da auch der Windows-Ersatz teuer geworden wäre, und schaute, was die Mac-Welt zu bieten hat. Gut, das Design und die Qualität der Komponenten hatten natürlich auch einen gewissen Einfluss. So kam ich zu meinem ersten MacBookPro mit iWork.
Die Feststellung nach wenigen Wochen? Große Verwunderung. Es war tatsächlich möglich an einem System zu arbeiten, das stabil läuft!
Keine Abstürzenden Office-Anwendungen, die einen um Stunden zurückwerfen, weil mal wieder vergessen wurde Zwischenstände zu speichern. Kein Blue-screen. Sofortige Einsatzbereitschaft nach dem Wecken aus dem Stand-by. System-Neustart.. wie geht das?

Kurz um, das Ding lief einfach und nervte nicht.
Selbige Beobachtung machte ich beim Wechsel von meinem Motorola Milestone auf mein erstes iPhone. Snappy in der Bedienung, stabil und funktional.
Langsam zeigten sich auch die Vorteile des Öko-Systems. Smartphone und Mac-Book funktionierten einfach zusammen. Keine Schmerzen, einfach nur Funktion.

Doch warum schreibe ich das auf dieser Seite??
Diese Erfahrung war für mich prägend in Sachen Software-Qualität!

Ok, mittlerweile bin ich in dieser Richtung auch verwöhnt und ertrage geringe Qualität in Software oder dem UI nur noch schwer. Seit dieser Zeit verstand ich Michaels Job des Softwaretesters und Software Qualitätsmanagers erst richtig.
MacOS und iOS laufen in ganz weiten Strecken absolut problemlos. Man kann davon ausgehen kann, dass schon während der Entwicklung kontinuierliches Testing stattgefunden hat. Und dass im Team einige Software-Qualitätsmanager sich viele Gedanken gemacht haben, wie man diese richtig Software testet. Da waren sicher gigabyteweise Testpläne erstellt, die jeden noch so unwahrscheinlichen Fall abdeckten. Diese Testpläne wurden durchgearbeitet, dann wurde gefixt. Und dann wurden sie noch einmal durchgearbeitet, dann wurde gefixt, und so weiter und so fort.

Dieser Aufwand kostet natürlich Zeit und Geld, einer der Gründe warum Produkte mit dem angebissenen Apfel doch etwas teurer sind als das Plaste-Notebook mit WindowsXYZ vom ortsansässigen Elektronik-Markt.
Auf lange Frist macht sich diese Qualität aber auch bemerkbar!

Eine Bitte an alle Softwareentwickler:

Wenn Ihr Software entwickelt, dann lasst sie bitte von einer anderen Person, die nicht in der Entwicklung beteiligt war, testen. Gut wäre es wenn Ihr hier für selbst einen umfangreichen Testplan erstellt habt. Noch besser ist es, wenn dieser Testplan von jemandem, basierend auf eurer Dokumentation oder Spezifikation erstellt hat. Diese unabhängige Person sollte den Plan nur abarbeiten und testen bis sie die Nase voll hat. Und dann bittet die nächste Person das Selbe zu tun. Und dann eine dritte Person. Und den nächsten, und den nächsten. Denn nur so, durch Softwaretest und Bugfixing, wird daraus ein Stück Software, was man gerne benutzt, weil es einfach funktioniert!

Wir helfen euch hierbei gerne, wenn Ihr selbst keine Zeit, keine Lust oder nicht genügend belastbare Mitarbeiter oder Bekannte habt 😉

Schaut hierzu vorbei auf: www.qa4software.deQA4software by AugMenVis