Definition

Der Begriff wurde zum ersten Mal in einer Arbeit von Ralph Johnson und William Opdyke 1990 gebraucht (Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In: Proceedings of Symposion on Object-Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990). Opdyke promovierte 1992 zu dem Thema. Sie entwickelten die Idee einer Software-Refactory, die das Umgestalten (eben das Refactoring) von Computerprogrammen erleichtern sollte. Die unzutreffende Übersetzung Refaktorisierung stammt aus einer Verwechslung mit einer häufig zitierten Analogie, die ursprünglich nicht Begriffsinhalt war: Refactoring ist eine Art, ein Programm so zu modifizieren, dass man verborgene Strukturen offenlegt, ohne die Funktionalität zu ändern. Dies, so der (fälschliche) Analogieschluss, entspreche dem Vorgehen der Faktorisierung von Polynomen in der Mathematik. Bin aber kein Mathematiker 😉

Warum ist Refactoring wichtig?

• Verbesserung der Code-Lesbarkeit: Lesbarkeit ist entscheidend, um den Code effizient zu warten und zu erweitern. Durch das Refactoring können Entwickler den Code vereinfachen, Duplikate entfernen und konsistente Benennungen und Formatierungen verwenden, um die Lesbarkeit zu verbessern.
• Reduzierung der technischen Schulden: Technische Schulden entstehen, wenn man die Software in Eile entwickelt, ohne auf Qualitätsstandards zu achten. Sie führen oft zu schwer zu wartendem und unzuverlässigem Code. Es hilft, technische Schulden zu reduzieren und verhindert, dass sie sich im Laufe der Zeit anhäufen.
• Optimierung der Code-Wartbarkeit: Refactoring hilft dabei, den Code modular und gut strukturiert zu halten, was die Wartung und Fehlerbehebung erleichtern kann.
• Verbesserung der Code-Performance: Durch das Entfernen von unnötigem Code und die Optimierung von Algorithmen kann Refactoring dazu beitragen, die Performance der Software zu steigern.
• Erleichterung der Teamarbeit: Ein sauberer und gut strukturierter Code ist leichter zu verstehen und ermöglicht eine effektivere Zusammenarbeit zwischen Entwicklern.

Strategien für effektives Refactoring

• Code Smells identifizieren: „Code Smells“ sind Anzeichen dafür, dass man den Code möglicherweise verbessern muss. Beispiele sind lange Methoden, große Klassen, doppelter Code und unklare Benennungen. Entwickler sollten diese Anzeichen erkennen und entsprechende Maßnahmen ergreifen, um den Code zu verbessern.
• Schrittweise Verbesserungen vornehmen: Refactoring sollte schrittweise erfolgen, um den Code schrittweise zu verbessern und gleichzeitig die Funktionalität intakt zu halten.
• Automatisierte Tests verwenden: Um sicherzustellen, dass die Funktionalität nach dem Refactoring unverändert bleibt, ist es entscheidend, automatisierte Tests zu verwenden. Dies stellt sicher, dass Änderungen am Code keine unerwünschten Nebenwirkungen verursachen.
• Konsistente Coding-Standards einhalten: Ein konsistenter Codierungsstil erleichtert das Lesen und Verstehen des Codes. Es ist wichtig, dass das gesamte Team die gleichen Standards einhält, um Inkonsistenzen zu vermeiden.
• Regelmäßiges Refactoring betreiben: Man Refactoring als fortlaufenden Prozess betrachten, der in die tägliche Arbeit eines Entwicklers integriert ist. Regelmäßiges Refactoring hilft dabei, den Code kontinuierlich sauber und auf dem neuesten Stand zu halten, wodurch man die langfristige Wartbarkeit der Software verbessern kann. Außerdem hilft es dabei, den Code zu besser verstehen und tiefere Erkenntnisse über das Programmieren selbst zu erhalten.

Beliebte Refactoring-Techniken

