Befreien Sie Ihre Codebasis von Paranoia und gewinnen Sie Selbstvertrauen mit offensiver Programmierung

Veröffentlicht Jul 31, 2020


Natürlich sind Fehler nicht gut für eine Schachpartie, aber Fehler sind unvermeidlich, und eine Partie ohne Fehler, oder wie man sagt, eine "fehlerfreie Partie", ist auf jeden Fall farblos. - Mikhail Tal

Stellen Sie sich vor, Sie wären ein Schachspieler und nicht ein Softwareentwickler.

Wie würde sich die Entwicklung Ihrer Figuren auf die Herausforderungen des Gegners einstellen? Werden Sie extrem defensiv oder erlauben Sie sich kalkulierte Risiken und geplante Opfer, indem Sie immer das Endspiel im Kopf haben.

Ich möchte über meine eigene Entwicklung in Bezug auf die Absicht hinter Eröffnungsvarianten sprechen und darüber, wie es mir gelungen ist, durch einige Techniken Vertrauen in meine Codebasis zu gewinnen.

Zunächst begann ich, die defensive Programmiertechnik einzubauen. Dieser Stil stammt aus den Anfängen von C und zielt darauf ab:

  • die Korrektheit des Codes zu gewährleisten und die Anzahl der Fehler zu reduzieren
  • Die Software soll sich trotz unerwarteter Benutzerinteraktionen vorhersehbar verhalten.

Mein Problem mit der defensiven Programmierung ist jedoch, dass sie in der Praxis über das hinausgeht, was beschrieben wird, und zu einem sehr traurigen und hässlichen Ort führt. Ich habe festgestellt, dass wichtige Dinge in meiner Codebasis darunter leiden:

  • Unnötiger Code
  • Lesbarkeit
  • Wartung
  • Verstecken von Ausnahmen

Wenn man sich defensiven Code ansieht, ist es schwer, die Absicht zu verstehen: Wurde er aus Sicherheitsgründen hinzugefügt oder gibt es einen triftigen Grund, warum x null sein kann? Handelt es sich um ein erwartetes Verhalten oder um einen unbehandelten Fehler?

Softwareentwicklung sollte sich nicht wie das Spiel "Whack-a-mole" anfühlen

Meiner Meinung nach ist diese Technik für Benutzereingaben oder externe Schnittstellen konzipiert und sollte nicht über diesen Rahmen hinausgehen.

Unachtsamkeit und mangelnde Disziplin bei der Anwendung dieser Technik können die Ursache für paranoide Programmierung sein. Dieser Ansatz kann ansteckend sein und sich wie ein Lauffeuer in der Codebasis verbreiten. Und damit möchte ich nichts mehr zu tun haben.

Wie können wir also unseren Verstand bewahren, die Kontrolle über das Board übernehmen und unseren Code von der Paranoia befreien? Ich habe herausgefunden, dass die Antwort auf diese Fragen lautet:

Offensive Programmierung, einfach abstürzen

  • Hören Sie auf, Ausnahmen zu verstecken.
  • Erstellen Sie einen guten Stack-Trace, Sie können sich später bedanken.
  • Verwenden Sie Assertions.
  • Wählen Sie Abstürze gegenüber logischen Fehlern, einer viel schlimmeren Version des Absturzes.
  • Ein Absturz des Programms ist erlaubt, anstatt zu versuchen, einen möglicherweise fehlerhaften Prozess fortzusetzen.

Erkennen und nutzen Sie Werkzeuge Ihrer bevorzugten Sprache, um sich zu helfen. Sie sollte der Hauptträger sein, wenn Sie diese Technik anwenden.

Ein kurzes Lob an Kotlin, diese Sprache bietet einige Perlen, die zur Erzwingung von Offensivität verwendet werden können. Ihre Absichten hinter der Nullsicherheit zur Kompilierzeit, dem Erfassen von Annahmen mit require, check und assert, aggressiven oder intelligenten TODOs und vielen anderen Konzepten lassen Sie Ihr Programm auf die fantastischsten Arten abstürzen.

  • Beginnen Sie mit dem Umgang mit den leeren catch or else Blöcken, wir alle wissen, dass Sie irgendwo tief in der Codebasis einen versteckt haben, sehen Sie ihn sich an. Behandeln Sie sie in Ihrem eigenen Tempo.
  • Benutzen Sie Breadcrumbs, das wird Ihnen helfen, das Problem zu reproduzieren, scheitern Sie achtsam.
  • Dokumentieren Sie das Verhalten, hinterlassen Sie Spuren in Ihrem Code, wenn nötig.
  • Verweisen Sie auf Ihre ToDos in Ihrem bevorzugten Projektmanagement-Tool, weisen Sie sie zu und geben Sie ihnen eine Frist, das ist viel angenehmer als einfach wegzusehen.
  • Führen Sie inkrementelle Rollouts ein.

