Des Pudels Kern

Wann soll man Details einer Funktion in Unterfunktionen extrahieren, weil man ansonsten "den Wald vor lauter Bäumen nicht sieht"? Und wann soll man lieber die Details sichtbar lassen? Welches sind die Vor- und Nachteile ​​der folgenden Beispiele und welches favorisiert ihr? 1. Alle Details import sys def main(): numbers = [int(argument) for argument in sys.argv[1:] if str.isnumeric(argument)] for i in range(0, len(numbers)): for j in range(1, len(numbers) - i): if numbers[j] 2. Alle Details mit Kommentaren import sys def main(): #Read numbers from command line numbers = [int(argument) for argument in sys.argv[1:] if str.isnumeric(argument)] #Sort numbers for i in range(0, len(numbers)): for j in range(1, len(numbers) - i): if numbers[j] 3. Drei Unterfunktionen mit konkreten Namen import sys def main(): numbers = readNumbersFromCommandLine() sort(numbers) writeNumbersToConsole(...

Heute möchte ich eine weitere Möglichkeit zur Vermeidung von bedingten Verzweigungen mittels if vorstellen. Außerdem möchte ich hier an alle Softwareentwickler den Appell richten, doch bitte kleine Funktionen zu schreiben. Meine diesbezügliche Leidensgeschichte* beginnt mit einem Absturz aufgrund eines Timeouts. Eine Routine braucht länger als vorgesehen und wird nach Ablauf der vorgeschriebenen Zeit vom überwachenden Thread abgeschossen. Was ist die Ursache? Eine aufwändige Berechnung? Eine Endlosschleife? Die einzige Debugmöglichkeit ist das Einfügen von printf -Anweisungen, um die Stelle zu finden, an der das Programm zum Stehen kommt. Sehr hilfreich wären hier jetzt kleine Integrationsfunktionen, die keine Logik enthalten und nur andere Funktionen aufrufen. Zwischen die Funktionsaufrufe jeweils ein printf eingefügt, ausführen und sehen, welches printf nicht mehr aufgerufen wird. Daraufhin in die davor ausgeführte Funktion abtauchen, bis man an der Wurzel des Übels angekommen ist...

Ich arbeite gerade einen Vortrag über TDD aus und möchte hier schon einmal eine erste Version zur Kritik stellen. Vorbemerkung Ich spreche hier von einem Werkzeug, nicht von einem Entwicklungsdogma. Dieses Werkzeug hat Vor- und Nachteile und ist in machen Situationen gut zu gebrauchen und in anderen weniger. Mir geht es darum, dieses Werkzeug vorzustellen und seine Anwendung zu zeigen, damit daraufhin dann jeder Entwickler eine bewusste Entscheidung für oder gegen diese Technologie treffen kann. Test First Was wohl jeder Entwickler über Test Driven Development weiß, ist dass der Test bereits geschrieben und ausgeführt wird, bevor der zugehörige Produktivcode existiert. Man schreibt zuerst einen Test, der fehlschlägt, dann schreibt man soviel Produktivcode wie nötig ist, damit der Test grün wird. Dann refaktorisiert man den Code und beginnt mit dem Zyklus erneut. Entsprechend nennt man diesen Prozess: Red (Test schlägt fehl), Green (Test ist erfolgreich), Refactoring (Programmcode wird ...

Hier meine aktuelle Fachlektüre: "Effektives Arbeiten mit Legacy Code" von Michael C. Feathers Das Buch, welches ich momentan täglich aufschlage. Vor allem als Vorbereitung zu dem kommenden Code Retreat . Für Feathers ist Legacy Code produktiver Code, für den es keine Tests gibt. Entsprechend beschäftigt sich die Hälfte des Buchs mit der Frage, wie man Legacy Code unter Test stellen kann, bevor man ihn verändert. Dabei zeigt Feather pragmatische Auswege aus dem Dilemma, dass man erst refaktorisieren soll, wenn der Code getestet wird; zum Testen der Code aber erst refaktorisiert werden muss. "Clean Code" von Robert C. Martin Das Buch, welches man sich zu Herzen nehmen sollte, damit Feathers Buch in der Schublade bleiben kann. Benutze ich momentan eher als Nachschlagewerk. "Clean Architecture" von Robert C. Martin Das aktuelle Buch von Onkel Bob. Fokussiert nicht mehr (nur) auf den Code, sondern diskutiert die Beziehung der Komponenten de...

Ich bereite gerade wieder einen Code Retreat vor. Diesmal einen "Legacy Code Retreat". Statt "TDD" steht diesmal "Golden Master" und statt "Clean Code" "Refacoring" im Fokus. Mal sehen ob und wie wir vorwärts kommen und ob wir dann auch saubereren Code commiten können. Und vor allem wie sich die Teilnehmer im Nachgang dazu äußern werden.

Der Statistik nach scheint "Code Retreat: Keine If-Ausdrücke" der am häufigsten gelesene Artikel dieses Blogs zu sein (Wie geht das, bei nur zwei Lesern?). Dabei enthält der Artikel nur ein unsinniges Anti-Pattern und ist damit nicht sehr hilfreich. In diesem Artikel möchte ich deswegen etwas nützlichere Informationen geben. Ich wechsle dabei in den Beispielen zwischen C#- und Python-Code hin und her :-) Natürlich sind bedingte Verzweigungen (if, switch, ?-Operator) nicht an sich schlecht. Allerdings kann es Alternativen zu ihrer Verwendung geben, die den Code übersichtlicher und verständlicher machen. Ob das in einem konkreten Fall wirklich so ist, muss dann situativ entschieden werden. Fall 1: Desine decision vs. Runtime decision Einige Ifs können manchmal schon entfernt werden, weil sich herausstellt, dass die Fallunterscheidungsinformationen bereits zur Zeit der Programmierung und nicht erst zur Laufzeit zur Verfügung steht. Mit If: File Open ( string path,...

Laut einer Studie (hier das englischen Original ) des Bezahldienstleisters Stripe, gehen 42 Prozent der Arbeitszeit eines Entwicklers für die Beschäftigung mit technischen Schulden und "Bad Code" drauf. Ich habe das gerade erst wieder Freitag selbst erlebt. Ich habe den ganzen Tag mit der Erweiterung eines von mir entwickelten Skripts zugebracht, welches ich schon länger nicht mehr "angefasst" hatte (was ein gutes Zeichen ist, denn es ist in der ganzen Abteilung fast täglich im Einsatz und die Bugs halten sich demnach in Grenzen :-)). Allerdings waren mir dadurch die Feinheiten der API nicht mehr so ganz präsent, so dass ich nach einigen Stunden plötzlich in einen Fehler lief (beim manuellen Testen. Selbstverständlich gab es keine ständig ausführbaren, voneinander unabhängigen automatischen Tests). Also debugged (mittels "print") und irgendwann schlug dann die Erkenntnis zu: Stimmt ja, dieser Befehl führt den Code ja verzögert aus. Variablen die dar...

