Veröffentlicht Jul 31, 2020
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:
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:
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?
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:
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.
Offensives Programmieren geht auf einer höheren Ebene Hand in Hand mit der agilen Methodik. In unserem Unternehmen folgen wir gerne diesen Worten.
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.
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
Vertrauen bei führenden Unternehmen weltweit



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

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

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