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

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

Alle Beiträge anzeigen