Vermeiden Sie diese 5 Dinge, wenn Sie Software veröffentlichen

Die Kosten eines Softwareausfalls können sich auf unterschiedliche Weise bemerkbar machen – zum Beispiel im Aktienkurs einer Aktiengesellschaft oder bei einem kleinen Unternehmen, was die Auflösung des Geschäfts bedeuten kann.

Allzu oft sehe ich Unternehmen, die Software auf eine Weise veröffentlichen, die ungefähr so ​​sicher ist wie ein russisches Roulette-Spiel - mit der Sicherheit, den privaten Daten und der Sicherheit ihrer Kunden zu spielen, ganz zu schweigen von der Zuverlässigkeit. Sie spielen auch mit dem Ruf und dem Endergebnis ihres Unternehmens. IEEE hat eine ausgezeichnete Liste von öffentlichen Fehlern vor ein paar Jahren und Sie können sicher sein, dass Software immer noch ausfällt. 

Der Grund, warum ich diese etwas beängstigende Analogie mag, ist, dass ich allzu oft Leute Dinge sagen höre wie „Diese Software ist schon lange nicht mehr verfügbar und hatte keine Probleme“ oder „Wir haben es immer so und so gemacht funktioniert “- aber das ist natürlich eine schlechte Art zu planen. Ein Unternehmen, das sich auf Software-Engineering konzentriert, sucht nach Möglichkeiten, bessere Software zu erstellen und zu veröffentlichen, die weniger ausfällt. Dies bedeutet, proaktiv den Erfolg zu planen, indem man das Richtige tut, auch wenn das Falsche bisher geklappt hat.

Forscher in Harvard haben festgestellt, dass etwa die Hälfte der IT-Softwareprojekte fehlschlägt. Es gibt viele Zahlen von anderen und diese Schätzung ist nicht die höchste, also nehmen wir es für eine Minute. Dies ist wie russisches Roulette mit 3 Kugeln in der Kammer zu spielen - eine 50: 50-Chance auf einen Misserfolg. Ich mag diese Chancen nicht und würde die Zukunft meines Unternehmens sicherlich nicht darauf setzen.

Schauen wir uns einige der fiesen Glücksspiele an, die Menschen jeden Tag machen, wenn sie ihre Software veröffentlichen. Kugeln in ihrer Roulette-Waffe, wenn Sie so wollen:

1. Alte bekannte Fehler

Wir alle wissen, dass wir Software mit Fehlern veröffentlichen, weil es ewig dauern würde, fehlerfreie Software zu erstellen. Aber das ist keine Entschuldigung dafür, die Fehler, die wir kennen, nie zu beheben. Es wurde viel über technische Schulden in sehr abstrakten Begriffen gesagt, aber dies ist ein echtes praktisches Maß für die Schulden in Ihrer Software. Wenn dort ein Fehler ist und Sie ihn nicht beheben, sollten Sie einen ziemlich guten Grund haben, warum Sie denken, dass es keine Rolle spielt. Planen Sie für jede Version etwas Zeit ein, um nicht nur neue Funktionen hinzuzufügen, sondern die Dinge im Allgemeinen zu verbessern. Nehmen Sie sich Zeit, um Ihre Software zu polieren.

2. Neue Fehler im alten Code

Alter Code ist knifflig. Ich habe Unternehmen gesehen, die eine Richtlinie haben, die lautet: „Bereinigen Sie es, wenn Sie es trotzdem reparieren“ und andere, bei denen die Regel lautet: „Nur anfassen, was Sie müssen, und nur, wenn es einen aus der Praxis gemeldeten Fehler gibt“. Beides sind interessante Richtlinien, aber am wichtigsten ist es, das Risiko zu verstehen, das damit verbunden ist, wenn Sie einen neuen Fehler in altem Code finden. Ich arbeitete mit einem Hardware-Hersteller zusammen und dieser hatte Schwierigkeiten damit, wie man die Ausgabe eines neuen Tools für einen Legacy-Code verarbeiten sollte. In ihrem Fall war es ein mehrdeutiges Problem mit dem Umfang, das mich immer noch fragen lässt, wie ihr Compiler einen solchen Wahnsinn zulassen konnte. Sie stießen auf einen Konflikt – einerseits hatten sie dieses neue Tool, und andererseits sollten sie alten Code nicht anfassen, es sei denn, es gab einen Fehlerbericht aus dem Feld.