1. Extract Method: Wenn eine Methode zu lang oder zu komplex ist, kann sie in kleinere, gut definierte Methoden aufgeteilt werden, um die Lesbarkeit und Wartbarkeit des Codes zu verbessern.
2. Rename Variable/Method/Class: Durch das Umbenennen von Variablen, Methoden und Klassen in klarere und aussagekräftigere Namen kann man den Code verständlicher und leichter pflegbar machen.
3. Remove Duplication: Duplikate im Code können Wartungsprobleme verursachen und man sollte sie entfernen. Bei der Erkennung von Duplikaten können Entwickler allgemeine Funktionen extrahieren und wiederverwenden, um den Code zu straffen.
4. Replace Conditional with Polymorphism: Anstatt mehrere bedingte Anweisungen zu verwenden, kann man Polymorphismus eingesetzen, um den Code besser zu strukturieren und die Lesbarkeit zu erhöhen.
5. Encapsulate Field: Durch das Kapseln von Feldern in Klassen und die Bereitstellung von Zugriffs- und Mutationsmethoden kann man den Code modularer und besser wartbar machen.

Tools und Programme

Es gibt eine Vielzahl von Tools und Programmen, die Entwicklern beim Refactoring helfen. Nachfolgend sind einige der gängigsten Tools für verschiedene Programmiersprachen (Einige davon habe ich bereits in diversen Beiträgen thematisiert. Hierzu einfach auf die jeweiligen Verlinkungen klicken oder die Suchfunktion verwenden 😉 ):

Integrated Development Environments (IDEs): Viele moderne IDEs bieten integrierte Refactoring-Unterstützung für verschiedene Programmiersprachen an. Einige der bekanntesten sind:

a. JetBrains IntelliJ IDEA (Java, Kotlin, Scala, u.a.)

b. JetBrains PhpStorm (PHP)

c. JetBrains PyCharm (Python)