Offensives Programmieren geht auf einer höheren Ebene Hand in Hand mit der agilen Methodik. In unserem Unternehmen folgen wir gerne diesen Worten.

Schnell starten - bewusst brechen - schnell korrigieren - schnell lernen

Wir haben es als eine unserer Stärken erkannt, schnell guten Code zu liefern und unsere Änderungen schnell zu iterieren. Je häufiger Deployments durchgeführt werden, desto mehr Informationen werden gesammelt. Scheuen Sie sich nicht davor, Fehler frühzeitig zu erkennen.

  • Um Vertrauen in Ihre Codebasis zu gewinnen, bedarf es eines strukturierten Ansatzes, seien Sie klug und machen Sie sich klar, dass dies ein fortlaufender Prozess ist.
  • Nutzen Sie den agilen Workflow, das Gambit und die Anwendung der Offensivtechniken, dann werden Sie allmählich viel bessere Ergebnisse erzielen und eine gesündere Codebasis schaffen.

Haben Sie es satt, paranoid und übervorsichtig zu sein, wenn es um Ihre Codebasis geht? Möchten Sie in einem Unternehmen arbeiten, in dem Abstürze gefördert werden und man Ihnen mit Verständnis begegnet? Schauen Sie sich unsere aktuellen Stellenausschreibungenan.

Tanja Zlatanovska

Tanja Zlatanovska

Buchen Sie eine kostenlose Beratung

Wählen Sie Ihre Branche*

Bitte wählen Sie Ihre Branche*

Wählen Sie Ihren Servicetyp

Bitte wählen Sie Ihren Servicetyp

calendarWann passt es Ihnen am besten für ein kurzes Gespräch

Die mit * gekennzeichneten Felder sind Pflichtfelder

Diese Website ist durch reCAPTCHA geschützt und es gelten die Datenschutzerklärung und Nutzungsbedingungen von Google.

Zeit- und Materialaufwand vs. Festpreis

Zeit und Materialien vs. Festpreis: Welches Vertragsmodell reduziert das finanzielle Risiko?

Mar 31, 2026

Wenn die meisten Leute über Zeit und Materialien oder Festpreise diskutieren, sehen sie dies als eine Frage des Projektmanagements. Welches Modell passt zu unserem Arbeitsablauf? Welches Modell passt zu unserem Entwicklungsteam? Diese Fragen sind wichtig - aber sie gehen am Kern der Sache vorbei.

Für einen CFO oder Finanzleiter lautet die eigentliche Frage: Wo liegt das finanzielle Risiko? Die Ve

Aneta Pejchinoska

Aneta Pejchinoska

Scope Creep in der Softwareentwicklung

Verhinderung von Scope Creep in der Softwareentwicklung: Wie man Software-Budgets vorhersehbar hält

Mar 30, 2026

Seien wir ehrlich - Software-Projekte haben den Ruf, das Budget zu sprengen. Und in den meisten Fällen ist die schleichende Ausweitung des Projektumfangs der Übeltäter, der sich im Verborgenen hält.

Nach Angaben des Project Management Institute (PMI) verschwenden Unternehmen im Durchschnitt 97 Millionen Dollar pro 1 Milliarde Dollar, die in Projekte investiert werden, aufg

Aneta Pejchinoska

Aneta Pejchinoska

Ein einfacher Leitfaden zur WCAG-2.1-Konformität

Ein einfacher Leitfaden zur WCAG-2.1-Konfortmität

Jan 4, 2026

Barrierefreiheit sollte von Anfang an in Ihr Produkt integriert sein, nicht erst später hinzugefügt werden. Wenn Menschen mit Behinderungen Ihre Benutzeroberfläche nicht nutzen können, verlieren Sie Kunden, erhöhen die Supportkosten und gehen rechtliche Risiken ein.

Die Zugänglichkeitsrichtlinien für Webinhalte (WCAG 2.1) stammen vom World Wide Web Consortium. Betrachten Sie sie als das Regelwerk

Intertec

Intertec

Alle Beiträge anzeigen