Es ist wichtig zu verstehen, was Sie mit Ihrem Legacy-Code vorhaben, und das Risiko für Ihr Unternehmen vollständig zu verstehen. Wenn der Code kritisch ist, ist das Alter möglicherweise nicht so wichtig, wie Sie denken. Wenn der Code veraltet ist, verschwenden Sie möglicherweise Zeit damit, Dinge zu testen, die Sie nicht reparieren möchten.

3. Sicherheit als Teil des Testens statt der Entwicklung

Es ist bedrückend häufig, dass Unternehmen die Sicherheit übersehen. In einigen Fällen glauben sie, die Sicherheit in ihrer Anwendung testen zu können (sie können es nicht), während sie in anderen Fällen glauben, dass Sicherheitsprobleme nicht auf ihren Code zutreffen (sie werden es tun). Um aus diesem Durcheinander ständiger Sicherheitsmängel herauszukommen, müssen Unternehmen Code mit soliden AppSec-Best Practices härten, die in einem statischen Analysetool kodifiziert sind, das mehr als nur eine Flussanalyse durchführt. Wenn Sie nicht wissen, wo Sie anfangen sollen, würde es ehrlich gesagt nicht schaden, einfach die MISRA-Regeln zu übernehmen und sie für jeden Code zu befolgen, den Sie ab heute schreiben.

4. Die immer versagende, immer bestandene Testsuite

Eine äußerst häufige und gefährliche Praxis, die ich sehe, besteht darin, eine große Testsuite zu haben und sich auf eine einfache Metrik der Anzahl der bestandenen Tests zu verlassen. Beispielsweise haben Sie normalerweise eine Erfolgsquote von 80%, sodass Sie davon ausgehen, dass dies in Ordnung ist. Das Problem ist, dass es keine Möglichkeit gibt zu wissen, ob die heute verstrichenen 80% mit den gestern verstrichenen 80% übereinstimmen. Es könnte leicht einen neuen echten Fehler geben, der sich in diesen 80% versteckt (da ist), weil etwas anderes behoben wurde und die Zahl ausgeglichen blieb. Halten Sie Ihre Testsuite sauber oder es sagt Ihnen nicht viel. Ich würde ernsthaft den Wert eines Testfehlers in Frage stellen, den Sie gerne ignorieren. Warum nicht einfach diesen Test überspringen - es ist ein ehrlicherer und nützlicherer Ansatz.

5. Freigeben im Kalender

Das wahrscheinlich immer noch am häufigsten verwendete entscheidende Veröffentlichungskriterium ist der Kalender. Die Leute haben ein Datum ausgewählt und jetzt werden sie es veröffentlichen, weil dieses Datum eingetroffen ist. Zugegeben, es gibt externe Probleme, die Ihren Veröffentlichungsplan beeinflussen, aber nur weil ein Datum eingetroffen ist, heißt das nicht, dass es in Ordnung ist, miese Software auf Ihre ahnungslosen zukünftigen Kunden zu übertragen. Lassen Sie los, wenn es fertig / sicher / stabil / gut ist. Wenn es sich bei dem Kalender um eine feste Einschränkung handelt, stellen Sie sicher, dass Ihr Prozess Sie pünktlich dorthin bringt.

Fazit

Wie oft können Sie so veröffentlichen, bevor Sie den Preis bezahlen? In unserer Analogie zum russischen Roulette höchstens sechs, vielleicht nur eins. Lassen Sie uns unser Bestes geben, um sicherzustellen, dass wir die beste Software mit den besten Erfolgschancen liefern.

„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.