d. JetBrains ReSharper (C# in Visual Studio)

e. Microsoft Visual Studio (C#, C++, VB.NET)

f. Eclipse (Java)

g. Xcode (Swift, Objective-C)

Standalone-Tools: Es gibt auch eigenständige Refactoring-Tools, die man unabhängig von der IDE verwenden kann. Einige Beispiele sind:

a. JDeodorant (Java)

b. SonarLint und SonarQube (Java, JavaScript, TypeScript, u.a.)

c. JSLint und ESLint (JavaScript)

d. RuboCop (Ruby)

e. Clang-Tidy (C++, Objective-C)

Code-Editor-Erweiterungen: Viele Code-Editoren, wie Visual Studio Code und Sublime Text, verfügen über Erweiterungen, die Refactoring-Unterstützung für verschiedene Programmiersprachen bieten. Einige dieser Erweiterungen sind:

a. Visual Studio Code Refactoring Extensions (z.B. Python, JavaScript, TypeScript, PHP, Ruby, C#)

b. Sublime Text Refactoring Plugins (z.B. Anaconda für Python, JsPrettier für JavaScript)

Es ist wichtig zu beachten, dass jedes Tool seine eigenen Stärken und Schwächen hat. Ein Entwickler sollte die verfügbaren Optionen für seine Programmiersprache und seinen Arbeitsablauf sorgfältig prüfen, um das am besten geeignete Refactoring-Tool zu finden.

Fazit

Refactoring ist ein wesentlicher Bestandteil des Softwareentwicklungsprozesses, der es ermöglicht, den Code sauber, lesbar und wartbar zu halten. Durch das Identifizieren von „Code Smells“, die Anwendung bewährter Techniken und das kontinuierliche Integrieren von Refactoring in den Arbeitsablauf können Entwickler qualitativ hochwertigen Code schreiben, der leicht zu verstehen und zu erweitern ist.

Die Investition in regelmäßiges Refactoring zahlt sich langfristig aus, indem sie dazu beiträgt, die technischen Schulden zu reduzieren und die Zusammenarbeit im Team zu verbessern. Der Schlüssel zum erfolgreichen Refactoring liegt in der Kombination aus automatisierten Tests, konsistenten Codierungsstandards und einem proaktiven Ansatz zur Code-Optimierung. Durch die Priorisierung von Refactoring in der Softwareentwicklung können Entwickler sicherstellen, dass ihre Projekte skalierbar und zukunftssicher sind.

Der Beitrag Refactoring – Optimierung und Evolution für nachhaltigen Code erschien zuerst auf CEOsBay.

Es bietet eine Reihe von Funktionen und Tools, die es Entwicklern erleichtert, effektive und zuverlässige Tests für ihre JavaScript-Anwendungen zu schreiben. Zu den Funktionen von Jest gehören unter anderem:

Automatisierte Testausführung:

Jest führt Tests automatisch aus, wenn es Codeänderungen erkennt. Dies beschleunigt den Entwicklungsprozess und sorgt dafür, dass man häufiger bzw. effektiver Tests ausführen kann. Dies steigert am Ende des Tages die Qualität der Anwendungen grundsätzlich.

Snapshot-Tests:

Mit Jest können Entwickler Snapshot-Tests durchführen. Dadurch stellt man sicher, dass das Rendering der Komponenten oder Funktionen konsistent stattfindet. Dies kann auch dabei helfen, visuelle Fehler in der Benutzeroberfläche zu identifizieren und zu beheben.

Mocking:

Jest erleichtert das Erstellen von Mocks und Stubs für Abhängigkeiten, die man in den zu entwickelnden Anwendungen verwendet. Dies kann Entwicklern dabei helfen, ihre Tests zu isolieren und sicherzustellen, dass die Ausführung unabhängig voneinander stattfindet.

Codeabdeckung:

Jest bietet eine integrierte Codeabdeckungsfunktion. Dies ermöglicht den Entwicklern die Überprüfung, wie viel des Codes während der Testausführung abgedeckt ist. Dies kann helfen, Lücken in der Testabdeckung zu identifizieren und die Qualität der Anwendung insgesamt zu verbessern.

Parallele Testausführung:

Jest kann Tests parallel ausführen, was die Testdauer verkürzt, und die Gesamtgeschwindigkeit des Entwicklungsprozesses erhöht.

Fazit

Insgesamt ist Jest ein leistungsstarkes Testframework für JavaScript-Anwendungen, dass eine breite Palette von Funktionen bietet, um Entwicklern dabei zu helfen, effektive und zuverlässige Tests für ihre Anwendungen zu schreiben. Es ist eine wichtige Technologie für die Entwicklung moderner JavaScript-Anwendungen und viele Entwickler sowie Unternehmen weltweit nutzen es.

Der Beitrag Jest – Test-Framework für Testautomatisierung erschien zuerst auf CEOsBay.

Kurze Zeitreise

Bis zum Aufkommen der Microservice-Architekturen wurde Software klassischerweise als Monolith entworfen. Dabei gab es keinerlei interne Schnittstellen, da alle Informationen im Monolithen weitergereicht werden konnten. Dementsprechend konnte man sich im Testing nur auf die Stufen Unittests, Integrationstests und End-to-End-Tests konzentrieren. Mit dem Aufkommen der Microservice-Architekturen existiert nun eine Vielzahl an internen Schnittstellen und damit entsteht die Notwendigkeit, diese zu testen. Die Kommunikation der Services untereinander geschieht dabei nicht zufällig, sondern folgt klar definierten Regeln, den sogenannten Schnittstellen-Contracts.

Was ist Contract Testing?

Wie bereits angesprochen, wurde die korrekte Zusammenarbeit von API und Consumer meist durch Integrationstests sichergestellt. Da diese allerdings eine lauffähige Systemlandschaft benötigen, können Fehler erst relativ spät erkannt werden. Bei der Entwicklung ist es jedoch von Vorteil, das Feedback so früh wie möglich zu erhalten. Hinzu kommt, dass Integrationstests eigentlich zum Prüfen der Fachlichkeit dienen. In heutigen Testlandschaften stellen sie strenggenommen „nur nebenher“ fest, wenn es technische Probleme an der Schnittstelle gibt. Das kann sowohl bedeuten, dass der Aufwand bei der Fehlersuche steigt, weil neben fachlichen Problemen auch technische Ursachen zum Fehlschlag des Tests führen können, als auch der Wartungsaufwand der Tests sich erhöht.

Macht also Sinn, dedizierte Tests zu nutzen, um Fehler an Schnittstellen zu finden. Hier bietet sich Contract Testing, genauer gesagt, Consumer Driven Contract Testing (CDCT) an. Verträge für Softwarekomponenten. Der Zusatz „Consumer Driven“ bedeutet, der Consumer bestimmt den Vertrag (Aus diesem Grund nennt man es auch Consumer Contract) und das sich die API nach dessen Vorgaben richten muss.

Neben Consumer Contracts gibt es die etwas verbreiteteren Provider Contracts wie WSDL-/XML-Schemata von SOAP-APIs oder Werkzeuge wie Swagger im Kontext von REST-Services.

Auch wenn sich die Funktionsweise von Framework zu Framework unterscheidet, bleibt die Idee dahinter gleich. Der Provider erfüllt den vom Consumer definierten Vertrag.

Der Vertrag enthält die API samt Parameter und die erwartete (minimale) Antwort. Dabei kann die Beschreibung der Parameter durch den Einsatz von regulären Ausdrücken beliebig präzise sein. So kann der Consumer erwarten, beim Aufruf der API einen unbestimmten String-Parameter oder einen bestimmten String-Parameter aus einem vordefinierten Set zu übergeben. Der zweite Fall ist äußerst hilfreich, wenn der Provider diesen String-Parameter in einen Enum-Wert übersetzt.

Der Consumer Test mit Pact

Sämtliche Verträge zwischen dem Consumer und dem Provider werden in einer JSON-Datei, auch Pact-Datei genannt, definiert. Der Consumer generiert diese Pact-Datei beim Ausführen seiner Pact-Tests und veröffentlicht sie auf dem Pact-Broker. Bei den Tests handelt es sich um gewöhnliche Unit-Tests und sie basieren auf einem der vielen von Pact unterstützen Test-Frameworks wie JUnit oder Jest. In dem Test ruft der Consumer die zu testende API inklusive Parameter auf. Der Aufruf wird von einem Mock-Provider, der vom Pact-Framework zur Verfügung gestellt wird, entgegengenommen. Der Mock-Provider prüft, ob dieser Aufruf mit dem Aufruf aus dem Vertrag übereinstimmt. Sind keine Abweichungen gefunden, antwortet der Mock-Provider mit der minimalen Antwort, die ebenfalls aus dem Vertrag stammt. Der Consumer empfängt in seinem Test die Antwort und vergleicht sie mit seiner Erwartung. Stimmen sie überein, ist der Test erfolgreich. Auf diesem Weg stellt der Pact-Test sicher, dass der Consumer den Aufruf tätigen und die Antwort verarbeiten kann.

Der Pact-Broker ist ein Webserver, der sowohl vom Consumer als auch vom Provider erreichbar sein muss. Er verwaltet die Verträge, indem er sie versioniert ablegt, sie dem Provider zur Verfügung stellt und die Testergebnisse speichert. Die Art und Weise wie der Consumer die Verträge auf dem Pact-Broker veröffentlicht, ist abhängig von der eingesetzten Programmiersprache der Tests und/oder dem eingesetzten Dependendency-Management. Für Maven beispielsweise gibt es ein spezielles Pact-Plugin, das den publish-Goal anbietet, für JavaScript existiert hingegen eine spezielle Pact-Version mit dem Namen Pact-js.

Der Provider Test

Analog zum Consumer-Test ist der Provider-Test auch ein Unit-Test und wird im Rahmen der restlichen Unit-Tests ausgeführt. Hierbei werden alle Verträge, die der Provider mit seinen Consumern abgeschlossen hat, vom Pact-Broker heruntergeladen. Der Aufruf der APIs erfolgt lokal, sodass ein Aufruf durch den Consumer simuliert wird. Der Provider verarbeitet den Aufruf und generiert seine Antwort, die mit der erwarteten Antwort aus dem Vertrag verglichen wird. Sollten sie gleich sein, hat der Provider den Pact-Test bestanden. Ansonsten gilt der Test als fehlgeschlagen und das Artefakt des Providers kann nicht ordnungsgemäß gebaut werden. Die Ursache für Fehlschläge sind in den meisten Fällen Code-Änderungen am Provider ohne den Consumer entsprechend angepasst zu haben oder die Erwartungshaltung des Consumers ist fehlerhaft. In beiden Fällen wird durch CDCT ein Missstand aufgedeckt, der erst zur Laufzeit bemerkbar gewesen wäre.

Alternativen zu Pact

Natürlich ist Pact nicht das einzige Framework zum Implementieren von CDCT, wenn auch aktuell eines der am weitesten verbreiteten. Neben Pact existieren noch ein paar weitere Möglichkeiten für das vertragsbasierte Testen wie Postman, Spring Cloud Contract Project oder Dredd, auf die ich noch in zukünftigen Beiträgen eingehen werde. Aus diesem Grund erfolgt auch das Fazit erst, wenn ich ein paar Vergleiche aufstellen kann.

Der Beitrag Pact.io – Für die nahtlose Integrationstestautomatisierung durch Contract Tests erschien zuerst auf CEOsBay.