Refactoring ist der Schlüssel zu gutem Code. Exclusive icon | shutterstock.com Ich erinnere mich gerne an die Tech- und Entwicklerkonferenzen der 1990er und 2000er Jahre. In dieser magischen Zeit arbeitete ich als Object-Pascal-Entwickler und ließ mich regelmäßig von großartigen Präsentationen und transformativen Features begeistern. Insbesondere die Keynote zur damals neuen, ersten echten Java-IDE JBuilder ist mir dabei im Gedächtnis geblieben. Damals wählte JBuilder-Architektin Kate Stone auf der großen Bühne einen in ihrer Anwendung gängigen Variablennamen aus – und änderte ihn mit ein paar Klicks in der gesamten Codebasis. Für Entwickler von heute ist es ein quasi selbstverständliches Feature, Code innerhalb einer IDE zu refaktorieren – damals war es eine revolutionäre Neuerung, die fast schon an schwarze Magie grenzte. Gleichermaßen ist auch Martin Fowlers bahnbrechendes Werk “Refactoring” längst zum Mainstream geworden, die vorgestellten Konzepte werden von den allermeisten Devs verstanden. Das ist auch gut so, denn Refactoring ist essenziell und generell nützlich. Die folgenden drei Refaktorierungskonzepte allerdings ganz besonders. 1. Extract Method Dürfte ich nur ein einziges Refactoring mit auf eine einsame Insel nehmen, wäre es wohl Extract Method – die beste Waffe gegen undurchdringlichen Spaghetti-Code. Das Chaos, das entsteht, wenn verschachtelte if -Statements mit großen Code-Blöcken zwischen geschweiften Klammern zusammenkommen, rechtfertigt so gut wie immer, Methoden zu extrahieren. Man könnte auch argumentieren, dass eine if-Anweisung jeweils nur einen einzigen Methodenaufruf enthalten sollte. Ich persönlich würde sogar so weit gehen zu sagen, dass das Code Refactoring erst abgeschlossen ist, wenn es keinen Sinn mehr macht, Extract Method anzuwenden. Oder anders ausgedrückt: Wenn Sie eine Methode extrahieren können, tun Sie es. Wenn das in Ihrem Kopf ein Szenario mit einer Unmenge kleiner Methoden erzeugt: Diese sind sinnvoll benannt (siehe weiter unten) und nur für eine Sache zuständig. 2. Rename Variable/Method/Class Es mag vielleicht dumm klingen, aber Dinge richtig, respektive sinnvoll zu benennen, ist kein Kinderspiel. Das ist leicht zu belegen mit einem beliebigen Stück Legacy-Code, das sich durch ungünstig benannte Variablen, Methoden und Klassen auszeichnet. Das liegt unter Umständen auch daran, dass die genutzten Feinheiten nur dem Entwickler bekannt sind, der ursprünglich mit dem Code gearbeitet hat. In den meisten Fällen ist es aber ehrlicherweise einfach so, dass aus Zeitmangel schlechte Benennungen gewählt werden. An dieser Stelle kommt das Rename-Refactoring ins Spiel: Diese Möglichkeit, eine Variable einfach umzubenennen, sollten Sie nicht ungenutzt lassen. Wenn Sie feststellen, dass eine Benennung aus bestimmten Gründen ungünstig ist, bringen Sie sie in eine bessere, präzisere Form. Weil Sie das für die gesamte Codebasis nur ein einziges Mal tun müssen, brauchen Sie auch nicht davor zurückzuschrecken, längere und dafür eindeutigere Bezeichnungen zu nutzen. Ein paar Beispiele: RecordNumber ist besser als RecNo, CustomerRecordNumber sticht RecordNumber und für einen booleschen Wert empfiehlt sich CustomerNumberCannotBeZero statt CustNo > 0 . 3. Extract Variable Zeitmangel ist ein Problem, das Developer quasi kontinuierlich verfolgt. Das kann zu Ergebnissen führen wie: If CalculateInterestRate(GatherAllInputs()) > 0.6 { .. } Oder in Nicht-Code ausgedrückt: Wir übergeben ein Funktionsergebnis direkt in eine andere Funktion als Teil eines booleschen Ausdrucks – was problematisch ist. Denn erstens ist der Code schwer lesbar und damit auch entsprechend diffizil zu durchdringen, was Zeit kostet. Und zweitens ist er auch schwierig zu debuggen, was noch schwerer wiegt. Zum Vergleich derselbe Code – extrahiert in lesbare und Debugging-fähige Form: const AllTheInputs = GatherAllInputs(); const CustomerInterestRate = CalculateInterestRate(AllTheInputs); const CustomerInterestRateIsHighEnough = CustomerInterestRate > 0.6; If KundenZinsRateIstHochGenug { .. } Wenn Ihnen das zu viel Tipperei ist, kann ich Ihnen nur entgegnen, dass Faulheit (in den allermeisten Fällen) nicht karrierefördernd ist. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
3 Pflicht-Refactorings für Entwickler
Refactoring ist der Schlüssel zu gutem Code. Exclusive icon | shutterstock.com Ich erinnere mich gerne an die Tech- und Entwicklerkonferenzen der 1990er und 2000er Jahre. In dieser magischen Zeit arbeitete ich als Object-Pascal-Entwickler und ließ mich regelmäßig von großartigen Präsentationen und transformativen Features begeistern. Insbesondere die Keynote zur damals neuen, ersten echten Java-IDE JBuilder ist mir dabei im Gedächtnis geblieben. Damals wählte JBuilder-Architektin Kate Stone auf der großen Bühne einen in ihrer Anwendung gängigen Variablennamen aus – und änderte ihn mit ein paar Klicks in der gesamten Codebasis. Für Entwickler von heute ist es ein quasi selbstverständliches Feature, Code innerhalb einer IDE zu refaktorieren – damals war es eine revolutionäre Neuerung, die fast schon an schwarze Magie grenzte. Gleichermaßen ist auch Martin Fowlers bahnbrechendes Werk “Refactoring” längst zum Mainstream geworden, die vorgestellten Konzepte werden von den allermeisten Devs verstanden. Das ist auch gut so, denn Refactoring ist essenziell und generell nützlich. Die folgenden drei Refaktorierungskonzepte allerdings ganz besonders. 1. Extract Method Dürfte ich nur ein einziges Refactoring mit auf eine einsame Insel nehmen, wäre es wohl Extract Method – die beste Waffe gegen undurchdringlichen Spaghetti-Code. Das Chaos, das entsteht, wenn verschachtelte if -Statements mit großen Code-Blöcken zwischen geschweiften Klammern zusammenkommen, rechtfertigt so gut wie immer, Methoden zu extrahieren. Man könnte auch argumentieren, dass eine if-Anweisung jeweils nur einen einzigen Methodenaufruf enthalten sollte. Ich persönlich würde sogar so weit gehen zu sagen, dass das Code Refactoring erst abgeschlossen ist, wenn es keinen Sinn mehr macht, Extract Method anzuwenden. Oder anders ausgedrückt: Wenn Sie eine Methode extrahieren können, tun Sie es. Wenn das in Ihrem Kopf ein Szenario mit einer Unmenge kleiner Methoden erzeugt: Diese sind sinnvoll benannt (siehe weiter unten) und nur für eine Sache zuständig. 2. Rename Variable/Method/Class Es mag vielleicht dumm klingen, aber Dinge richtig, respektive sinnvoll zu benennen, ist kein Kinderspiel. Das ist leicht zu belegen mit einem beliebigen Stück Legacy-Code, das sich durch ungünstig benannte Variablen, Methoden und Klassen auszeichnet. Das liegt unter Umständen auch daran, dass die genutzten Feinheiten nur dem Entwickler bekannt sind, der ursprünglich mit dem Code gearbeitet hat. In den meisten Fällen ist es aber ehrlicherweise einfach so, dass aus Zeitmangel schlechte Benennungen gewählt werden. An dieser Stelle kommt das Rename-Refactoring ins Spiel: Diese Möglichkeit, eine Variable einfach umzubenennen, sollten Sie nicht ungenutzt lassen. Wenn Sie feststellen, dass eine Benennung aus bestimmten Gründen ungünstig ist, bringen Sie sie in eine bessere, präzisere Form. Weil Sie das für die gesamte Codebasis nur ein einziges Mal tun müssen, brauchen Sie auch nicht davor zurückzuschrecken, längere und dafür eindeutigere Bezeichnungen zu nutzen. Ein paar Beispiele: RecordNumber ist besser als RecNo, CustomerRecordNumber sticht RecordNumber und für einen booleschen Wert empfiehlt sich CustomerNumberCannotBeZero statt CustNo > 0 . 3. Extract Variable Zeitmangel ist ein Problem, das Developer quasi kontinuierlich verfolgt. Das kann zu Ergebnissen führen wie: If CalculateInterestRate(GatherAllInputs()) > 0.6 { .. } Oder in Nicht-Code ausgedrückt: Wir übergeben ein Funktionsergebnis direkt in eine andere Funktion als Teil eines booleschen Ausdrucks – was problematisch ist. Denn erstens ist der Code schwer lesbar und damit auch entsprechend diffizil zu durchdringen, was Zeit kostet. Und zweitens ist er auch schwierig zu debuggen, was noch schwerer wiegt. Zum Vergleich derselbe Code – extrahiert in lesbare und Debugging-fähige Form: const AllTheInputs = GatherAllInputs(); const CustomerInterestRate = CalculateInterestRate(AllTheInputs); const CustomerInterestRateIsHighEnough = CustomerInterestRate > 0.6; If KundenZinsRateIstHochGenug { .. } Wenn Ihnen das zu viel Tipperei ist, kann ich Ihnen nur entgegnen, dass Faulheit (in den allermeisten Fällen) nicht karrierefördernd ist. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
3 Pflicht-Refactorings für Entwickler Refactoring ist der Schlüssel zu gutem Code. Exclusive icon | shutterstock.com Ich erinnere mich gerne an die Tech- und Entwicklerkonferenzen der 1990er und 2000er Jahre. In dieser magischen Zeit arbeitete ich als Object-Pascal-Entwickler und ließ mich regelmäßig von großartigen Präsentationen und transformativen Features begeistern. Insbesondere die Keynote zur damals neuen, ersten echten Java-IDE JBuilder ist mir dabei im Gedächtnis geblieben. Damals wählte JBuilder-Architektin Kate Stone auf der großen Bühne einen in ihrer Anwendung gängigen Variablennamen aus – und änderte ihn mit ein paar Klicks in der gesamten Codebasis. Für Entwickler von heute ist es ein quasi selbstverständliches Feature, Code innerhalb einer IDE zu refaktorieren – damals war es eine revolutionäre Neuerung, die fast schon an schwarze Magie grenzte. Gleichermaßen ist auch Martin Fowlers bahnbrechendes Werk “Refactoring” längst zum Mainstream geworden, die vorgestellten Konzepte werden von den allermeisten Devs verstanden. Das ist auch gut so, denn Refactoring ist essenziell und generell nützlich. Die folgenden drei Refaktorierungskonzepte allerdings ganz besonders. 1. Extract Method Dürfte ich nur ein einziges Refactoring mit auf eine einsame Insel nehmen, wäre es wohl Extract Method – die beste Waffe gegen undurchdringlichen Spaghetti-Code. Das Chaos, das entsteht, wenn verschachtelte if -Statements mit großen Code-Blöcken zwischen geschweiften Klammern zusammenkommen, rechtfertigt so gut wie immer, Methoden zu extrahieren. Man könnte auch argumentieren, dass eine if-Anweisung jeweils nur einen einzigen Methodenaufruf enthalten sollte. Ich persönlich würde sogar so weit gehen zu sagen, dass das Code Refactoring erst abgeschlossen ist, wenn es keinen Sinn mehr macht, Extract Method anzuwenden. Oder anders ausgedrückt: Wenn Sie eine Methode extrahieren können, tun Sie es. Wenn das in Ihrem Kopf ein Szenario mit einer Unmenge kleiner Methoden erzeugt: Diese sind sinnvoll benannt (siehe weiter unten) und nur für eine Sache zuständig. 2. Rename Variable/Method/Class Es mag vielleicht dumm klingen, aber Dinge richtig, respektive sinnvoll zu benennen, ist kein Kinderspiel. Das ist leicht zu belegen mit einem beliebigen Stück Legacy-Code, das sich durch ungünstig benannte Variablen, Methoden und Klassen auszeichnet. Das liegt unter Umständen auch daran, dass die genutzten Feinheiten nur dem Entwickler bekannt sind, der ursprünglich mit dem Code gearbeitet hat. In den meisten Fällen ist es aber ehrlicherweise einfach so, dass aus Zeitmangel schlechte Benennungen gewählt werden. An dieser Stelle kommt das Rename-Refactoring ins Spiel: Diese Möglichkeit, eine Variable einfach umzubenennen, sollten Sie nicht ungenutzt lassen. Wenn Sie feststellen, dass eine Benennung aus bestimmten Gründen ungünstig ist, bringen Sie sie in eine bessere, präzisere Form. Weil Sie das für die gesamte Codebasis nur ein einziges Mal tun müssen, brauchen Sie auch nicht davor zurückzuschrecken, längere und dafür eindeutigere Bezeichnungen zu nutzen. Ein paar Beispiele: RecordNumber ist besser als RecNo, CustomerRecordNumber sticht RecordNumber und für einen booleschen Wert empfiehlt sich CustomerNumberCannotBeZero statt CustNo > 0 . 3. Extract Variable Zeitmangel ist ein Problem, das Developer quasi kontinuierlich verfolgt. Das kann zu Ergebnissen führen wie: If CalculateInterestRate(GatherAllInputs()) > 0.6 { .. } Oder in Nicht-Code ausgedrückt: Wir übergeben ein Funktionsergebnis direkt in eine andere Funktion als Teil eines booleschen Ausdrucks – was problematisch ist. Denn erstens ist der Code schwer lesbar und damit auch entsprechend diffizil zu durchdringen, was Zeit kostet. Und zweitens ist er auch schwierig zu debuggen, was noch schwerer wiegt. Zum Vergleich derselbe Code – extrahiert in lesbare und Debugging-fähige Form: const AllTheInputs = GatherAllInputs(); const CustomerInterestRate = CalculateInterestRate(AllTheInputs); const CustomerInterestRateIsHighEnough = CustomerInterestRate > 0.6; If KundenZinsRateIstHochGenug { .. } Wenn Ihnen das zu viel Tipperei ist, kann ich Ihnen nur entgegnen, dass Faulheit (in den allermeisten Fällen) nicht karrierefördernd ist. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!