Ich hatte am letzten Samstag einen Code Retreat organisiert. Dabei hatten wir auch zwei Sessions mit der Vorgabe, keine If-Ausrücke (auch keine switches oder ?-Operatoren) zu verwenden. Folgendes fand sich daraufhin haufenweise im Code eines Paares: while (a == 1 ) { //do something break ; } Soviel also zum Ziel, saubereren Code zu schreiben... Konstruktivere Beispiele findet man stattdessen im Artikel "Ohne Wenn und Aber" .

Ich habe mich mal wieder in Javascript ausgetobt. Ich hatte mir zwar selbst selbst die Grenze von 500 Zeilen gesetzt, habe diese aber leider gerissen. Nun werde ich wohl noch weitere Arcade-Titel schreiben müssen, die gemeinsame Funktionalitäten nutzen, damit die einzelnen Spiele im Durchschnitt unter der Grenze bleiben :-) Hier auf jeden Fall also das erste Spiel der 500-Lines-Challenge: Panel with bocks .

So, es wird mal wieder Zeit für ein wenig Sport – also im Informatikersinne. Nehmt Euch ein kleines Projekt, wärmt Euch kurz auf und dann programmiert los. Aber Achtung! Dabei müsst Ihr folgende neun Regeln beachten: Verschachtele in jeder Methode nur bis zur ersten Ebene! Nutze kein ELSE! Verpacke alle primitiven Datentypen in spezielle Klassen! Eine Collection sollte die einzige Variable einer Klasse sein! Greife nur auf die Objekte zu, die Du direkt kennst! Schreibe alle Namen aus und verwende keine Abkürzungen! Klassen sollten nicht länger als 50 Zeilen und Packages sollten nicht mehr als 10 Dateien enthalten! Verwende nicht mehr als zwei Instanzvariablen in einer Klasse! Erlaube keinen Zugriff von Außen auf Deine Instanzvariablen! Viel Spaß!

Im vorletzten Entwicklermagazin las ich über Code Retreats . Das liest sich spannend. Hat damit schon einmal jemand Erfahrungen gemacht?

Hier möchte ich noch zwei Quellen zum Thema verlinken: Zum einen eine Liste der "Code-Gerüche" und zum anderen ein Katalog von Refactoring-Methoden .

Bevor ich von Refactoring hörte, hieß die Antwort auf schlechte Wartbarkeit (Weiterentwicklung, Fehlerbereinigung) und Performanceprobleme von Softwarekomponenten Redesign: Es wurden Klassendiagramme und ggf. Aktivitätendiagramme des Ist-Zustands erstellt und auf diesem Abstraktionsniveau dann überlegt, wie das Zieldesign aussehen soll. Dann wurde versucht, diesen Entwurf mit einem mehr oder weniger großen Ruck in Sourcecode zu gießen. Beim Refactoring bleiben wir auf dem Niveau des Sourcecodes; und wir machen kleine Schritte. Aber lassen wir die Theorie und schauen wir uns einfach mal ein Refactoring im Beispiel an. Legen wir los! Vielleicht stoße ich bei der Lektüre einer mir fremden Quelldatei auf die folgende Methode: public void Buy(String x) { if ((Int32.Parse(x[0]) * 1 + Int32.Parse(x[1]) * 2 + Int32.Parse(x[2]) * 3 + Int32.Parse(x[3]) * 4 + Int32.Parse(x[4]) * 5 + Int32.Parse(x[5]) * 6 + Int32.Parse(x[6]) * 7 + Int32.Parse(x[7]) * 8 ...

Gibt es noch irgendeinen Programmierer, der noch nicht von Refactoring gehört hat? Diesen möchte ich vorschlagen, sich einmal damit zu beschäftigen. Gerne kann ich auch auf Wunsch den einen oder anderen Artikel dazu schreiben. Empfehlen möchte ich jedoch auch gerne das Buch, welches mir vor einigen Jahren die Konzepte des Refactorings auf unterhaltsame und kurzweilige Weise nahebrachte: Refactoring. Oder wie Sie das Design vorhandener Software verbessern . Ok, als ich es gekauft habe war es noch günstiger als die aktuelle englische Ausgabe .