{"id":19683,"date":"2023-07-18T14:17:26","date_gmt":"2023-07-18T14:17:26","guid":{"rendered":"https:\/\/devologyx.io\/der-pragmatische-programmierer\/"},"modified":"2024-10-31T17:44:26","modified_gmt":"2024-10-31T17:44:26","slug":"der-pragmatische-programmierer","status":"publish","type":"post","link":"https:\/\/devologyx.io\/de\/der-pragmatische-programmierer\/","title":{"rendered":"DER PRAGMATISCHE PROGRAMMIERER"},"content":{"rendered":"\n
\"\"<\/figure>\n\n

The Pragmatic Programmer ist ein geschickter und praktischer Leitfaden, der Ihnen Einblicke und Grundlagen vermittelt, um ein guter Programmierer zu sein, und der Ihre Spezialisierung und die technischen Aspekte der modernen Softwareentwicklung erweitert. Das Buch wurde im Oktober 1999 ver\u00f6ffentlicht. Andrew Hunt behandelt Themen wie pers\u00f6nliche Verantwortung und Karriereentwicklung bis hin zu architektonischen Techniken, mit denen Sie Ihren Code flexibel halten und leicht anpassen und wiederverwenden k\u00f6nnen. In dem Buch lernen Sie, wie Sie Softwaref\u00e4ulnis bek\u00e4mpfen, die Falle der Wissensverdoppelung vermeiden und Ihre Entwicklungen durch Automatisierung pr\u00e4ziser gestalten k\u00f6nnen. <\/p>\n\n

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

Dieses Buch hat uns geholfen zu verstehen, wie Entwickler bessere Programmierer werden k\u00f6nnen, indem sie die wichtigsten Grundlagen verstehen, die f\u00fcr den Erfolg der Softwareentwicklung erforderlich sind. Es zeigt, dass es bei einem guten Programmierer nicht nur um technische F\u00e4higkeiten geht. Es konzentriert sich auf praktische Themen wie Entkopplung, Power Editing, Debugging und Testen, die uns helfen, Entwicklern dabei zu helfen, besseren Code f\u00fcr unsere Kunden zu erstellen und Berater und Mitglieder gro\u00dfer Projektteams zu werden. Das Buch hat uns geholfen zu verstehen, wie wir unsere Erfahrungen nutzen k\u00f6nnen, um sowohl in unserem beruflichen als auch in unserem privaten Leben fundiertere Entscheidungen zu treffen. <\/p>\n\n

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

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

Das Buch verwendet Analogien und kurze Geschichten, um Entwicklungsmethoden und Warnungen vorzustellen, z.B. die Broken-Windows-Theorie, die Geschichte von der Steinsuppe oder dem kochenden Frosch. Au\u00dferdem enth\u00e4lt es kleine \u00dcbungen, mit denen Sie Ihre Programmierkenntnisse trainieren k\u00f6nnen. <\/p>\n\n

Der pragmatische Programmierer erkl\u00e4rt, dass sich Softwarefehler auf verschiedene Weise manifestieren, von missverstandenen Anforderungen bis hin zu Programmierfehlern. Leider sind moderne Computersysteme immer noch darauf beschr\u00e4nkt, das zu tun, was Sie ihnen sagen, und nicht das, was Sie von ihnen wollen. <\/p>\n\n

Dem Buch zufolge schreibt niemand perfekte Software. Es ist also klar, dass die Fehlersuche einen gro\u00dfen Teil Ihres Tages in Anspruch nehmen wird. Die Fehlersuche ist f\u00fcr viele Entwickler ein sensibles, emotionales Thema. <\/p>\n\n

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

„Werkzeuge verst\u00e4rken Ihr Talent. Je besser Ihre Werkzeuge sind und je besser Sie sie zu nutzen wissen, desto produktiver k\u00f6nnen Sie sein.“<\/em><\/p>\n\n

„Die gr\u00f6\u00dfte aller Schw\u00e4chen ist die Angst, schwach zu erscheinen“.<\/em><\/p>\n\n

„Der Editor wird zu einer Verl\u00e4ngerung Ihrer Hand; die Tasten singen, w\u00e4hrend sie sich durch Text und Gedanken schneiden.<\/em><\/p>\n\n

BUCHZUSAMMENFASSUNG UND ANMERKUNGEN<\/strong><\/p>\n\n

Kapitel Eins: Eine pragmatische Philosophie<\/strong><\/p>\n\n

    \n
  1. Die Katze hat meinen Quellcode gefressen<\/strong><\/li>\n<\/ol>\n\n

    \u00dcbernehmen Sie Verantwortung: <\/strong>Verantwortung ist etwas, dem Sie aktiv zustimmen; Sie setzen sich daf\u00fcr ein, dass etwas richtig ausgef\u00fchrt wird. Allerdings haben Sie nicht unbedingt die direkte Kontrolle \u00fcber jeden Aspekt. Sie haben das Recht, die Verantwortung f\u00fcr eine unvorstellbare oder mit hohen Risiken behaftete Situation nicht zu \u00fcbernehmen. Wenn Sie die Verantwortung f\u00fcr eine Situation \u00fcbernehmen, sollten Sie die Demut haben, daf\u00fcr zur Rechenschaft gezogen zu werden. Jeder macht Fehler. Wenn Sie also einen Fehler machen, geben Sie ihn ehrlich zu und versuchen Sie, Alternativen zu finden. <\/p>\n\n

      \n
    1. Software-Entropie<\/strong><\/li>\n<\/ol>\n\n

      Ein zerbrochenes Fenster, das \u00fcber einen l\u00e4ngeren Zeitraum nicht repariert wurde, vermittelt den Bewohnern des Hauses das Gef\u00fchl, dass sie sich selbst \u00fcberlassen sind, was schlie\u00dflich zu weiteren Sch\u00e4den und Ruinen f\u00fchrt. Das Gleiche gilt f\u00fcr Software. Ein mieser Code kann zu noch mehr Schaden f\u00fchren, wenn er nicht bald repariert wird. Leben Sie daher nicht mit destruktivem Code. Reparieren Sie ihn, sobald ein Fehler entdeckt wird. Ergreifen Sie Ma\u00dfnahmen und zeigen Sie Initiative, um weiteren Schaden zu verhindern und um zu zeigen, dass Sie die Situation im Griff haben. <\/p>\n\n

        \n
      1. Ausreichend gute Software<\/strong><\/li>\n<\/ol>\n\n

        Gut genug bedeutet nicht, dass der Code schlampig oder schlecht produziert ist. Alle Systeme m\u00fcssen die Anforderungen ihrer Benutzer erf\u00fcllen, um erfolgreich zu sein. Sie k\u00f6nnen sich selbst dazu verpflichten, Software zu schreiben, die gut genug ist – f\u00fcr Ihre Benutzer, f\u00fcr k\u00fcnftige Betreuer und f\u00fcr Ihren Seelenfrieden. Wenn Sie Software schreiben, die gut genug ist, werden Sie produktiver und Ihre Benutzer zufriedener. Die Erstellung von ausreichend gutem Code setzt einfach voraus, dass die Benutzer mitentscheiden k\u00f6nnen, ob das, was Sie produziert haben, gut genug ist. <\/p>\n\n

        Wenn Sie einen ausreichend guten Code entwickeln, sollten Sie wissen, wann Sie aufh\u00f6ren m\u00fcssen. Ruinieren Sie ein hervorragendes Programm nicht durch \u00fcberm\u00e4\u00dfige Ausschm\u00fcckung und Verfeinerung. Machen Sie weiter und lassen Sie Ihren Code eine Zeit lang f\u00fcr sich stehen. Er mag nicht perfekt sein. Machen Sie sich keine Sorgen: Er k\u00f6nnte nie perfekt sein. Gute Software jetzt ist besser als ideale Software in einem Jahr. <\/p>\n\n

        \n Mein Lieblingszitat aus dem Kapitel: „<\/em>\n<\/strong>\n Tolle Software heute ist oft besser als perfekte Software morgen.“<\/em>\n<\/strong><\/p>\n\n

        Kapitel Zwei: Ein pragmatischer Ansatz<\/strong><\/p>\n\n

          \n
        1. Das \u00dcbel der Duplikation<\/strong><\/li>\n<\/ol>\n\n

          Als Programmierer sammeln, organisieren, pflegen und nutzen Sie Wissen. Ungl\u00fccklicherweise ist das Lernen nicht konstant oder fest und \u00e4ndert sich schnell. Ihr Verst\u00e4ndnis einer Anforderung kann sich nach einem Treffen mit dem Kunden \u00e4ndern. Das bedeutet, dass Sie den gr\u00f6\u00dften Teil Ihrer Zeit damit verbringen, den Code t\u00e4glich zu pflegen. Die meisten Leute denken, dass die Wartung mit dem Start einer Anwendung beginnt, dass Wartung bedeutet, Fehler zu beheben und Funktionen zu verbessern. Diese Leute irren sich. Die Wartung ist keine separate Aktivit\u00e4t, sondern ein Teil des Entwicklungsprozesses, denn neue Anforderungen kommen hinzu, w\u00e4hrend Sie den Code entwerfen. <\/p>\n\n

          Die einzige M\u00f6glichkeit, Software zuverl\u00e4ssig zu entwickeln und Ihre Entwicklungen leichter verst\u00e4ndlich und wartbar zu machen, besteht darin, dem DRY-Prinzip (Don’t Repeat Yourself)<\/strong> zu folgen: Jedes Wissen muss in einem System eine einzige, eindeutige und verbindliche Darstellung haben.<\/p>\n\n

          Die meisten der Duplikate, die wir sehen, fallen in eine der folgenden Kategorien: <\/p>\n\n

            \n
          • Aufgezwungene Vervielf\u00e4ltigung. <\/strong>Sie haben das Gef\u00fchl, dass Sie keine andere Wahl haben – die Umwelt scheint eine Replikation zu verlangen.<\/li>\n\n\n\n
          • Unbeabsichtigte Duplikation.<\/strong> Sie sind sich nicht bewusst, dass Sie Informationen duplizieren.<\/li>\n\n\n\n
          • Ungeduldige Vervielf\u00e4ltigung.<\/strong> Man wird faul und dupliziert, weil es einfacher erscheint.<\/li>\n\n\n\n
          • Duplizierung zwischen Entwicklern.<\/strong> Mehrere Personen in einem Team duplizieren eine Information und merken es nicht.<\/li>\n<\/ul>\n\n
              \n
            1. Umkehrbarkeit.<\/strong><\/li>\n<\/ol>\n\n

              Die \u00c4nderungen m\u00fcssen nicht extrem sein oder sogar sofort erfolgen. Aber wenn die Zeit vergeht und Ihr Projekt voranschreitet, kann es sein, dass Sie sich in einer unhaltbaren Lage befinden. Das Projektteam legt sich bei kritischen Entscheidungen auf ein kleineres Ziel fest und schafft so eine Version der Realit\u00e4t mit weniger Optionen. Das Problem ist, dass kritische Entscheidungen nicht leicht r\u00fcckg\u00e4ngig zu machen sind. <\/p>\n\n

              Nichts ist f\u00fcr immer, und wenn Sie sich auf eine Tatsache verlassen, k\u00f6nnen Sie fast sicher sein, dass sie sich \u00e4ndern wird. Planen Sie die Umkehrbarkeit ein, denn keine Entscheidung ist endg\u00fcltig. Streben Sie nach flexiblem Code, Architektur und Anbieterintegration. <\/p>\n\n

              Wenn Sie sich an Empfehlungen wie das DRY-Prinzip, die Entkopplung und die Verwendung von Metadaten halten, m\u00fcssen Sie nicht viele kritische und unumkehrbare Entscheidungen treffen.<\/p>\n\n

                \n
              1. Leuchtspurgeschosse<\/strong><\/li>\n<\/ol>\n\n

                Tracer-Bullets helfen Ihnen, Ihr Ziel unter realen Bedingungen schnell zu finden und geben Ihnen und Ihren Benutzern Feedback. Ein Tracer-Code k\u00f6nnte eine einzelne Funktion sein, die durchg\u00e4ngig auf allen Ebenen implementiert ist. Ein Tracer-Code f\u00fchrt schnell zum Ziel und liefert sofortiges Feedback. Und vom praktischen Standpunkt aus betrachtet, sind sie eine relativ billige L\u00f6sung. Um denselben Effekt im Code zu erzielen, suchen wir nach etwas, das uns schnell, sichtbar und wiederholt von einer Anforderung zu einem Aspekt des endg\u00fcltigen Systems bringt. <\/p>\n\n

                Vorteile<\/strong><\/p>\n\n

                  \n
                • Sie haben eine Integrationsplattform.<\/li>\n\n\n\n
                • Sie haben ein besseres Gef\u00fchl f\u00fcr den Fortschritt.<\/li>\n\n\n\n
                • Die Benutzer k\u00f6nnen fr\u00fchzeitig sehen, dass etwas funktioniert.<\/li>\n\n\n\n
                • Helfen Sie beim Aufbau einer Struktur, in der Sie arbeiten k\u00f6nnen.<\/li>\n<\/ul>\n\n

                  Tracer Code versus Prototyping<\/strong><\/p>\n\n

                  Sie k\u00f6nnten denken, dass das Konzept des Tracer Codes nichts anderes als Prototyping ist; es gibt einen Unterschied. Beim Prototyping geht es darum, bestimmte Aspekte des endg\u00fcltigen Systems zu erforschen. Bei einem echten Prototyp werfen Sie alles weg, was Sie beim Ausprobieren des Konzepts zusammengezimmert haben, und programmieren es anhand der gewonnenen Erkenntnisse neu. Der Tracer-Code-Ansatz befasst sich mit einem anderen Problem. Sie m\u00fcssen wissen, wie die Anwendung als Ganzes zusammenh\u00e4ngt. Sie wollen Ihren Benutzern zeigen, wie die Interaktionen in der Praxis funktionieren und Ihren Entwicklern ein architektonisches Ger\u00fcst an die Hand geben, an dem sie den Code aufh\u00e4ngen k\u00f6nnen. <\/p>\n\n

                  Lieblingszitat des Kapitels: „Nichts ist gef\u00e4hrlicher als eine Idee, wenn es die einzige ist, die man hat.“ <\/em><\/strong><\/p>\n\n

                  Kapitel 3: Die grundlegenden Werkzeuge<\/strong><\/p>\n\n

                  \"\"<\/figure>\n\n
                    \n
                  1. Die Macht des einfachen Textes<\/strong><\/li>\n<\/ol>\n\n

                    Als Pragmatischer Programmierer ist Ihr Basismaterial Wissen. Sie sammeln Anforderungen wie Wissen und dr\u00fccken es dann in Ihren Entw\u00fcrfen, Implementierungen, Tests und Dokumenten aus. Das beste Format f\u00fcr die Speicherung von Wissen ist einfacher Text. <\/p>\n\n

                    Was ist Klartext?<\/p>\n\n

                    Der einfache Text besteht aus druckbaren Zeichen, so dass Menschen ihn direkt lesen und verstehen k\u00f6nnen. Mit einfachem Text geben Sie sich die M\u00f6glichkeit, Wissen sowohl manuell als auch programmgesteuert mit praktisch jedem Ihnen zur Verf\u00fcgung stehenden Werkzeug zu manipulieren. <\/p>\n\n

                      \n
                    1. Muschelspiele<\/strong><\/li>\n<\/ol>\n\n

                      Jeder Holzarbeiter braucht eine geeignete, solide und zuverl\u00e4ssige Werkbank, auf der er seine Werkst\u00fccke in bequemer H\u00f6he aufbewahren kann, w\u00e4hrend er sie bearbeitet. <\/p>\n\n

                      Als Programmierer, der mit Textdateien arbeitet, ist Ihre Werkbank die Befehlsshell. \u00dcber die Shell-Eingabeaufforderung k\u00f6nnen Sie Ihr gesamtes Repertoire an Tools aufrufen. Mit der Shell-Eingabeaufforderung k\u00f6nnen Sie Anwendungen, Debugger, Browser, Editoren und Dienstprogramme starten. Sie k\u00f6nnen nach Dateien suchen, den Status des Systems abfragen und Ausgaben filtern. Durch die Programmierung der Shell k\u00f6nnen Sie Multiplex-Makrobefehle f\u00fcr Aktivit\u00e4ten erstellen, die Sie h\u00e4ufig ausf\u00fchren. <\/p>\n\n

                      Shell-Dienstprogramme und Windows-Systeme<\/strong><\/p>\n\n

                      Obwohl sich die von Windows-Systemen bereitgestellten Befehlsshells allm\u00e4hlich verbessern, sind die Windows-Befehlszeilen-Dienstprogramme ihren Linux\/Unix-Pendants immer noch unterlegen. Es ist jedoch noch nicht alles verloren. <\/p>\n\n

                      Cygnus Solutions bietet ein Paket namens Cygwin an. Cygwin bietet nicht nur eine Linux\/Unix-Kompatibilit\u00e4tsschicht f\u00fcr Windows, sondern enth\u00e4lt auch eine Sammlung von mehr als 120 Unix-Dienstprogrammen, darunter beliebte Programme wie 1s, grep und find. Die Dienstprogramme und Bibliotheken k\u00f6nnen kostenlos heruntergeladen und verwendet werden, aber lesen Sie die Lizenz. Die Cygwin-Distribution wird mit der Bash-Shell geliefert. <\/p>\n\n

                        \n
                      1. Power Editing<\/strong><\/li>\n<\/ol>\n\n

                        Werkzeuge sind eine Verl\u00e4ngerung Ihrer Hand. Das gilt f\u00fcr Editoren mehr als f\u00fcr jedes andere Softwaretool. W\u00e4hlen Sie einen Editor, mit dem Sie Text so m\u00fchelos wie m\u00f6glich bearbeiten k\u00f6nnen, denn der Text ist das wichtigste Rohmaterial f\u00fcr die Programmierung. <\/p>\n\n

                        Ein Redakteur<\/strong><\/p>\n\n

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

                        Es ist besser, einen Editor sehr gut zu kennen und ihn f\u00fcr alle Bearbeitungsaufgaben zu verwenden: Code, Dokumentation, Memos, Systemverwaltung und so weiter. Bei mehreren Editoren droht Ihnen ein modernes Chaos der Verwirrung. Sie m\u00fcssen vielleicht den integrierten Editor in der IDE jeder Sprache f\u00fcr die Programmierung verwenden, ein All-in-One-Office-Produkt f\u00fcr die Dokumentation und vielleicht einen anderen integrierten Editor f\u00fcr das Versenden von E-Mails. Selbst die Tastenkombinationen, mit denen Sie Befehlszeilen in der Shell bearbeiten, k\u00f6nnen sich unterscheiden. Es ist schwierig, sich in jeder dieser Umgebungen zurechtzufinden, wenn Sie in jeder einen anderen Satz von Bearbeitungskonventionen und Befehlen verwenden. <\/p>\n\n

                        W\u00e4hlen Sie daher einen einzigen Editor, kennen Sie ihn genau und verwenden Sie ihn f\u00fcr alle Bearbeitungsaufgaben. Verwenden Sie einen einzigen Editor oder eine Reihe von Tastenkombinationen f\u00fcr alle Textbearbeitungsvorg\u00e4nge. Sie m\u00fcssen nicht mehr innehalten und nachdenken, um einen Text zu bearbeiten: Die notwendigen Tastenanschl\u00e4ge werden ein Reflex sein. Der Editor wird zu einer Verl\u00e4ngerung Ihrer Hand, die Tasten werden singen, wenn sie sich ihren Weg durch Text und Gedanken bahnen. Stellen Sie sicher, dass der von Ihnen gew\u00e4hlte Editor auf allen von Ihnen verwendeten Plattformen verf\u00fcgbar ist. Emacs, vi, CRiSP, Brief und andere sind auf mehreren Plattformen verf\u00fcgbar, oft in GUI- und Nicht-GUI-Versionen (Textbildschirm). <\/p>\n\n

                        Editor-Funktionen:<\/p>\n\n

                          \n
                        • Konfigurierbar<\/li>\n\n\n\n
                        • Erweiterbar<\/li>\n\n\n\n
                        • Programmierbar<\/li>\n<\/ul>\n\n

                          Mein Lieblingszitat aus dem Kapitel: „Werkzeuge verst\u00e4rken Ihr Talent. Je besser Ihre Werkzeuge sind und je besser Sie wissen, wie man sie benutzt, desto produktiver k\u00f6nnen Sie sein.“<\/em><\/strong><\/p>\n\n

                          Viertes Kapitel: Pragmatische Paranoia<\/strong><\/p>\n\n

                            \n
                          1. Design im Auftrag<\/strong><\/li>\n<\/ol>\n\n

                            Das Konzept des Design by Contract ist eine einfache, aber wirkungsvolle Technik, die sich auf die Dokumentation und Vereinbarung der Rechte und Pflichten von Softwaremodulen konzentriert, um die Korrektheit des Programms sicherzustellen. Ein korrektes Programm tut nicht mehr und nicht weniger, als es zu tun behauptet. Die Dokumentation und \u00dcberpr\u00fcfung dieses Anspruchs ist das Herzst\u00fcck von Design by Contract. Jede Funktion und Methode in einem Softwaresystem tut etwas. Bevor sie startet, kann die Routine einige Erwartungen an den Zustand der Welt haben. Zu den Erwartungen und Anspr\u00fcchen geh\u00f6ren; <\/p>\n\n

                              \n
                            • Vorbedingungen: Was muss erf\u00fcllt sein, damit die Routine aufgerufen werden kann?<\/li>\n\n\n\n
                            • Invariante der Klasse: Eine Klasse stellt sicher, dass diese Bedingung aus Sicht des Aufrufers immer aktuell ist.<\/li>\n\n\n\n
                            • Nach-Bedingungen: Die Tatsache, dass die Routine eine Nachbedingung hat, bedeutet, dass sie zu einem Ergebnis kommt: Endlosschleifen sind nicht erlaubt.<\/li>\n<\/ul>\n\n

                              Implementierung von Design by Contract<\/strong><\/p>\n\n

                              Der Hauptvorteil der DBC ist, dass sie die Frage der Anforderungen und Garantien in den Vordergrund r\u00fcckt. Die einfache Aufz\u00e4hlung des Eingabebereichs, der Randbedingungen und dessen, was die Routine zu liefern verspricht bzw. was sie nicht zu liefern verspricht, ist ein gro\u00dfer Fortschritt beim Schreiben besserer Software. Wenn Sie diese Dinge nicht angeben, programmieren Sie nach dem Zufallsprinzip und genau hier beginnen viele Projekte, enden und scheitern. In Sprachen, die DBC im Code nicht unterst\u00fctzen, k\u00f6nnen Sie nur so weit gehen, was gar nicht so schlecht ist. Schlie\u00dflich ist DBC eine Entwurfstechnik. <\/p>\n\n

                                \n
                              1. Tote Programme l\u00fcgen nicht<\/strong><\/li>\n<\/ol>\n\n

                                Es ist leicht, in die Denkweise „das kann nicht passieren“ zu verfallen. Die meisten von Ihnen haben schon Code geschrieben, der nicht \u00fcberpr\u00fcft hat, ob eine Datei erfolgreich geschlossen wurde oder ob eine Trace-Anweisung wie erwartet geschrieben wurde. Wahrscheinlich war das auch gar nicht n\u00f6tig, denn der betreffende Code w\u00fcrde unter normalen Bedingungen nicht fehlschlagen. Aber Sie programmieren defensiv. Sie suchen nach fehlerhaften Zeigern in anderen Teilen Ihres Programms und l\u00f6schen den Stack. Sie \u00fcberpr\u00fcfen, ob die geladenen Versionen der gemeinsam genutzten Bibliotheken korrekt sind. <\/p>\n\n

                                Alle Fehler geben Ihnen Informationen. Sie k\u00f6nnten sich selbst davon \u00fcberzeugen, dass der Fehler nicht passieren kann und ihn einfach ignorieren. Stattdessen sagt sich ein pragmatischer Programmierer, dass etwas sehr, sehr Schlimmes passiert ist, wenn ein Fehler auftritt. <\/p>\n\n

                                Abst\u00fcrzen, nicht ausmisten<\/strong><\/p>\n\n

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

                                Einer der Vorteile, Probleme so fr\u00fch wie m\u00f6glich zu erkennen, ist, dass Sie fr\u00fcher abst\u00fcrzen k\u00f6nnen.<\/p>\n\n

                                Und in vielen F\u00e4llen ist ein Absturz Ihres Programms das Beste, was Sie tun k\u00f6nnen. Die Alternative w\u00e4re vielleicht, weiterhin besch\u00e4digte Daten in eine robuste Datenbank zu schreiben oder die Waschmaschine in den zwanzigsten aufeinanderfolgenden Schleudergang zu schicken. <\/p>\n\n

                                  \n
                                1. Selbstbewusste Programmierung<\/strong><\/li>\n<\/ol>\n\n

                                  Der Z\u00e4hlerstand kann nicht negativ sein, der Druck kann nicht fehlschlagen, die Protokollierung kann nicht fehlschlagen oder dies kann niemals passieren. \u00dcben Sie diese Art von T\u00e4uschung nicht aus, vor allem nicht beim Programmieren. Wenn es nicht passieren kann, wenden Sie Assertions an, um sicherzustellen, dass es nicht passieren wird. <\/p>\n\n

                                  Wann immer Sie denken, dass „das niemals passieren k\u00f6nnte“, f\u00fcgen Sie Code hinzu, um dies zu \u00fcberpr\u00fcfen. Der einfachste Weg, dies zu tun, ist die Verwendung von Assertions. In den meisten C- und C++-Implementierungen finden Sie eine Form von assert oder assert-Makros, die eine boolesche Bedingung \u00fcberpr\u00fcfen. Diese Makros k\u00f6nnen von unsch\u00e4tzbarem Wert sein. Assertions helfen auch bei der \u00dcberpr\u00fcfung der Funktionsweise eines Algorithmus. Angenommen, Sie haben einen ausgekl\u00fcgelten Algorithmus geschrieben; Assertions pr\u00fcfen, ob er funktioniert. <\/p>\n\n

                                  Verwenden Sie keine Assertions anstelle der eigentlichen Fehlerbehandlung. Assertions pr\u00fcfen auf Dinge, die niemals passieren sollten, und stellen Sie sicher, dass die von Ihnen verwendete Assertion-Methode keine Nebeneffekte hat, die neue Fehler verursachen k\u00f6nnten. <\/p>\n\n

                                  Lassen Sie Behauptungen auf<\/strong><\/p>\n\n

                                  Bei Menschen, die Compiler und Sprachumgebungen schreiben, ist eine weit verbreitete Fehlinterpretation von Assertions weit verbreitet. Sie lautet: „Assertions f\u00fcgen dem Code einen gewissen Overhead hinzu. Da sie Dinge \u00fcberpr\u00fcfen, die nie passieren sollten, werden sie nur durch einen Fehler im Code ausgel\u00f6st. Sobald der Code getestet und ausgeliefert wurde, schalten Sie die Assertions aus, damit der Code schneller l\u00e4uft.“ <\/p>\n\n

                                  Mein Lieblingszitat aus dem Kapitel: „Assertions f\u00fcgen dem Code einen gewissen Overhead hinzu. Da sie Dinge \u00fcberpr\u00fcfen, die niemals passieren sollten, werden sie nur durch einen Fehler im Code ausgel\u00f6st. Sobald der Code getestet und ausgeliefert wurde, werden sie nicht mehr ben\u00f6tigt und sollten abgeschaltet werden, damit der Code schneller l\u00e4uft.“<\/em><\/strong><\/p>\n\n

                                  Kapitel F\u00fcnf: Biegen oder Brechen<\/strong><\/p>\n\n

                                    \n
                                  1. Entkopplung und das Gesetz von Demeter<\/strong><\/li>\n<\/ol>\n\n

                                    Organisieren Sie Ihren Code in Module und kontrollieren Sie die Interaktion zwischen ihnen. Wenn ein Modul besch\u00e4digt wird und ersetzt werden muss, sollten die anderen Module weiterarbeiten. <\/p>\n\n

                                    Kopplung minimieren<\/p>\n\n

                                    Es ist nichts dagegen einzuwenden, wenn Module voneinander wissen. Allerdings m\u00fcssen Sie darauf achten, mit wie vielen anderen Modulen Sie interagieren und, noch wichtiger, wie Sie dazu gekommen sind, mit ihnen zu interagieren. Wenn Sie ein Objekt um einen bestimmten Dienst bitten, m\u00f6chten Sie, dass dieser Dienst in Ihrem Namen ausgef\u00fchrt wird. Sie m\u00f6chten nicht, dass das Objekt Ihnen eine fremde Entit\u00e4t liefert, mit der Sie sich auseinandersetzen m\u00fcssen, um den gew\u00fcnschten Dienst zu erhalten. <\/p>\n\n

                                    Das Gesetz der Demeter<\/strong><\/p>\n\n

                                    Das Demeter-Gesetz f\u00fcr Funktionen besagt, dass jede Methode eines Objekts nur Prozesse aufrufen sollte, die zu ihr selbst geh\u00f6ren, alle an die Methode \u00fcbergebenen Parameter, alle von ihr erstellten Objekte und alle direkt gehaltenen zusammengesetzten Objekte. Das Demeter-Gesetz zielt darauf ab, die Kopplung zwischen Modulen in einem bestimmten Programm zu minimieren. Es verhindert, dass Sie in ein Objekt eingreifen, um Zugriff auf die Methoden eines dritten Objekts zu erhalten. Das Schreiben von „scheuem“ Code ehrt das Gesetz der Demeter und erreicht Ihr Ziel, die Kopplung zwischen den Modulen zu minimieren. <\/p>\n\n

                                      \n
                                    1. Metaprogrammierung<\/strong><\/li>\n<\/ol>\n\n

                                      Details bringen Ihren perfekten Code erheblich durcheinander, wenn sie sich h\u00e4ufig \u00e4ndern. Jedes Mal, wenn Sie den Code \u00e4ndern m\u00fcssen, um ihn an eine \u00c4nderung der Gesch\u00e4ftslogik, des Gesetzes oder des Zeitgeschmacks des Managements anzupassen, laufen Sie Gefahr, das System durch die Einf\u00fchrung eines neuen Fehlers zu zerst\u00f6ren. <\/p>\n\n

                                      Genug mit den Details! Holen Sie sie aus dem Code heraus. Und wenn Sie schon dabei sind, k\u00f6nnen Sie Ihren Code hochgradig konfigurierbar und „weich“ machen. Das hei\u00dft, er l\u00e4sst sich leicht an \u00c4nderungen anpassen.<\/p>\n\n

                                      Dynamische Konfiguration<\/strong><\/p>\n\n

                                      Konfigurieren Sie, integrieren Sie nicht. Sie sollten Ihre Systeme in hohem Ma\u00dfe konfigurierbar machen. Dabei geht es nicht nur um Bildschirmfarben oder Eingabeaufforderungstexte, sondern auch um tief verwurzelte Dinge wie die Auswahl von Algorithmen, Datenbankprodukten, Middleware-Technologien und die Gestaltung der Benutzeroberfl\u00e4che, die Sie als Konfigurationsoptionen und nicht durch Integration oder Engineering anwenden sollten. <\/p>\n\n

                                      Wann Sie konfigurieren m\u00fcssen<\/strong><\/p>\n\n

                                      Stellen Sie Ihre Konfigurations-Metadaten im Klartext dar; das macht das Leben viel einfacher. Aber wann sollte ein Programm diese Konfiguration lesen? Viele Programme scannen solche Dinge nur beim Start. Das ist ungl\u00fccklich, weil Sie dann gezwungen sind, die Anwendung neu zu starten, wenn Sie das Layout \u00e4ndern m\u00fcssen. Ein flexiblerer Ansatz ist es, Programme zu schreiben, die ihre Konfiguration w\u00e4hrend der Ausf\u00fchrung neu laden. Diese Flexibilit\u00e4t hat zwar ihren Preis, ist aber auch komplexer zu implementieren. <\/p>\n\n

                                      \u00dcberlegen Sie also, wie die Benutzer Ihre Anwendung verwenden werden: Wenn es sich um einen lang laufenden Serverprozess handelt, sollten Sie eine M\u00f6glichkeit vorsehen, die Metadaten w\u00e4hrend der Ausf\u00fchrung des Programms erneut zu lesen und anzuwenden. Bei einer kleinen Client-GUI-Anwendung, die schnell neu gestartet wird, brauchen Sie das vielleicht nicht. <\/p>\n\n

                                        \n
                                      1. Zeitliche Kopplung<\/strong><\/li>\n<\/ol>\n\n

                                        Hier spricht der Autor \u00fcber Zeit als Gestaltungselement der Software selbst. Es gibt zwei Aspekte der Zeit, die f\u00fcr Sie wichtig sind: Gleichzeitigkeit (Dinge, die gleichzeitig geschehen) und Ordnung (die relativen Positionen der Dinge in der Zeit). Bei der zeitlichen Kopplung wird die Gleichzeitigkeit immer vor der Ordnung aufgerufen; Sie k\u00f6nnen immer nur einen Bericht gleichzeitig ausf\u00fchren; danach warten Sie, bis der Bildschirm neu gezeichnet ist, bevor Sie auf eine Schaltfl\u00e4che klicken. <\/p>\n\n

                                        Lieblingszitat aus diesem Kapitel: „Keine noch so gro\u00dfe Genialit\u00e4t kann die Besch\u00e4ftigung mit Details \u00fcberwinden.“<\/em><\/strong><\/p>\n\n

                                        Sechstes Kapitel: W\u00e4hrend Sie programmieren<\/strong><\/p>\n\n

                                          \n
                                        1. Programmieren nach dem Zufallsprinzip<\/strong><\/li>\n<\/ol>\n\n

                                          Es gibt Hunderte von Fallen, die jeden Tag darauf warten, Sie als Entwickler zu erwischen. Seien Sie vorsichtig damit, falsche Schl\u00fcsse zu ziehen. Vermeiden Sie es, nach dem Zufallsprinzip zu programmieren, sich auf Gl\u00fcck und zuf\u00e4llige Erfolge zu verlassen und stattdessen bewusst zu programmieren. Wenn Sie nach dem Zufallsprinzip programmieren und Ihr Code scheitert, werden Sie nicht wissen, warum er scheitert, weil Sie bei den wenigen Tests, die Sie durchgef\u00fchrt haben, nicht wussten, warum er \u00fcberhaupt funktioniert hat. <\/p>\n\n

                                          Unf\u00e4lle bei der Umsetzung<\/strong><\/p>\n\n

                                          Unf\u00e4lle bei der Implementierung sind Dinge, die einfach deshalb passieren, weil der Code so geschrieben ist, wie er ist. Am Ende verlassen Sie sich auf undokumentierte Fehler oder Randbedingungen. Die Randbedingung, auf die Sie sich verlassen, ist vielleicht nur ein Zufall. Unter anderen Umst\u00e4nden (z.B. bei einer anderen Bildschirmaufl\u00f6sung) k\u00f6nnte sie sich anders verhalten. <\/p>\n\n

                                          Das undokumentierte Verhalten kann sich mit der n\u00e4chsten Version der Bibliothek \u00e4ndern.<\/p>\n\n

                                          Wie Sie bewusst programmieren<\/strong><\/p>\n\n

                                            \n
                                          • Programmieren Sie nicht mit verbundenen Augen.<\/li>\n\n\n\n
                                          • Verlassen Sie sich nur auf zuverl\u00e4ssige Dinge. Verlassen Sie sich nicht auf Zuf\u00e4lle oder Annahmen. <\/li>\n\n\n\n
                                          • Dokumentieren Sie Ihre Annahmen.<\/li>\n<\/ul>\n\n
                                              \n
                                            1. Algorithmus Geschwindigkeit<\/strong><\/li>\n<\/ol>\n\n

                                              Als pragmatischer Programmierer sch\u00e4tzen Sie die Ressourcen von Algorithmen, wie Zeit, Prozessor und Speicher. Die meisten nicht trivialen Algorithmen verarbeiten irgendeine Art von variabler Eingabe; die Gr\u00f6\u00dfe dieser Eingabe hat Auswirkungen auf den Algorithmus. Je gr\u00f6\u00dfer die Informationen sind, desto l\u00e4nger ist die Laufzeit oder desto mehr Speicher wird verbraucht. <\/p>\n\n

                                              Sie werden feststellen, dass Sie unbewusst die Laufzeit- und Speicheranforderungen \u00fcberpr\u00fcfen, wenn Sie etwas schreiben, das Schleifen oder rekursive Aufrufe enth\u00e4lt. Dieser Prozess ist eine schnelle Best\u00e4tigung daf\u00fcr, dass Ihre Aktionen unter den gegebenen Umst\u00e4nden sinnvoll sind. Deshalb f\u00fchren Sie eine detailliertere Analyse durch. Hier kommt die O()-Notation ins Spiel. Die O()-Notation ist eine mathematische Methode, um mit N\u00e4herungen umzugehen. <\/p>\n\n

                                                \n
                                              1. Refactoring<\/strong><\/li>\n<\/ol>\n\n

                                                Code muss sich weiterentwickeln, er ist nicht statisch. Wenn sich ein Programm weiterentwickelt, wird es notwendig, fr\u00fchere Entscheidungen zu \u00fcberdenken und Teile des Codes zu \u00fcberarbeiten. Das Umschreiben, Umstrukturieren und Umgestalten eines bestehenden Codes, das \u00c4ndern seiner internen Struktur, ohne sein \u00e4u\u00dferes Verhalten zu ver\u00e4ndern, wird als Refactoring bezeichnet. <\/p>\n\n

                                                Wann sollten Sie refaktorisieren?<\/strong><\/p>\n\n

                                                Angenommen, Sie sto\u00dfen auf einen Stolperstein, weil der Code nicht mehr ganz passt oder Ihnen zwei Dinge auffallen, die Sie zusammenf\u00fchren sollten, dann z\u00f6gern Sie nicht, ihn zu \u00e4ndern. Hier sind einige Dinge, die dazu f\u00fchren k\u00f6nnen, dass der Code f\u00fcr ein Refactoring in Frage kommt: <\/p>\n\n

                                                Duplikation. Sie haben einen Versto\u00df gegen das DRY-Prinzip (Don’t Repeat Yourself) entdeckt. <\/p>\n\n

                                                Nicht-orthogonaler Entwurf. Sie haben einen Code oder ein Verfahren entdeckt, das noch orthogonaler gestaltet werden k\u00f6nnte (Orthogonalit\u00e4t). <\/p>\n\n

                                                Veraltetes Wissen. Die Dinge \u00e4ndern sich, die Anforderungen \u00e4ndern sich, und Ihr Verst\u00e4ndnis des Problems w\u00e4chst. Der Code muss damit Schritt halten. <\/p>\n\n

                                                Leistung. Sie m\u00fcssen Funktionen aus einem Bereich des Systems in einen anderen verschieben, um die Leistung zu verbessern. <\/p>\n\n

                                                  \n
                                                1. Code, der leicht zu testen ist<\/strong><\/li>\n<\/ol>\n\n

                                                  Bei komplexeren Chips und Systemen integrieren die Hardwareentwickler Funktionen wie einen vollst\u00e4ndigen BIST (Build-In Self Test), der intern Diagnosen auf der Basisebene durchf\u00fchrt, und einen TAM (Test Access Mechanism), der ein Test-Kabelbaum bereitstellt, der es der externen Umgebung erm\u00f6glicht, Stimuli zu liefern und Antworten des Chips zu sammeln. Sie k\u00f6nnen dasselbe in der Software tun, die Testbarkeit von Anfang an in die Software einbauen und jedes Teil im Detail testen, bevor Sie versuchen, es miteinander zu verbinden. <\/p>\n\n

                                                  Einheitstest<\/strong><\/p>\n\n

                                                  Das Testen auf Chipebene bei Hardware entspricht dem Unit-Test bei Software. Jedes Modul wird isoliert getestet, um sein Verhalten zu \u00fcberpr\u00fcfen. Sie k\u00f6nnen besser verstehen, wie ein Modul in der gro\u00dfen weiten Welt reagieren wird, wenn Sie es unter kontrollierten Bedingungen gr\u00fcndlich getestet haben. <\/p>\n\n

                                                  Ein Software-Einheitstest ist ein Code, der ein Modul testet. Normalerweise richtet der Unit-Test eine k\u00fcnstliche Umgebung ein und ruft dann Routinen in dem zu testenden Modul auf. Der Unit-Test pr\u00fcft dann die zur\u00fcckgegebenen Ergebnisse, entweder gegen bekannte Werte oder gegen die Ergebnisse der vorherigen Durchl\u00e4ufe desselben Tests. <\/p>\n\n

                                                  Wenn Sie sp\u00e4ter Ihre „integrierten Software-Schaltkreise“ zu einem kompletten System zusammenf\u00fcgen, k\u00f6nnen Sie sich darauf verlassen, dass die einzelnen Teile wie erwartet funktionieren. Dann k\u00f6nnen Sie die gleichen Unit-Tests verwenden, um das System als Ganzes zu testen. <\/p>\n\n

                                                  Lieblingszitat des Kapitels: „Jede Software, die Sie schreiben, wird getestet – wenn nicht von Ihnen und Ihrem Team, dann von den sp\u00e4teren Benutzern – also sollten Sie sie gr\u00fcndlich testen.<\/em><\/strong><\/p>\n\n

                                                  Kapitel Sieben: Vor dem Projekt<\/strong><\/p>\n\n

                                                  \"\"<\/figure>\n\n
                                                    \n
                                                  1. Die Anforderungsgrube<\/strong><\/li>\n<\/ol>\n\n

                                                    Das Sammeln von Anforderungen ist eine fr\u00fche Phase des Projekts. Sammeln bedeutet, dass die Anforderungen bereits vorhanden sind, Sie m\u00fcssen sie nur noch finden. Legen Sie sie in Ihren Korb und machen Sie sich auf den Weg. Obwohl es so nicht funktioniert, tauchen die Anforderungen nur selten auf. Sie sind tief unter Schichten von Annahmen, Missverst\u00e4ndnissen und Politik begraben. <\/p>\n\n

                                                    Auf der Suche nach Anforderungen<\/strong><\/p>\n\n

                                                    Wie erkennen Sie einen echten Bedarf, wenn Sie sich durch den Schmutz der Umgebung w\u00fchlen? Die Antwort ist sowohl komplex als auch einfach. Die einfache Antwort ist eine Aussage \u00fcber etwas, das erf\u00fcllt werden muss. Andererseits sind nur sehr wenige Anforderungen eindeutig, was die Anforderungsanalyse komplex macht. <\/p>\n\n

                                                    Wenn die Anforderung lautet: „Nur Mitarbeiter k\u00f6nnen einen Mitarbeiterdatensatz einsehen“, dann werden Sie jedes Mal, wenn die Anwendung auf diese Dateien zugreift, einen einfachen Test programmieren m\u00fcssen. Lautet die Anweisung jedoch „Nur autorisierte Benutzer k\u00f6nnen auf einen Mitarbeiterdatensatz zugreifen“, wird der Entwickler wahrscheinlich eine Art von Zugriffskontrollsystem entwerfen und implementieren. Wenn sich die Richtlinien \u00e4ndern, m\u00fcssen nur die Metadaten f\u00fcr dieses System aktualisiert werden. Wenn Sie die Anforderungen auf diese Weise sammeln, erhalten Sie ein System, das die Metadaten gut unterst\u00fctzt. <\/p>\n\n

                                                      \n
                                                    1. L\u00f6sen Sie unm\u00f6gliche R\u00e4tsel<\/strong><\/li>\n<\/ol>\n\n

                                                      Denken Sie an Puzzles aus der realen Welt, die als Weihnachtsgeschenke oder auf Flohm\u00e4rkten auftauchen. Sie m\u00fcssen den Ring entfernen oder die T-f\u00f6rmigen Teile in die Schachtel legen. Sie ziehen den Ring ab und stellen schnell fest, dass die scheinbaren L\u00f6sungen das R\u00e4tsel nicht l\u00f6sen. Die Antwort liegt ganz woanders. Das Geheimnis zur L\u00f6sung des R\u00e4tsels besteht darin, die wirklichen Zw\u00e4nge zu erkennen und darin eine L\u00f6sung zu finden. Einige Zw\u00e4nge sind absolut, andere sind lediglich vorgefasste Meinungen. Grundlegende Zw\u00e4nge m\u00fcssen beachtet werden, auch wenn sie noch so geschmacklos oder dumm erscheinen m\u00f6gen. Auf der anderen Seite sind einige scheinbare Zw\u00e4nge m\u00f6glicherweise nicht korrekt. <\/p>\n\n

                                                      Denken Sie nicht au\u00dferhalb der Box – finden Sie die Box<\/strong><\/p>\n\n

                                                      Wenn Sie vor einem unl\u00f6sbaren Problem stehen, z\u00e4hlen Sie alle m\u00f6glichen Wege auf, die Sie vor sich haben.<\/p>\n\n

                                                      Lehnen Sie nichts ab, auch wenn es noch so unbrauchbar oder dumm klingt. Gehen Sie die Liste durch und erkl\u00e4ren Sie, warum Sie einen bestimmten Weg nicht einschlagen k\u00f6nnen. K\u00f6nnen Sie es beweisen? <\/p>\n\n

                                                        \n
                                                      1. Nicht bevor Sie bereit sind<\/strong><\/li>\n<\/ol>\n\n

                                                        Wenn Sie bei einer Aufgabe anhaltende Zweifel oder Widerwillen versp\u00fcren, sollten Sie darauf achten. Vielleicht k\u00f6nnen Sie nicht herausfinden, was genau falsch ist. Geben Sie dem Ganzen Zeit und Ihre Zweifel werden sich wahrscheinlich zu etwas Handfesterem herauskristallisieren, etwas, das Sie angehen k\u00f6nnen. Softwareentwicklung ist immer noch keine Wissenschaft. Lassen Sie Ihre Instinkte zu Ihrer Leistung beitragen. <\/p>\n\n

                                                        Gutes Urteilsverm\u00f6gen oder Aufschieberitis?<\/strong><\/p>\n\n

                                                        <\/p>\n\n

                                                        Der Beginn eines neuen Projekts oder sogar eines neuen Moduls in einem bestehenden Projekt kann eine schmerzhafte Erfahrung sein. Viele w\u00fcrden es vorziehen, den Anfang zu verschieben. Woran erkennen Sie also, dass Sie einfach nur z\u00f6gern, anstatt verantwortungsbewusst darauf zu warten, dass alle Teile an ihren Platz fallen? <\/p>\n\n

                                                        Unter diesen Umst\u00e4nden ist eine Technik, die Ihnen helfen kann, das Prototyping. W\u00e4hlen Sie einen Bereich, den Sie f\u00fcr schwierig halten, und beginnen Sie mit der Erstellung eines Konzeptnachweises. Schon nach kurzer Zeit werden Sie denken, dass Sie Ihre Zeit verschwenden. Diese Langeweile ist wahrscheinlich ein gutes Indiz daf\u00fcr, dass Ihre anf\u00e4ngliche Zur\u00fcckhaltung nur der Wunsch war, die Verpflichtung, mit dem Projekt zu beginnen, aufzuschieben. Geben Sie den Prototyp auf und machen Sie sich an die eigentliche Entwicklung. <\/p>\n\n

                                                        Lieblingszitat des Kapitels: „Vollkommenheit ist nicht erreicht, wenn es nichts mehr hinzuzuf\u00fcgen gibt, sondern wenn es nichts mehr wegzunehmen gibt….“<\/em><\/strong><\/p>\n\n

                                                        Achtes Kapitel<\/strong>: Pragmatische Projekte<\/p>\n\n

                                                          \n
                                                        1. R\u00fccksichtslose Tests<\/strong><\/li>\n<\/ol>\n\n

                                                          Testen Sie fr\u00fch, testen Sie oft und testen Sie automatisch. Sie sollten mit dem Testen beginnen, sobald Sie den Code haben. Entwickeln Sie ausgefeilte Testpl\u00e4ne f\u00fcr Ihre Projekte. Teams, die automatisierte Tests verwenden, haben eine viel bessere Chance auf Erfolg. Tests, die bei jedem Build ausgef\u00fchrt werden, sind viel effektiver als Testpl\u00e4ne, die im Regal liegen. Denken Sie daran: Je fr\u00fcher Sie einen Fehler finden, desto billiger ist es, ihn zu beheben. „Ein wenig kodieren, ein wenig testen.“ <\/p>\n\n

                                                          Damit Ihr Projekt zufriedenstellend ist, muss es mehr Testcode als Produktionscode enthalten. Die Zeit, die bei der Erstellung dieses Testcodes verloren geht, ist die M\u00fche wert und auf lange Sicht billiger. Au\u00dferdem haben Sie die Chance, ein Produkt mit nahezu null Fehlern zu erstellen. <\/p>\n\n

                                                            \n
                                                          1. Gro\u00dfe Erwartungen<\/strong><\/li>\n<\/ol>\n\n

                                                            Der Erfolg des Projekts Ihres Teams wird daran gemessen, wie es die Erwartungen der Benutzer erf\u00fcllt. Wenn Ihr Projekt hinter den Erwartungen zur\u00fcckbleibt, gilt es als Misserfolg, unabh\u00e4ngig davon, wie gut das Ergebnis in absoluten Zahlen ist. <\/p>\n\n

                                                            Die extra Meile<\/strong><\/p>\n\n

                                                            \u00dcbertreffen Sie sanft die Erwartungen Ihrer Benutzer. Erschrecken Sie Ihre Benutzer nicht, sondern \u00fcberraschen Sie sie. Geben Sie ihnen ein bisschen mehr, als sie erwartet haben. Der zus\u00e4tzliche Aufwand, der erforderlich ist, um dem System eine benutzerorientierte Funktion hinzuzuf\u00fcgen, wird sich immer wieder durch Wohlwollen auszahlen. <\/p>\n\n

                                                              \n
                                                            1. Stolz und Vorurteile<\/strong><\/li>\n<\/ol>\n\n

                                                              Als pragmatischer Programmierer sollten Sie nicht vor der Verantwortung weglaufen. Freuen Sie sich vielmehr, wenn Sie vor Herausforderungen stehen, und machen Sie Ihre Arbeitsexpertise bekannt. Wenn Sie f\u00fcr ein Design oder ein St\u00fcck Code verantwortlich sind, werden Sie eine Arbeit machen, auf die Sie stolz sind. <\/p>\n\n

                                                              Signieren Sie Ihre Arbeit<\/strong><\/p>\n\n

                                                              Seien Sie stolz auf Ihr Eigentum. „Sie haben das geschrieben und Sie sollten hinter Ihrer Arbeit stehen“. Ihre Unterschrift sollte als Indikator f\u00fcr Qualit\u00e4t anerkannt werden. Die Leute sollten Ihren Namen auf einem St\u00fcck Code sehen und erwarten, dass es solide, gut geschrieben, getestet und dokumentiert ist – eine professionelle Arbeit, die von einem echten Profi gemacht wurde. <\/p>\n\n

                                                              Mein Lieblingszitat aus diesem Kapitel: „Die Zivilisation schreitet voran, indem sie die Zahl der wichtigen Operationen, die wir ohne Nachdenken ausf\u00fchren k\u00f6nnen, erweitert.“<\/em><\/strong><\/p>\n\n

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

                                                              „The Pragmatic Programmer“ von Andrew Hunt und David Thomas ist ein klassisches Buch zur Softwareentwicklung, das praktische Ratschl\u00e4ge und Techniken zur Verbesserung der Arbeitsweise von Entwicklern bietet. Es behandelt Themen wie Debugging, Testen, Automatisierung und Projektmanagement sowie die Bedeutung von Kommunikation und kontinuierlichem Lernen. Wenn Sie den Anleitungen des Buches folgen, k\u00f6nnen Entwickler ihre Programmierkenntnisse verbessern, ihre Produktivit\u00e4t steigern, effizienter arbeiten, effektivere Teammitglieder werden und bessere Softwareprodukte liefern. <\/p>\n","protected":false},"excerpt":{"rendered":"

                                                              The Pragmatic Programmer ist ein geschickter und praktischer Leitfaden, der Ihnen Einblicke und Grundlagen vermittelt, um ein guter Programmierer zu sein, und der Ihre Spezialisierung und die technischen Aspekte der modernen Softwareentwicklung erweitert. Das Buch wurde im Oktober 1999 ver\u00f6ffentlicht. Andrew Hunt behandelt Themen wie pers\u00f6nliche Verantwortung und Karriereentwicklung bis hin zu architektonischen Techniken, mit […]<\/p>\n","protected":false},"author":1,"featured_media":17633,"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-19683","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\/19683","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=19683"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19683\/revisions"}],"predecessor-version":[{"id":19684,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19683\/revisions\/19684"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media\/17633"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media?parent=19683"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/categories?post=19683"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/tags?post=19683"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/writer?post=19683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}