{"id":19696,"date":"2023-07-19T12:28:14","date_gmt":"2023-07-19T12:28:14","guid":{"rendered":"https:\/\/devologyx.io\/sauberer-code-ein-handbuch-der-agilen-handwerkskunst\/"},"modified":"2024-10-31T17:46:28","modified_gmt":"2024-10-31T17:46:28","slug":"sauberer-code-ein-handbuch-der-agilen-handwerkskunst","status":"publish","type":"post","link":"https:\/\/devologyx.io\/de\/sauberer-code-ein-handbuch-der-agilen-handwerkskunst\/","title":{"rendered":"SAUBERER CODE – EIN HANDBUCH DER AGILEN HANDWERKSKUNST"},"content":{"rendered":"\n
\"\"<\/figure>\n\n

Schlechter Code kann funktionieren. Aber wenn der Code nicht sauber ist, kann er ein Softwareentwicklungsunternehmen in die Knie zwingen. \u00dcberall auf der Welt gehen hervorragende Ressourcen im Namen von schlecht entworfenem Code verloren. Aber das muss nicht so sein. Im August 2008 stellte der renommierte Softwareexperte Robert C. Martin ein umfassendes Buch mit dem Titel Clean Code vor. Das Buch vermittelt Ihnen die Grundwerte eines Software-Handwerkers und Ans\u00e4tze, um sauberen Code zu entwerfen und Sie zu einem besseren Programmierer zu machen. <\/p>\n\n

WIE DIESES BUCH UNS GEHOLFEN HAT?<\/strong><\/p>\n\n

Dieses Buch hat uns geholfen zu verstehen, dass wir bessere Software-Handwerker werden und sauberen Code schreiben m\u00fcssen, um uns als Profis zu betrachten. Sauberer Code wirft ein Licht auf Unit-Tests, Formatierung, Debugging und die Verwendung von beschreibenden Namen, die uns helfen, saubereren und robusteren Code f\u00fcr unsere Kunden zu schreiben. Das Schreiben von sauberem Code ist eine Frage der pers\u00f6nlichen Gewohnheit und viel mehr eine F\u00e4higkeit. Mit der Zeit m\u00fcssen Sie durch Erfahrung und Wissen wachsen, um sauberen Code zu schreiben. <\/p>\n\n

DAS BUCH ERKL\u00c4RT IN 60 SEKUNDEN<\/strong><\/p>\n\n

Der Autor betont, dass Funktionen klein sein, eine Aufgabe erf\u00fcllen und beschreibende Namen haben sollten. Wenn eine Funktion viele Konfigurationsargumente ben\u00f6tigt, sollten Sie diese in eine einzige Variable f\u00fcr die Konfigurationsoptionen integrieren. <\/p>\n\n

Das Buch betont, dass sich Entwickler an das Single Responsibility Principle halten sollen, das besagt, dass eine Klasse oder ein Modul nur einen Grund f\u00fcr eine \u00c4nderung haben muss. Dieses Prinzip gab uns eine Definition von Verantwortung und Richtlinien f\u00fcr die Klassengr\u00f6\u00dfe. Klassen m\u00fcssen eine Verantwortung und einen Grund f\u00fcr eine \u00c4nderung haben. <\/p>\n\n

DIE DREI BESTEN ZITATE<\/strong><\/p>\n\n

„Code ohne Tests ist nicht sauber. Egal wie elegant er ist, wie lesbar und zug\u00e4nglich, er ist unsauber, wenn er keine Tests hat.“<\/p>\n\n

„Jedes System basiert auf einer dom\u00e4nenspezifischen Sprache, die von den Programmierern entwickelt wurde, um dieses System zu beschreiben. Funktionen sind die Verben dieser Sprache, und Klassen sind die Substantive.“<\/p>\n\n

„Fehlerbehandlung ist wichtig, aber wenn sie die Logik verdunkelt, ist sie falsch.“<\/p>\n\n

\"\"<\/figure>\n\n

BUCHZUSAMMENFASSUNGEN UND NOTIZEN<\/strong><\/p>\n\n

Kapitel eins: Sauberer Code<\/strong><\/p>\n\n

Sauberer Code ist wichtig: Falscher Code bringt ein Unternehmen irgendwann zu Fall, denn mit zunehmender Entwicklung geht die Produktivit\u00e4t immer mehr gegen Null.<\/p>\n\n

Die Gesamtkosten f\u00fcr ein Chaos steigen mit der Zeit. Je unordentlicher der Code wird, desto geringer sind die Chancen, ihn zu bereinigen. Die Produktivit\u00e4t des Teams sinkt, je gr\u00f6\u00dfer das Chaos wird, weil es unter Druck steht, eine Frist einzuhalten oder die Produktivit\u00e4t zu steigern. <\/p>\n\n

Es kostet Zeit und Ressourcen, ein System von Grund auf neu zu erstellen. Refactoring und schrittweise Verbesserungen sind in der Regel die bessere Wahl. Ihren Code sauber zu halten ist kosteneffizient und eine Frage des beruflichen \u00dcberlebens. <\/p>\n\n

Sie w\u00fcrden Monate damit verbringen, eine Aufgabe zu erledigen, f\u00fcr die Sie mit unordentlichem Code nur Stunden gebraucht h\u00e4tten. Guter Code verrottet schnell zu falschem Code, weil sich die Anforderungen in Ans\u00e4tzen \u00e4ndern, die das urspr\u00fcngliche Design durchkreuzen. <\/p>\n\n

Sauberer Code ist gut getestet und f\u00fchrt eine Aufgabe effektiv aus, w\u00e4hrend lausiger Code meist fahrl\u00e4ssig zu viel macht.<\/p>\n\n

Unordentliche Codes bremsen Entwickler aus, aber alle f\u00fchlen sich unter Druck gesetzt, ein Chaos zu schaffen, um Termine einzuhalten. In der Regel werden Sie die Frist nicht einhalten, wenn Sie Unordnung machen. Die einzige M\u00f6glichkeit, die Frist einzuhalten, ist die Pflege eines sauberen Codes. <\/p>\n\n

Lieblingszitat des Kapitels: „Sauberen Code zu schreiben, ist das, was Sie tun m\u00fcssen, um sich als Profi zu bezeichnen. Es gibt keine vern\u00fcnftige Entschuldigung daf\u00fcr, dass Sie weniger als Ihr Bestes geben.“<\/em><\/strong><\/p>\n\n

Kapitel zwei: Bedeutungsvolle Namen<\/strong><\/p>\n\n

Es ist m\u00fc\u00dfig zu kommentieren, dass Namen ihren Zweck offenbaren sollten. Die Auswahl guter Namen kostet Zeit, spart aber mehr als sie kostet. Achten Sie auf die von Ihnen gew\u00e4hlten Namen und \u00e4ndern Sie sie, wenn Sie bessere finden. <\/p>\n\n

Die Wahl eines guten Namens ist komplex, und der Name einer Funktion oder Variable sollte erkl\u00e4ren, was sie ist, wie sie verwendet wird und warum sie existiert. Wenn ein Name einen Kommentar erfordert, verr\u00e4t er nicht seine Absicht. <\/p>\n\n

Sie m\u00fcssen vermeiden, falsche Hinweise zu hinterlassen, die die Bedeutung des Codes verschleiern. Vermeiden Sie W\u00f6rter, deren etablierte Bedeutungen von der von Ihnen beabsichtigten Bedeutung abweichen. <\/p>\n\n

Vermeiden Sie die Verwendung von Abk\u00fcrzungen in Funktionsnamen und einstelligen Variablennamen, au\u00dfer bei h\u00e4ufig verwendeten Namen wie „i“ f\u00fcr die Z\u00e4hlervariable in einer Schleife.<\/p>\n\n

Variablen sollten aussprechbar sein, damit Sie \u00fcber sie sprechen und sie laut aussprechen k\u00f6nnen. Sie k\u00f6nnen sie nur mit Ihren Teamkollegen besprechen, wenn Sie sie aussprechen k\u00f6nnen. <\/p>\n\n

Einbuchstabige Namen und numerische Konstanten haben ein besonderes Problem. Es ist m\u00fchsam, sie in einem Textk\u00f6rper zu finden. Namen mit nur einem Buchstaben k\u00f6nnen nur als lokale Variablen innerhalb kurzer Methoden verwendet werden. <\/p>\n\n

Lieblingszitat des Kapitels: „Ein langer beschreibender Name ist besser als ein langer beschreibender Kommentar.“<\/em><\/strong><\/p>\n\n

Kapitel drei: Funktionen<\/strong><\/p>\n\n

Die erste Regel f\u00fcr Funktionen lautet: Sie m\u00fcssen unbedeutend sein, und die zweite Regel lautet: Sie sollten nur eine Aufgabe ausf\u00fchren. Funktionen sollten so unbedeutend sein, dass sie verschachtelte Strukturen enthalten. Daher darf die Einr\u00fcckungsebene einer Funktion nicht gr\u00f6\u00dfer als eins oder zwei sein. Das macht die Funktionen leichter lesbar und verst\u00e4ndlich. <\/p>\n\n

Funktionen sollten so wenige Parameter wie m\u00f6glich haben. Parameter neigen dazu, Funktionen schwer verst\u00e4ndlich zu machen und befinden sich auf einer niedrigeren Abstraktionsebene. Vermeiden Sie die Verwendung von Parametern so gut es geht, indem Sie abstrakte Hilfsklassen einf\u00fchren oder Argumente in Mitgliedsvariablen umwandeln. <\/p>\n\n

Um sicherzustellen, dass Ihre Funktionen eine Aufgabe erf\u00fcllen, m\u00fcssen Sie daf\u00fcr sorgen, dass die Anweisungen innerhalb Ihrer Funktionen alle auf der gleichen Abstraktionsebene liegen.<\/p>\n\n

Verwenden Sie aussagekr\u00e4ftige Namen zur Kennzeichnung Ihrer Funktionen. Beschreibende Namen erkl\u00e4ren, was eine Funktion tut. Je kleiner und konzentrierter eine Funktion ist, desto einfacher ist es, einen beschreibenden Namen zu w\u00e4hlen. <\/p>\n\n

Lieblingszitat des Kapitels: „Sie wissen, dass Sie an sauberem Code arbeiten, wenn sich jede Routine als so ziemlich das herausstellt, was Sie erwartet haben.“<\/em><\/strong><\/p>\n\n

Viertes Kapitel: Kommentare<\/strong><\/p>\n\n

\"\"<\/figure>\n\n

Die tats\u00e4chliche Verwendung von Kommentaren entsch\u00e4digt Sie f\u00fcr Ihr Versagen, sich in Code auszudr\u00fccken. Kommentare sind durchweg Fehlschl\u00e4ge. Sie sollten sie haben, weil Sie nur manchmal herausfinden, wie Sie sich ohne sie beschreiben k\u00f6nnen. <\/p>\n\n

Sauberer und aussagekr\u00e4ftiger Code mit wenigen Kommentaren ist viel besser als unordentlicher und komplexer Code mit vielen Kommentaren. Verbringen Sie daher lieber Zeit damit, das Chaos in Ihrem Code zu beseitigen, als Kommentare zu schreiben, die Ihr Chaos erkl\u00e4ren. <\/p>\n\n

Die meisten Kommentare sind Kr\u00fccken und Rechtfertigungen f\u00fcr schlechten Code. Kommentare lassen sich vermeiden, wenn Sie eindeutig benannte Variablen verwenden und Codeabschnitte in klar benannte Funktionen einteilen. <\/p>\n\n

Verwenden Sie Javadocs nicht einfach nur, um sie zu verwenden. Kommentare, die erkl\u00e4ren, was eine Methode tut, welche Argumente sie annimmt und was sie zur\u00fcckgibt, sind im besten Fall \u00fcberfl\u00fcssig und im schlimmsten Fall irref\u00fchrend. <\/p>\n\n

Kommentare m\u00fcssen alle zutreffenden Informationen und den Kontext enthalten, den jemand, der die Kommentare liest, ben\u00f6tigt. Seien Sie nicht faul, wenn Sie Kommentare schreiben. <\/p>\n\n

Lieblingszitat des Kapitels: „Kommentieren Sie keinen schlechten Code – schreiben Sie ihn um.“<\/em><\/strong><\/p>\n\n

Kapitel F\u00fcnf: Formatieren<\/strong><\/p>\n\n

Sorgen Sie daf\u00fcr, dass Ihr Code ansprechend formatiert ist. W\u00e4hlen Sie eine bestimmte Anzahl von \u00fcberschaubaren Regeln, die das Format Ihres Codes steuern. Setzen Sie diese Regeln dann konsequent in Ihrem Code um. Noch besser ist es, wenn Sie ein Tool haben, das diese Formatierungsregeln umsetzt. <\/p>\n\n

Die Formatierung von Code ist unerl\u00e4sslich. Sie ist zu wichtig, um ignoriert zu werden. Verlassen Sie sich nicht darauf, dass Menschen jeden Formatierungsfehler manuell erkennen und korrigieren. Verwenden Sie stattdessen einen automatischen Code-Formatierer und Code-Linter. Das ist effizient und produktiv und spart Zeit bei der \u00dcberpr\u00fcfung des Codes. <\/p>\n\n

Quelldateien sollten wie ein Zeitungsartikel sein. Der Name muss einfach, aber aussagekr\u00e4ftig sein. Der Name sollte ausreichen, um zu erkennen, ob Sie sich in einem geeigneten Modul befinden. Die obersten Teile Ihrer Quelldatei sollten Konzepte und Algorithmen auf hoher Ebene enthalten. Dann sollten die Details nach unten hin zunehmen. <\/p>\n\n

Variablen m\u00fcssen in der N\u00e4he der Stelle deklariert werden, an der sie verwendet werden. Bei kleinen Funktionen steht dies normalerweise am Anfang der Funktion. Selbst bei kurzen Funktionen sollten Sie sie gut formatieren, anstatt sie in einer einzigen Zeile zu schreiben. <\/p>\n\n

Lieblingszitat des Kapitels: „Die Formatierung von Codes ist wichtig. Sie ist zu wichtig, um sie zu ignorieren, und sie ist zu wichtig, um sie religi\u00f6s zu behandeln. Bei der Codeformatierung geht es um Kommunikation, und Kommunikation ist die erste Aufgabe eines professionellen Entwicklers.“<\/em><\/strong><\/p>\n\n

Kapitel sechs: Objekte und Datenstrukturen<\/strong><\/p>\n\n

Sie halten Ihre Variablen privat, weil Sie nicht wollen, dass jemand anderes von ihnen abh\u00e4ngt. Sie m\u00f6chten die Freiheit behalten, ihren Typ oder ihre Implementierung spontan zu \u00e4ndern. Viele Entwickler f\u00fcgen automatisch Getter und Setter zu ihren Objekten hinzu und geben damit ihre privaten Variablen preis, als w\u00e4ren sie \u00f6ffentlich. <\/p>\n\n

F\u00fcgen Sie nicht standardm\u00e4\u00dfig Getter und Setter hinzu, sondern bieten Sie eine abstrakte Schnittstelle zu den Daten an, so dass Sie die Implementierung anpassen k\u00f6nnen, ohne an die Clients denken zu m\u00fcssen.<\/p>\n\n

Objekte verbergen ihre Daten hinter Abstraktionen und offenbaren Funktionen, die mit diesen Daten arbeiten, au\u00dfer Sichtweite. Datenstrukturen legen ihre Daten offen und haben keine sinnvollen Funktionen. <\/p>\n\n

Das Gesetz von Demeter besagt, dass ein Modul nichts \u00fcber das Innere des Objekts wissen sollte, das es manipuliert. Das bedeutet, dass ein Objekt seine interne Struktur nicht durch Accessoren offenbaren sollte, denn das w\u00fcrde bedeuten, dass es seine interne Struktur preisgibt, anstatt sie zu verbergen. Da Objekte Daten verbergen und ihr Verhalten offenlegen, ist es m\u00fchelos m\u00f6glich, neue Objekte hinzuzuf\u00fcgen, ohne das aktuelle Verhalten zu \u00e4ndern. Datenstrukturen legen Daten offen und haben kein ungew\u00f6hnliches Verhalten, so dass das Hinzuf\u00fcgen neuer Verhaltensweisen zu den vorhandenen Datenstrukturen einfach ist. <\/p>\n\n

Lieblingszitat des Kapitels: „In jedem System werden wir manchmal die Flexibilit\u00e4t haben wollen, neue Datentypen hinzuzuf\u00fcgen, also bevorzugen wir Objekte f\u00fcr diesen Teil des Systems. Ein anderes Mal m\u00f6chten wir die Flexibilit\u00e4t haben, neue Verhaltensweisen hinzuzuf\u00fcgen. Daher bevorzugen wir f\u00fcr diesen Teil des Systems Datentypen und Prozeduren.“<\/em><\/strong><\/p>\n\n

Kapitel sieben: Fehlerbehandlung<\/strong><\/p>\n\n

Die Behandlung von Fehlern ist unerl\u00e4sslich, und davon gibt es bei der Programmierung in der Regel viel. Dennoch sollte sie nicht die eigentliche Absicht des Codes verbergen. Verwenden Sie daher eher Erwartungen als R\u00fcckgabewerte. <\/p>\n\n

Die Ausnahmen sollten informativ sein und objektive, kontextbezogene und detaillierte Angaben zum Fehlertyp enthalten, damit jemand, der die Fehlermeldung erh\u00e4lt, eine effektive Fehlersuche durchf\u00fchren kann.<\/p>\n\n

Ausnahmen definieren den Anwendungsbereich Ihres Programms. Wenn Sie Code in den try-Teil einer try-catch-finally-Anweisung implementieren, dr\u00fccken Sie damit aus, dass die Ausf\u00fchrung an jedem beliebigen Punkt abgebrochen und an der catch-Anweisung neu gestartet werden kann. <\/p>\n\n

Wenn Sie die APIs von Drittanbietern in eine d\u00fcnne Abstraktionsschicht verpacken, wird es einfacher, eine Bibliothek in Zukunft gegen eine andere auszutauschen und die Bibliothek w\u00e4hrend des Testens zu simulieren.<\/p>\n\n

Lieblingszitat des Kapitels: „Sauberer Code ist lesbar, aber er muss auch robust sein. Dies sind keine widerspr\u00fcchlichen Ziele. Wir k\u00f6nnen robusten, sauberen Code schreiben, wenn wir die Fehlerbehandlung als ein besonderes Anliegen betrachten.“<\/em><\/strong><\/p>\n\n

Kapitel acht: Grenzen<\/strong><\/p>\n\n

\"\"<\/figure>\n\n

Der Code von Drittanbietern hilft Ihnen dabei, mehr Funktionalit\u00e4t in k\u00fcrzerer Zeit zu liefern. Es ist nicht Ihre Aufgabe, den Code von Drittanbietern zu testen, aber es sollte Ihr Interesse sein, Tests f\u00fcr den von Ihnen verwendeten Code von Drittanbietern zu schreiben. <\/p>\n\n

Lerntests sind pr\u00e4zise Experimente, die Ihnen helfen, Ihr Verst\u00e4ndnis zu verbessern. Lerntests best\u00e4tigen, dass die von Ihnen verwendeten Drittanbieterpakete so funktionieren, wie Sie es erwarten. Es gibt keine Garantie daf\u00fcr, dass der Code von Drittanbietern in Kombination mit Ihren Anforderungen kompatibel bleibt. <\/p>\n\n

Gute Software l\u00e4sst sich ohne gro\u00dfe Investitionen und Nacharbeit \u00e4ndern. Wenn Sie Code verwenden, der sich Ihrer Kontrolle entzieht, m\u00fcssen Sie besonders vorsichtig sein, um Ihre Investitionen zu sch\u00fctzen und sicherzustellen, dass k\u00fcnftige \u00c4nderungen \u00fcberschaubar sind. <\/p>\n\n

Grenzen von Drittanbietern werden durch einige Stellen im Code verwaltet, die auf sie verweisen.<\/p>\n\n

Vermeiden Sie es, dass zu viel von Ihrem Code \u00fcber die Details von Drittanbietern erf\u00e4hrt. Es ist besser, sich auf etwas zu verlassen, das Sie kontrollieren k\u00f6nnen, als auf etwas, das Sie nicht kontrollieren k\u00f6nnen. <\/p>\n\n

Lieblingszitat des Kapitels: „Wir sollten es vermeiden, zu viel von unserem Code \u00fcber Einzelheiten von Dritten wissen zu lassen. Es ist besser, sich auf etwas zu verlassen, das Sie kontrollieren, als auf etwas, das Sie nicht kontrollieren, damit es nicht Sie kontrolliert.“<\/em><\/strong><\/p>\n\n

Kapitel neun: Einheitstests<\/strong><\/p>\n\n

Bei der testgesteuerten Entwicklung m\u00fcssen Sie Unit-Tests schreiben, bevor Sie Produktionscode schreiben. Sie k\u00f6nnen keinen produktiven Code schreiben, bevor Sie nicht einen fehlgeschlagenen Unit-Test geschrieben haben. Der Testcode muss genauso sauber sein wie der Produktionscode, mit wenigen Ausnahmen, die in der Regel den Speicher oder die Effizienz betreffen. <\/p>\n\n

Achten Sie darauf, Ihre Tests sauber zu halten, sonst verlieren Sie sie. Und wenn sie fehlen, verlieren Sie das Einzige, was Ihren Code wiederverwendbar, flexibel und wartbar macht. Sie werden keine Angst haben, Code\u00e4nderungen vorzunehmen, wenn Tests vorhanden sind, aber ohne sie ist jede \u00c4nderung ein m\u00f6glicher Fehler. <\/p>\n\n

Die Lesbarkeit ist das, was einen Test sauber macht. Die Lesbarkeit ist bei Unit-Tests vielleicht sogar noch wichtiger als bei Produktionscode. Klarheit, Einfachheit und Dichte des Ausdrucks machen Tests lesbar. In einem Test m\u00fcssen Sie mit so wenigen Ausdr\u00fccken wie m\u00f6glich viel sagen. <\/p>\n\n

Normalerweise m\u00f6chten Sie in jeder Testfunktion ein einziges Konzept testen. Sie m\u00f6chten keine ausgedehnten Testfunktionen, die eine Sache nach der anderen testen. <\/p>\n\n

Genau wie der Produktionscode sind auch die Tests f\u00fcr die Robustheit des Projekts entscheidend. Tests sind notwendig, weil sie die Wiederverwendbarkeit, Wartbarkeit und Flexibilit\u00e4t des Codes verbessern und erhalten. Halten Sie Ihre Tests sauber und sorgen Sie daf\u00fcr, dass sie aussagekr\u00e4ftig und kurz sind. Entwickeln Sie APIs, die als dom\u00e4nenspezifische Sprache fungieren, die Sie beim Schreiben von Tests unterst\u00fctzt. <\/p>\n\n

Lieblingszitat des Kapitels: „Tests m\u00fcssen zeitnah geschrieben werden. Unit-Tests sollten kurz vor dem Produktionscode geschrieben werden, der sie erfolgreich macht.“<\/em><\/strong><\/p>\n\n

Kapitel 10: Klassen<\/strong><\/p>\n\n

Klassen m\u00fcssen mit einer Liste von Variablen beginnen. \u00d6ffentliche statische Konstanten sollten an erster Stelle stehen, dann private statische Variablen, gefolgt von privaten Instanzvariablen. Setzen Sie die privaten Hilfsprogramme, die von einer \u00f6ffentlichen Funktion aufgerufen werden, direkt dahinter. <\/p>\n\n

Die erste Regel f\u00fcr Klassen ist, dass sie klein sein m\u00fcssen. Genau wie bei Funktionen ist die wichtigste Regel f\u00fcr die Erstellung von Klassen, dass sie klein sein m\u00fcssen. Aber die eigentliche Frage ist immer: „Wie klein?“. Bei Funktionen berechnen Sie die Gr\u00f6\u00dfe durch das Z\u00e4hlen der physischen Zeilen. Bei Klassen messen Sie die Gr\u00f6\u00dfe durch das Z\u00e4hlen von Verantwortlichkeiten. <\/p>\n\n

Klassen m\u00fcssen eine kleine Anzahl von Instanzvariablen haben. Jede Methode einer Klasse sollte eine oder mehrere dieser Variablen kontrollieren. Je mehr Variablen eine Methode beeinflusst, desto st\u00e4rker ist sie mit ihrer Klasse verbunden. <\/p>\n\n

Verwenden Sie in Ihrer Anwendung lieber viele kleine Klassen als ein paar gro\u00dfe Klassen. Dies minimiert die Menge an Informationen, die ein anderer Entwickler bei der Arbeit an einer bestimmten Aufgabe verstehen muss. <\/p>\n\n

Lieblingszitat des Kapitels: „Eine Klasse oder ein Modul sollte einen, und nur einen, Grund haben, sich zu \u00e4ndern.“<\/em><\/strong><\/p>\n\n

WIE DIESES BUCH SOFTWAREENTWICKLERN HELFEN KANN?<\/strong><\/p>\n\n

„Clean Code“ von Robert C. Martin kann Softwareentwicklern helfen, die Qualit\u00e4t ihres Codes zu verbessern. Es bietet praktische Ratschl\u00e4ge und Richtlinien, wie man lesbaren, wartbaren und effizienten Code schreibt. Das Buch behandelt Themen wie Benennung, Kommentierung, Formatierung und Testen und betont die Bedeutung von Einfachheit, Klarheit und Konsistenz bei der Codierung. Durch die Befolgung der in diesem Buch dargelegten Prinzipien k\u00f6nnen Entwickler technische Schulden reduzieren, die Produktivit\u00e4t steigern und Software erstellen, die leichter zu verstehen, zu \u00e4ndern und zu erweitern ist. Es bietet Softwareentwicklern einen umfassenden Ansatz f\u00fcr die Programmierung, mit dem sie ihre F\u00e4higkeiten verbessern und die Kosten f\u00fcr die Wartung senken k\u00f6nnen. Dieses Buch hilft Programmierern, Code zu schreiben, der in Zukunft leicht zu \u00e4ndern und zu refaktorisieren ist. Es ist eine Pflichtlekt\u00fcre f\u00fcr jeden Softwareentwickler, der ein besserer Programmierer werden will. <\/p>\n","protected":false},"excerpt":{"rendered":"

Schlechter Code kann funktionieren. Aber wenn der Code nicht sauber ist, kann er ein Softwareentwicklungsunternehmen in die Knie zwingen. \u00dcberall auf der Welt gehen hervorragende Ressourcen im Namen von schlecht entworfenem Code verloren. Aber das muss nicht so sein. Im August 2008 stellte der renommierte Softwareexperte Robert C. Martin ein umfassendes Buch mit dem Titel […]<\/p>\n","protected":false},"author":1,"featured_media":17641,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[83],"tags":[],"writer":[],"class_list":["post-19696","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-buchclub"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19696","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/comments?post=19696"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19696\/revisions"}],"predecessor-version":[{"id":19699,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19696\/revisions\/19699"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media\/17641"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media?parent=19696"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/categories?post=19696"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/tags?post=19696"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/writer?post=19696"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}