Bugs: Woher sie kommen und wie man sie beseitigt
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Kapitel 1
Bugs: Woher sie kommen und wie
man sie beseitigt
In diesem Kapitel:
Bugs und Debugging 4
Was sind Bugs? 5
Voraussetzungen für das Debuggen 18
Der Debugging-Vorgang 21
Zusammenfassung 31
3
John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)4 Kapitel 1: Bugs: Woher sie kommen und wie man sie beseitigt Debugging ist ein faszinierendes Thema, egal mit welcher Sprache oder auf welcher Plattform Sie arbeiten. Es ist der einzige Bereich der Softwareentwicklung, in dem Fachleute ihre Computer treten, anbrüllen oder sogar wegwerfen. Für eine sonst eher zurückhaltende, introvertierte Gruppe sind diese Gefühlsausbrüche außergewöhnlich. Im Rahmen der Softwareentwicklung ist Debugging auch berühmt dafür, dass Sie Nacht- schichten einlegen müssen. Ich bin noch keinem Techniker begegnet, der zu Hause angerufen hätte: »Lieb- ling, ich kann heute nicht pünktlich kommen, weil wir mit unseren UML-Diagrammen so viel Spaß haben, dass wir gleich die Nacht durchmachen wollen!« Allerdings sind mir schon zig Techniker begegnet, die ihren Partner wehleidig informiert haben: »Liebling, ich kann nicht nach Hause kommen, weil wir mit einem Mordsding von Bug zu kämpfen haben.« Bugs und Debugging Bugs sind toll! Sie zwingen uns, den Dingen auf den Grund zu gehen und die Funktionsweise zu verstehen. Wie sind alle zu diesem Geschäft gekommen, weil wir gerne lernen – und Bugs aufspüren ist die ultimative Lernerfahrung. Ich weiß nicht, wie oft ich schon fast sämtliche Programmierbücher in meinem Büro ausge- breitet habe, um einen guten Bug zu suchen. Es fühlt sich einfach großartig an, diese Bugs zu finden und zu beseitigen! Am besten sind natürlich die Bugs, die Sie finden, bevor die Kunden Ihr Produkt in die Hände bekommen. Also müssen Sie Ihren Job beherrschen, um diese Bugs zu finden, bevor Ihre Kunden es tun. Es ist unverantwortlich, den Kunden die Suche nach Bugs zu überlassen. Verglichen mit anderen Ingenieurdisziplinen nimmt die Softwaretechnik in zweierlei Hinsicht eine Sonder- stellung ein. Erstens ist Softwaretechnik ein neuer und gewissermaßen unreifer Zweig der Technik vergli- chen mit traditionellen Zweigen wie zum Beispiel Hochbau oder Elektrotechnik. Zweitens haben sich Benutzer mit fehlerhaften Produkten abgefunden, was besonders auf PC-Software zutrifft. Interessanterwei- se würden dieselben Kunden in einem Kernreaktor oder in einem medizinischen Gerät keinen Konstrukti- onsfehler dulden. Und da PC-Software den Alltag immer mehr durchdringt, ist die Sorglosigkeit, die sich die Softwarebranche früher leisten konnte, nahezu passé. Zweifellos werden die Produkthaftungsgesetze, die schon längere Zeit für andere Ingenieurdisziplinen gelten, schließlich auch die Softwaretechnik einschlie- ßen. Um Bugs müssen Sie sich schon deshalb Gedanken machen, weil sie letztlich für Ihr Unternehmen teuer sind. Kurzfristig gesehen ist es die Hilfe, die Kunden von Ihnen verlangen, sodass Sie Zeit und Geld aufwen- den müssen, um die aktuelle Produktversion zu stützen, während Ihre Konkurrenten schon an ihren nächs- ten Versionen arbeiten. Langfristig gesehen wirkt die unsichtbare Hand der Ökonomie und Kunden gehen dazu über, Alternativen zu Ihrem fehlerhaften Produkt zu kaufen. Software ist heutzutage mehr eine Dienst- leistung als eine Kapitalinvestition, sodass der Ruf nach qualitativ besserer Software immer eindringlicher wird. Mit jeder Anwendung, die XML (Extensible Markup Language) für Ein- und Ausgabe unterstützt, können Ihre Benutzer zwischen Softwareprodukten von verschiedenen Anbietern wechseln, indem sie einfach von einer Website zu einer anderen gehen. Diese Freiheit für Benutzer bedeutet weniger Sicherheit für die Jobs von Softwareentwicklern, d. h. für Sie und mich, wenn unsere Produkte fehlerhaft sind und förmlich danach schreien, verbessert zu werden. Lassen Sie mich das anders ausdrücken: Je fehlerhafter Ihr Produkt, desto wahrscheinlicher ist es, dass Sie sich nach einem neuen Job umsehen müssen. Und wenn es etwas gibt, was Techniker hassen, dann die Jagd nach einem neuen Job. John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
Was sind Bugs? 5 Was sind Bugs? Bevor Sie mit dem Debuggen beginnen können, brauchen Sie eine Definition für »Bugs«. Meiner Definition nach ist ein Bug »alles, was einen Benutzer verdrießt«. Ich klassifiziere Bugs in die folgenden Kategorien: Abstürze und Hänger Schlechte Leistung und Skalierbarkeit Falsche Ergebnisse Ausnutzen von Sicherheitsrisiken Inkonsistente Benutzeroberflächen Nicht erfüllte Erwartungen Abstürze und Hänger Abstürze (Crashes) und Hänger (Hangs) sind das, was sich die meisten Entwickler und Benutzer unter einem Bug vorstellen. Andere Arten von Bugs, die ich hier beschreiben werde, können Benutzer gegebenen- falls umgehen, doch offensichtlich vereiteln Abstürze und Hänger dies. Deshalb konzentriert sich der größere Teil dieses Buchs auf die Lösung dieser extremen Probleme und die Suche nach Wegen, um sie durch Testen aus dem Code zu verbannen. Wie wir alle wissen, sind manche dieser Bugs leicht zu lösen, bei anderen ist das dagegen fast unmöglich. Bei Bugs, die zu Abstürzen und Hängern führen, ist vor allem zu beachten, dass Sie niemals ein Produkt ausliefern sollten, wenn Sie wissen, dass es einen dieser Bugs enthält. Der eine oder andere mag einwenden, dass Sie das Produkt mit diesem unwahrscheinlichen Absturz- oder Hängerproblem ausliefern können, doch wenn Sie davon wissen und es reproduzieren können, müssen Sie den Fehler beseitigen, selbst wenn er schwer zu reproduzieren ist. Erfreulicherweise nimmt uns Microsoft .NET viele dieser hässlichen und bizarren Absturzprobleme ab, über denen wir unzählige Nachtstunden gesessen haben, um sie aufzuspüren, als wir nativen Code entwickelt haben. Wenn Sie natürlich systemeigene Komponenten in Ihrer Anwendung einsetzen, besitzen diese trotzdem die Kraft, jederzeit in die Interna der CLR (Common Language Runtime) hineinzureichen und dort Unruhe zu stiften, sodass wir immer noch nicht frei von Abstürzen sind. In der .NET-Welt sind unbehandelte Ausnahmen der Fluch des Endbenutzerdaseins. Mit der wundervollen Exception-Klasse als Wurzel aller Fehler haben wir eine klare Linie, um die Ursache des Problems herauszu- finden. Und mit etwas Code, den ich später im Buch vorstelle, können Sie leicht ein superintelligentes Fehlermeldesystem in der Art des Windows Error Reporting-Tools von Microsoft erstellen, das beispielhaft zur Verbesserung von Microsoft Windows und Microsoft Office beigetragen hat. Schlechte Leistung und Skalierbarkeit Benutzer werden frustriert durch Bugs, die die Anwendung bremsen, wenn sie mit realen Daten konfron- tiert wird. Stets ist ungeeignetes Testen die Wurzel aller Bugs in Bezug auf schlechte Leistung –so großartig die Anwendung auch in der Entwicklung ausgesehen haben mag, das Team hat es versäumt, sie mit allem zu testen, was praxisnahen Inhalten oder Szenarios nahe kommt. Vor Jahren habe ich am Projekt BoundsChe- cker 3.0 von NuMega gearbeitet, bei dem ein derartiger Fehler in der ursprünglichen FinalCheck-Tech- John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
6 Kapitel 1: Bugs: Woher sie kommen und wie man sie beseitigt nologie schlummerte. Diese Version von FinalCheck hatte zusätzliche Debugging- und kontextuelle Infor- mationen direkt in den Quellcode eingebaut, damit BoundsChecker Fehler besser melden konnte. Leider hatten wir den FinalCheck-Code nicht genügend auf größeren realen Anwendungen getestet, bevor Bound- sChecker 3.0 veröffentlicht wurde. Im Ergebnis konnten nicht mehr Benutzer als vorgesehen dieses Feature nutzen. In darauf folgenden Releases haben wir das FinalCheck-Feature vollkommen neu geschrieben, doch aufgrund der Leistungsprobleme in der ursprünglichen Version haben viele Benutzer es nie wieder auspro- biert, obwohl es eines der leistungsfähigsten und nützlichsten Features des Produkts war. BoundsChecker 3.0 haben wir im Jahre 1995 herausgebracht und es ist interessant, dass Benutzer elf Jahre später – mindestens vier Äonen in Internet-Zeit – mir sagen, dass sie FinalCheck aufgrund einer schlechten Erfah- rung noch nicht wieder verwendet haben! Was die Leistung betrifft, muss von der Ebene der Projektverwaltung eine grundlegende Änderung der Denkweise ausgehen. Leistung darf niemals ein nachträglicher Einfall sein; es handelt sich um ein Feature an sich. In meiner Beratertätigkeit ist mir vor allem aufgefallen, dass kaum ein Entwickler über Leistungs- kenndaten verfügt, die er zu erfüllen hat. Derartige Kennzahlen geben klar das angepeilte Ziel vor, sodass Sie gar nicht erst in die Leistungsfalle tappen. Wenn Sie noch nicht über Leistungskenndaten verfügen, legen Sie ein Leistungsniveau am besten wie folgt fest: Machen Sie das Produkt nicht langsamer als die letzte Version. Jetzt stellt sich die Frage, wie diese Kennzahl für die aktuelle Version aussieht. Diese müssen Sie erst einmal ermitteln. Wenn Sie an einer neuen Entwicklung arbeiten, müssen Sie mit diesen Kennzahlen bereits in der Anforderungsphase beginnen. Nachdem Sie über Leistungskenndaten verfügen, müssen Sie diese auch überwachen. Verfehlt Ihre Anwen- dung die Werte um 10 oder mehr Prozent, stoppen Sie die laufenden Entwicklungsarbeiten und ermitteln die Gründe, warum die Leistung gefallen ist. Daraus leiten Sie dann Schritte zur Korrektur des Problems ab. Stellen Sie außerdem sicher, dass Sie Anwendungen gegen Szenarios testen, die so praxisnah wie möglich sind – und tun Sie dies möglichst frühzeitig im Entwicklungszyklus. Entwickler stellen mir regelmäßig folgende Frage: »Wo bekomme ich diese Praxisdaten her, damit ich Leistungstests durchführen kann?« Die Antwort lautet: »Sprechen Sie mit Ihren Kunden.« Es schadet niemals, die Kunden um deren Datensätze zu bitten, damit Sie Tests durchführen können. Hat ein Kunde Bedenken hinsichtlich der Vertraulichkeit, schreiben Sie ein Programm, das vertrauliche Daten verschleiert. Der Kunde kann dieses Programm ausführen und sich davon überzeugen, dass vertrauliche Informationen ausreichend unkenntlich gemacht sind, sodass der Kunde Ihnen die Daten bedenkenlos übergeben kann. Eine Bekannte erzählte mir eine Geschichte über ihre Arbeit für eine Firma, die Anwendungen für private Finanzdienstleister ausführte. Als die Mitarbeiter des Entwicklungsteams den Hauptkunden um einige Praxisdaten zum Testen gebeten hatten, erlitten sie fast einen Schock. Die Daten waren vollkommen echt und unverschleiert! Anfangs hatte sie mit dem Gedanken gespielt, alle Männer unter 30 Jahren mit einem Einkommen über $10 Millionen herauszusuchen. Doch sie löschte sofort alle Instanzen der Daten und bat den Kunden um verschleierte Daten. Die Leser dieses Buchs dürfte das wohl nicht schockieren, doch in der modernen Welt von .NET können Leistungsprobleme einen großen Teil Ihrer Debugging-Herausforderungen ausmachen. Zwar nimmt uns .NET schon recht viele der lästigen Entwicklungsherausforderungen ab, mit denen wir in den Tagen der nativen C++-Entwicklung zu kämpfen hatten. Doch hat diese Einfachheit den Preis, dass es schwerer ist, in die »Blackbox« der CLR (Common Language Runtime) selbst zu schauen. John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
Was sind Bugs? 7 Falsche Ergebnisse Dieser Fehlertyp ist sehr subtil und möglicherweise heimtückisch. Wenn Sie an einer Anwendung für eine Bank arbeiten, kann eine falsche Berechnung mitten in einer riesigen Datenmenge eine sich allmählich ausbreitende Wirkung zeigen, die zwar die Daten korrekt aussehen lässt, aber die Bank erheblich Geld kostet. Obwohl wir Debugger und Leistungsmonitore haben, um Abstürze und Datenbeschädigungen zu verfolgen, gibt es kaum geeignete Tools, um Probleme bei falschen Ergebnissen zu erkennen. Hier müssen Sie selbst Code schreiben, der die Ergebnisse überprüft. Ein perfektes Beispiel für die Doppelprüfung aller Ergebnisse ist das Neuberechnungsmodul von Microsoft Office Excel. In Debugbuilds verrichtet das normale, hochgradig optimierte Berechnungsmodul seine Arbeit, und nachdem es fertig ist, überprüft ein zweites Modul, das nur in der Debugversion aktiv ist, ob alle Werte des ersten Moduls korrekt sind. Diesen Testcode brauchen Sie, weil die Alternative darin besteht, alle Ausgaben Ihres Codes manuell zu testen. Wenn Sie geglaubt haben, dass es umständlich wäre, derartigen Code zu schreiben, verbringen Sie einfach einige Wochen damit, die Daten per Hand nachzurechnen! Ausnutzen von Sicherheitsrisiken Heutzutage können Sie sich kaum die Nachrichten ansehen, ohne wieder von einer Geschichte zu erfahren, dass Daten gestohlen wurden oder ein Sicherheitsloch in der Website irgendeiner Firma aufgetaucht ist. Jeder in einem Unternehmen – vom Empfang bis zum CEO – ist auf Sicherheit bedacht. Unabhängig davon, wie großartig Ihre Anwendung läuft oder aussieht, ein einziger SQL-Injection-Angriff kann Sie in fünfzehn Sekunden vom Helden zum Verlierer befördern. Genau wie Leistung und Skalierbarkeit darf Sicherheit kein nachträglicher Einfall sein. Sicherheit ist als vollwertiges Feature gleich von der Anforderungsphase an einzubinden. Im Team brauchen Sie jemanden, der für die Sicherheit des Produkts verantwortlich ist. Machen Sie aber nicht den Fehler, willkürlich jeman- dem die Funktion des Sicherheitsbeauftragten für das Projekt zusätzlich zu seinen Aufgaben aufzudrücken. Diese Rolle muss die Zeit haben, Sicherheitstests und Bedrohungsmodelle für das Projekt als Ganzes zu modellieren. Wie Michael Howard und David LeBlanc im schöpferischen Writing Secure Code (Microsoft Press, 2. Auflage, 2003), sagen: »Sicherheitsprodukte sind Qualitätsprodukte.« Inkonsistente Benutzeroberflächen Inkonsistente Benutzeroberflächen sind zwar nicht der gravierendste Fehlertyp, aber störend. Der Erfolg des Windows-Betriebssystems hat unter anderem damit zu tun, dass sich alle Windows-basierten Anwendungen allgemein in der gleichen Weise verhalten. Wenn eine Anwendung vom Windows-Standard abweicht, wird sie zu einer Last für den Benutzer. Ein hervorragendes Beispiel für dieses nicht standardgerechte, verdrießli- che Verhalten sind die Tastenkombinationen für die Suchen-Befehle in Microsoft Office Outlook. In jeder anderen englischsprachigen Windows-basierten Anwendung auf dem Planeten gelangen Sie mit (Strg)(F) zum Dialogfeld Suchen (engl. Find), sodass Sie Text im aktuellen Fenster suchen können. In Office Outlook dagegen wird mit (Strg)(F) die geöffnete Nachricht weitergeleitet, was in meinen Augen ein Bug ist. Selbst nach den vielen Jahren, in denen ich Outlook einsetze, kann ich mich nicht daran gewöhnen, die Taste (F4) zu drücken, um Text in der momentan geöffneten Nachricht zu suchen. Vielleicht entschließt sich Micro- soft, dieses eklatante Problem irgendwann zu beseitigen, wenn wir hartnäckig Berichte zu falschen Tasten- kombinationen liefern. John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
8 Kapitel 1: Bugs: Woher sie kommen und wie man sie beseitigt Mit Clientanwendungen ist es einfach, Probleme mit inkonsistenten Benutzeroberflächen zu lösen, indem man den Empfehlungen in den Windows Vista User Experience Guidelines folgt, die unter http://msdn.microsoft.com/windowsvista/building/ux/default.aspx verfügbar sind. Wenn dieses Buch auf einen bestimmten Punkt nicht eingeht, suchen Sie nach einer anderen Microsoft-Anwendung, die ein vergleichbares Element realisiert, und folgen sie ihrem Modell. Microsoft besitzt scheinbar unbegrenzte Ressourcen und unbegrenzte Zeit. Profitieren Sie also von den Forschungsergebnissen dieser Firma – Konsistenzprobleme können Sie dadurch viel kostengünstiger lösen. Wenn Sie an Webfrontends arbeiten, ist das wesentlich schwieriger, weil es keinen Standard für die Anzeige einer Benutzeroberfläche gibt. Wie wir alle aus der Benutzerperspektive erfahren haben, ist es wesentlich schwieriger, eine gute Benutzeroberfläche (User Interface, UI) in einem Webbrowser zu bekommen. Für die Entwicklung starker Webclient-UIs kann ich zwei Bücher empfehlen. Das erste ist die Standardbibel zum Webdesign Designing Web Usability: The Practice of Simplicity (New Riders Press, 2000) von Jacob Nielsen. Das zweite ist ein herausragendes kleines Buch, dass Sie jedem selbst ernannten Usability-Experten in Ihrem Team geben sollten, der keinen blassen Schimmer vom Thema hat (wie zum Beispiel einem Geschäftsführer, der die Benutzeroberfläche bestimmen möchte, aber nie einen Computer verwendet hat): Don’t Make Me Think! A Common Sense Approach to Web Usability (New Riders Press, 2000) von Steve Krug. Was Sie auch für Ihre Web-UI tun, denken Sie daran, dass nicht alle Ihre Benutzer über 100-MB/s-Pipes für ihre Browser verfügen. Halten Sie also Ihre Benutzeroberfläche einfach und vermeiden Sie überflüssigen Schnickschnack, der lange Downloadzeiten mit sich bringt. Bei der Untersuchung großer Webclients hat User Interface Engineering (www.uie.com) herausgefunden, dass Konzepte wie zum Beispiel die Benutzeroberfläche auf CNN.com für alle Benutzer am besten geeignet sind. Durch einen einfachen Satz von deutlich abgesetzten Links mit Informationsgruppen unter klar erkennbaren Abschnitten ist es dem Benutzer wesentlich einfa- cher als bei allen anderen Oberflächen möglich, das zu finden, was er sucht. Ein ausgezeichneter Weg, um das Testen von Usability zu behandeln, stammt von Joel Spolskey, bei dessen Blog sich alle Softwareentwickler unbedingt anmelden sollten. In seinem Eintrag »The Joel Test: 12 Steps to Better Code« (http://www.joelonsoftware.com/articles/fog0000000043.html) lautet sein Schritt 12 »Do you do hallway usability testing?« Der Gedanke ist, fünf Leute herauszugreifen, die auf dem Gang herumlaufen, und sie zu zwingen, den Code zu verwenden, den Sie gerade geschrieben haben. Gemäß Joel finden Sie dabei 95 Prozent Ihrer Usability-Probleme sofort. Nicht erfüllte Erwartungen Am schwersten lassen sich Fehler auflösen, die dazu führen, dass die Erwartungen der Benutzer nicht erfüllt werden. Die Wurzeln dieser Fehler liegen gewöhnlich unmittelbar am Beginn eines Projekts, wenn die Firma nicht genügend Untersuchungen durchgeführt hat, wie die Bedürfnisse des Kunden tatsächlich aussehen. Unabhängig davon, ob kommerzielle Software für den Verkauf oder betriebsinterne Software geschrieben wird – Ursache dieses Fehlers ist ein Kommunikationsproblem. Im Allgemeinen kommunizieren Entwicklungsteams nicht direkt mit den Kunden ihrer Produkte, sodass sie nicht erfahren, was die Benutzer brauchen. Im Idealfall sollten alle Mitglieder des Technikteams die Kunden vor Ort besuchen, damit sie sich ein Bild davon machen können, wie sie Ihr Produkt einsetzen. Dies kann eine Erfahrung sein, die Ihnen die Augen öffnet. Zusätzlich bekommen Sie dadurch den Einblick, den Sie brauchen, um richtig zu interpretieren, was Kunden Ihrem Produkt abverlangen. Dabei sollten Sie mit möglichst vielen Kunden sprechen, sodass Sie Eingaben über ein breites Spektrum erhalten können. In der John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
Was sind Bugs? 9 Tat empfehle ich dringend, dass Sie fürs Erste mit Lesen aufhören und sich an die Planung eines Kunden- treffens machen. Ich kann es nicht oft genug betonen: Je mehr Sie mit den Kunden sprechen, desto bessere Ingenieure werden Sie sein. Zusätzlich zu den Kundenbesuchen ist es auch empfehlenswert, das Technikteam die Zusammenfassungen der Support-Anrufe und -E-Mail-Nachrichten studieren zu lassen. Anhand der Rückmeldungen sieht das Technikteam die Probleme der Benutzer in ungefilterter Form. Neben den Tools, die Ihnen beim Diagnosti- zieren von Problemen helfen, können diese Inspektionen zu allen Arten von interessanten Ideen führen. Ein anderer Aspekt dieser Fehlerart ist die Situation, in der das Erwartungsniveau des Benutzers höher angehoben wurde als es vom Produkt realisiert werden kann. Diese Inflation von Benutzererwartungen ist das klassische Ergebnis von zu viel Euphorie und Sie müssen mit allen Mitteln verhindern, dass die Mög- lichkeiten Ihres Produkts falsch dargestellt werden. Wenn Benutzer nicht das bekommen, was sie von einem Produkt erwarten, neigen sie dazu, dass Produkt als noch fehlerhafter zu betrachten, als es wirklich ist. Versprechen Sie niemals, was Sie nicht liefern können, und liefern Sie immer das, was Sie versprochen haben. Prozessfehler und Lösungen Obwohl die Auslieferung von fehlerfreier Software theoretisch möglich ist – vorausgesetzt, Sie achten genügend auf jedes Detail und besitzen fast unendlich viel Zeit – habe ich schon zu viele Produkte ausgelie- fert, um zu wissen, dass die meisten Firmen vom Markt verschwunden wären, wenn sie dies versucht hätten. Bugs gehören in diesem Geschäft zum Leben dazu, selbst an Stellen wie dem NASA (National Aeronautics and Space Administration) Software Engineering Laboratory, das als der fehlerfreieste Entwicklungsshop in der Welt gilt. Allerdings können Sie die Anzahl der Bugs in Ihrer Anwendung minimieren. Das ist das, was Teams tun, die hochqualitative Produkte ausliefern – und davon gibt es recht viele auf dem Markt. Die Gründe für Bugs lassen sich allgemein in die folgenden Prozesskategorien gliedern: Knappe oder unmögliche Deadlines Der Ansatz »Erst kodieren, dann denken« Falsch verstandene Anforderungen Unkenntnis der Technik oder falsche Ausbildung Fehlende Qualitätsverpflichtungen Knappe oder unmögliche Deadlines Wir haben alle in Entwicklungsteams gearbeitet, für die das »Management« eine Deadline festgelegt hat, die es entweder von einem Tarot-Kartenleser bezogen hat oder, wenn das zu teuer war, durch das Werfen eines Dartpfeils auf einen Kalender. Obwohl wir daran glauben möchten, dass Manager für die meisten unrealisti- schen Zeitpläne verantwortlich sind, ist es meistens so, dass sie nicht zu tadeln sind. Die von den Ingenieu- ren abgegebenen Aufwandseinschätzungen bilden in der Regel die Basis des Zeitplans und manchmal unterschätzen Techniker, wie lange sie brauchen, um ein solides Produkt zu entwickeln. Techniker sind eine eigene Spezies. Sie sind introvertierte, doch fast immer sehr positiv denkende Menschen. Für eine gegebene Aufgabe sind sie im Innersten davon überzeugt, dass sie den Computer dazu bringen können, aufzustehen und zu tanzen. Kommt ihr Manager zu ihnen und sagt, dass sie eine XML-Transformation in die Anwen- John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
10 Kapitel 1: Bugs: Woher sie kommen und wie man sie beseitigt dung einbauen müssen, sagt der durchschnittliche Ingenieur: »Klar Chef! Das dauert nur drei Tage.« Natür- lich weiß dieser Techniker nicht einmal, wie man »XML« schreibt, aber er weiß, dass es drei Tage dauert. Das große Problem dabei ist, dass Ingenieure und Manager die notwendige Einarbeitungszeit, um das Feature umzusetzen, nicht in Betracht ziehen. Im Abschnitt »Zeit für das Erstellen von Debugging-Systemen planen« in Kapitel 2 gehe ich auf einige Regeln ein, die Sie bei der Zeitplanung berücksichtigen sollten. Ob ein unrealistischer Liefertermin der Fehler der Verwaltung und/oder der Technik ist – unterm Strich führt ein unmöglich zu erfüllender Zeitplan dazu, dass viele Schritte gekürzt werden und ein qualitativ schlechte- res Produkt herauskommt. Ich bin in der glücklichen Lage gewesen, in mehreren Teams zu arbeiten, die Software rechtzeitig ausgelie- fert haben. In jedem Fall hat das Entwicklungsteam den Zeitplan wirklich in Besitz genommen und wir waren gut darin, realistische Liefertermine zu ermitteln. Dazu haben wir unsere Termine auf eine Feature- menge gestützt. Wenn die Firma erkannt hat, dass der vorgeschlagene Liefertermin nicht akzeptabel war, haben wir Features weggelassen, um dem Termin zu entsprechen. Außerdem hat sich jeder im Entwick- lungsteam mit dem Zeitplan einverstanden erklärt, bevor wir ihn der Verwaltung präsentiert haben. Somit stand die Glaubwürdigkeit des Teams mit der rechtzeitigen Fertigstellung des Produkts auf dem Spiel. Interessanterweise wurden diese Produkte nicht nur rechtzeitig ausgeliefert, sondern gehörten auch zu den Produkten mit der höchsten Qualität. Der Ansatz »Erst kodieren, dann denken« Mein Freund Peter Ierardi hat den Begriff geprägt »Erst kodieren, dann denken« (Code First, Think Later – CFTL), um die allzu bekannte Situation zu beschreiben, in der ein Softwareteam mit der Programmierung beginnt, bevor überhaupt darüber nachgedacht wurde. Jeder von uns ist an diesem Konzept in gewissem Maße schuldig. Uns macht es Spaß, mit Compilern zu hantieren, Code zu schreiben und zu debuggen. In erster Linie deshalb sind wir an diesem Geschäft interessiert. Nur wenige von uns setzen sich hin und verfassen Dokumente mit UML-Diagrammen, die beschreiben, was wir eigentlich vorhaben. Wenn Sie diese Dokumente jedoch nicht schreiben, kommt es zu Fehlern. Anstatt zu stoppen und darüber nachzudenken, wie sich Bugs von vornherein vermeiden lassen, beginnen Sie den Code anzupassen, wäh- rend Sie weiterarbeiten, um die Bugs zu umgehen. Man kann sich vorstellen, dass diese Taktik das Problem verschlimmert, weil Sie immer mehr Bugs in eine bereits instabile Codebasis einschleusen. Die Firma, für die ich arbeite, ist weltweit tätig, um dabei zu helfen, die hartnäckigsten Probleme zu debuggen, mit denen Entwickler zu tun haben. Leider werden wir oft gerufen, um verfahrene Situationen oder Leistungsprobleme zu lösen, und es gibt nichts, was wir tun können, weil die Probleme grundsätzlich bei der Architektur liegen. Wenn wir die Probleme an die Verwaltung herantragen, die uns angeheuert hat, und erwähnen, dass die Beseitigung der Probleme ein teilweises Neuschreiben verlangt, hören wir manchmal: »Wir haben zu viel in diese Codebasis investiert, um sie jetzt zu ändern.« Das ist ein sicheres Merkmal für eine Firma, die in die Kategorie »Erst kodieren, dann denken« fällt. Im Bericht über einen Kundenbesuch geben wir dann einfach »CFTL« als Grund an, warum wir nicht erfolgreich helfen konnten. Erfreulicherweise ist die Lösung für dieses Problem einfach: Planen Sie Ihre Projekte. Über das Erfassen von Anforderungen und die Projektplanung sind mehrere gute Bücher geschrieben worden. Auch wenn der Softwaretechniker im Allgemeinen eine andere Vorstellung von sinnvoller Arbeitszeit besitzt, ist die Voraus- planung lebenswichtig, um Bugs zu eliminieren. John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
Was sind Bugs? 11 Leser früherer Ausgaben dieses Buchs haben sich vor allem darüber beschwert, dass ich empfohlen habe, die Projekte zu planen, aber nicht gesagt habe, wie das geschehen soll. Die Beschwerde ist durchaus angebracht und ich möchte mich diesem Thema auch stellen. Das einzige Problem ist, dass ich eigentlich nicht weiß wie, weil ich zweifellos kein Projektverwaltungsguru bin. Vielleicht fragen Sie sich jetzt, ob ich die schlechte Angewohnheit eines Autors zeige und Ihnen dies als sprichwörtliche Übung für den Leser überlasse. Lesen Sie weiter und ich sage Ihnen, welche Planungstaktiken für mich als Ingenieur und Manager an vorderster Front funktioniert haben. Auch wenn Sie andere Bücher und Artikel zur Projektverwaltung lesen müssen, hoffe ich zumindest, dass meine Taktiken Ihnen einige Ideen vermitteln, wie Sie die Herausforderungen meistern, denen wir uns alle als Ingenieure bei der Softwareplanung gegenübersehen. Wenn Sie meinen Lebenslauf am Ende des Buchs lesen, wird Ihnen auffallen, dass ich erst mit Ende 20 in das Softwaregeschäft eingestiegen bin und dass es eigentlich meine zweite Karriere ist. In meiner ersten Laufbahn bin ich aus Flugzeugen gesprungen und habe Feinde gejagt, da ich Fallschirmjäger und Green Beret in der US-Army war. Wenn das keine Vorbereitung auf das Softwaregeschäft ist, weiß ich nicht, was es dann sein soll! Wenn Sie mich jetzt treffen, sehen Sie nur einen kleinen dicken Mann mit einem blassgrünen Leuchten – das Resultat ausgedehnter Sitzungen vor einem Monitor. Allerdings bin ich immer ein Mensch geblieben. Wirklich! Mein Job als Green Beret hat mich gelehrt, wie zu planen ist. Wenn Sie eine Spezialoperation vorhaben und die Chancen ziemlich hoch stehen, dass Sie sterben könnten, sind Sie extrem motiviert, bestmöglich zu planen. Bei der Planung einer dieser Operationen hat die Armee die ganze Gruppe in Isolation gesteckt. In Fort Bragg, North Carolina, dem Stützpunkt der Special Forces, gibt es besondere Gebiete, wo sie das Team wegsperren, um die Mission zu planen. Der gesamte Schlüssel während der Planung wurde »what if-ing yourself to death« (etwa: Planspiele mit einkalkulierter Todesfolge) genannt. Wir setzten uns zusammen und dachten über Szenarios nach. Was passiert, wenn wir abspringen mussten und den Punkt erreichen, an dem es kein Zurück mehr gibt, und die Air Force nicht den Absetzpunkt finden kann? Was passiert, wenn Unfälle auftreten, bevor wir springen? Was passiert, wenn wir am Boden ankommen und den Guerillakommandan- ten nicht finden können, auf den wir treffen sollen? Was passiert, wenn der Guerillakommandant, auf den wir treffen sollen, mehr Leute mit sich führt, als angenommen? Was passiert, wenn wir in einen Hinterhalt gelockt werden? Wir haben unaufhörlich über diese Fragen nachgedacht und Antworten darauf entwickelt, bevor wir überhaupt aus der Isolation entlassen wurden. Die Idee war, alle Eventualitäten einzuplanen, damit nichts dem Zufall überlassen bleibt. Vertrauen Sie mir: Wenn die Chance besteht, dass Sie bei der Ausübung Ihres Jobs sterben könnten, wollen Sie alle variablen Faktoren wissen und sie berücksichtigen. Ich erzähle Ihnen diese Geschichte, um die Wahrheit der Aussage zu veranschaulichen, die ich vor langer Zeit in der Armee gehört habe: Pläne sind wertlos, aber Planen ist alles. Wir haben so hart daran gearbeitet, das Problem aus jedem nur denkbaren Winkel zu betrachten, dass wir in der Lage waren, uns schnell anzupas- sen, wenn etwas Unerwartetes passiert. Bei meinem Einstieg ins Softwaregeschäft war ich an diese Art Planung gewöhnt. Als ich das erste Mal in einem Meeting saß und sagte: »Was passiert, wenn Bob stirbt, bevor wir die Anforderungsphase abgeschlos- sen haben?« wurde jeder ziemlich nervös, sodass ich jetzt Fragen mit einem weniger morbiden Anstrich stelle, in der Art wie: »Was passiert, wenn Bob in der Lotterie gewinnt und reich aus dem Team ausscheidet, bevor wir die Anforderungsphase abgeschlossen haben?« Der Grundgedanke ist allerdings der gleiche. Suchen Sie alle zweifelhaften und unklaren Bereiche in Ihren Plänen und gehen Sie sie an. Es ist kein leich- tes Unterfangen und wird schwächere Ingenieure verrückt machen, doch die Kernfragen werden immer auftauchen, wenn Sie nur tief genug eindringen. Zum Beispiel stellen Sie in der Anforderungsphase Fragen wie: »Wie sieht es aus, wenn unsere Anforderungen nicht das sind, was der Benutzer möchte?« Derartige John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
12 Kapitel 1: Bugs: Woher sie kommen und wie man sie beseitigt Fragen verlangen von Ihnen Zeit und Geld, um herauszufinden, ob Sie diese Anforderungen wirklich klären müssen. In der Entwurfsphase stellen Sie Fragen wie: »Was ist, wenn unsere Leistung nicht gut genug ist?« Derartige Fragen erinnern Sie daran, dass Sie sich über Ihre Leistungsziele klar werden müssen und mit der Planung beginnen, wie Sie diese Ziele erreichen, indem Sie in Praxisszenarios testen. Planung ist wesentlich einfacher, wenn Sie alle Punkte auf den Tisch bringen können. Seien Sie dankbar, dass Ihr Leben nicht von der rechtzeitigen Auslieferung der Software abhängt! Wenn Sie schon einmal etwas über Risikoanalyse gelesen haben, dürfte Ihnen der »Was wäre wenn«-Ansatz bekannt vorkommen, weil die Risikoanalyse für meinen »Was wäre wenn«-Ansatz Pate gestanden hat. In der Risikoanalyse versuchen Sie, alle Einflussfaktoren zu finden, und vor allem, diese Risiken einzuschätzen, damit Sie die Wahrscheinlichkeit ermitteln können, dass diese Probleme auf Sie zurückfallen und Ihnen schaden. Indem Sie die Probleme aufdecken, die Sie am meisten kosten oder die höchste Wahrscheinlichkeit haben, können Sie sie anpacken, bevor sie Ihnen Ärger bereiten. Jedes Projekt besitzt seine eigenen einzigar- tigen Risikofaktoren, doch solange Sie keine Vorstellung davon haben, wie sie konkret aussehen, kommen Sie mit Ihren Aufgaben niemals zurecht. Geschichten von der Debugging-Front – Akutes »Erst kodieren, dann denken« (CFTL) Die Schlacht Ein Kunde rief uns an, weil er ein großes Leistungsproblem hatte und sich der Auslieferungstermin be- drohlich näherte. Wenn wir uns derartigen Notproblemen widmen, fragen wir als Erstes nach einem 15- minütigen Architekturüberblick, sodass wir uns schneller auf die Terminologie einschießen und eine Vorstellung davon bekommen können, wie das Projekt zusammenspielt. Der Kunde holte einen der Archi- tekten herbei und der begann die Erläuterung auf dem Whiteboard. Normalerweise dauern diese Kreis-und-Pfeil-Sitzungen etwa 10 bis 15 Minuten. Allerdings war dieser Architekt 45 Minuten später immer noch gut in Form und ich wurde zunehmend verwirrt, weil ich eher eine Roadmap brauchte, um folgen zu können. Schließlich gab ich zu, dass ich vollkommen den Faden verloren hatte und bat erneut nach dem 10-minütigen Systemüberblick. Ich musste nicht alles wissen, sondern brauchte lediglich die Höhepunkte. Der Architekt begann noch einmal und in 15 Minuten hatte er gerade einmal 25 Prozent im System zurückgelegt! Das Ergebnis Es handelte sich um ein großes COM-System und ich begann zu begreifen, worin das Leistungsproblem lag. Offensichtlich hatte irgendein Architekt im Team eine Vorliebe zu COM entwickelt. Er nippte nicht einfach an einem Glas mit COM-Essenz; er prasste in vollen Zügen aus dem 55-Gallonen Fass von COM. Wie sich später zeigte, hätte das System etwa 8 bis 10 Hauptobjekte benötigt – dieses Team hatte es auf über 80 gebracht! Um zu verstehen, wie überzogen dies war, brauchen Sie sich nur vorzustellen, dass jedes Zeichen in einer Zeichenfolge als COM-Objekt repräsentiert wird. Dieses System war einfach überzüchtet und vollkommen unzureichend durchdacht. Es verkörperte den klassischen Fall, in dem die Architekten keinerlei praktische Erfahrung haben. Nach etwa einem halben Tag nahm ich schließlich den Manager beiseite und sagte ihm, dass wir in Bezug auf die Leistung nicht viel tun könnten, da der Overhead von COM selbst das Problem war. Er war nicht gerade erfreut, dies zu hören, und platzte sofort mit dieser berüchtigten Phrase heraus: »Wir haben zu viel in diesen Code investiert, um ihn jetzt zu ändern!« Leider konnten wir mit der vorhandenen Architektur nichts anfangen, um einen Leistungsschub zu bewirken. John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
Was sind Bugs? 13 Die Lektion Dieses Projekt litt von Anfang an unter mehreren entscheidenden Problemen. Erstens hatten die Team- mitglieder das vollständige Projekt in die Hände von Nicht-Programmierern gegeben. Zweitens hatten sie sofort mit der Kodierung begonnen, als der Plan von oben kam. Es wurde absolut kein Gedanke mehr daran verschwendet, als dieses Ding zu kodieren und es sofort zu tun. Es war das klassische Problem »Erst kodieren, später denken«, dem ein »Nicht durchdachter Entwurf« vorausging. Ich kann es nicht oft genug betonen: Sie müssen realistische Technologieeinschätzungen treffen und Ihre Entwicklung planen, bevor Sie den Computer überhaupt einschalten. Falsch verstandene Anforderungen Geeignete Planung minimiert auch eine der größten Fehlerursachen in der Entwicklung: das Einschleichen von Features. Das Einschleichen von Features – das Festhalten an Features, die ursprünglich nicht geplant waren – ist ein Symptom schlechter Planung und mangelhafter Anforderungserfassung. Das Hinzufügen von Last-Minute-Features, ob als Reaktion auf Wettbewerbsdruck, als Lieblingsfeature eines Entwicklers oder aus der Laune des Managements heraus, verursacht mehr Bugs in der Software als alles andere. Softwaretechnik ist eine äußerst detailorientierte Angelegenheit. Je mehr Details Sie ausarbeiten und auflö- sen, bevor Sie mit der Kodierung beginnen, desto weniger gelingt Ihnen. Die richtige Detailgenauigkeit erreichen Sie nur dadurch, dass Sie die Eckpunkte und die Implementierung für Ihre Projekte planen. Natürlich bedeutet das nicht, dass Sie über die Stränge schlagen und Tausende Seiten Dokumentation generieren müssen, die Ihre Absichten beschreiben. Eines der besten Entwurfsdokumente, die ich je für ein Produkt erstellt habe, war einfach eine Reihe von Papierzeichnungen oder Papierprototypen der Benutzeroberfläche. Basierend auf Untersuchungen und Lehrgängen von Jared Spool und seiner Firma User Interface Engineering hat mein Team die Benutzerober- fläche gezeichnet und jedes Benutzerszenario vollständig durchgearbeitet. Dabei hatten wir uns auf die Anforderungen für das Produkt zu konzentrieren und sollten genau herausfinden, wie die Benutzer an die Durchführung ihrer Aufgaben herangehen. Am Ende wussten wir ganz genau, was wir abliefern würden, und vor allem galt das für jeden Mitarbeiter in der Firma. Wenn eine Frage darüber auftauchte, was in einem gegebenen Szenario voraussichtlich passieren würde, zogen wir unsere Papierprototypen hervor und arbeiteten das Szenario erneut durch. Selbst bei sorgfältigster Planung müssen Sie die wirklichen Anforderungen Ihres Produkts verstehen, um sie in geeigneter Weise zu implementieren. Bei einer Firma, in der ich– zum Glück für weniger als ein Jahr – gearbeitet habe, schienen die Anforderungen für das Produkt sehr einfach und geradlinig zu sein. Wie sich allerdings herausstellte, hatten die meisten Teammitglieder die Bedürfnisse der Kunden nicht genügend verstanden, um herauszufinden, wofür das Produkt vorgesehen war. Die Firma machte den klassischen Fehler, mehr Ingenieure einzustellen, sie aber nicht ausreichend zu schulen. Und obwohl das Team alles bis ins Kleinste geplant hatte, wurde das Produkt erst mehrere Jahre später ausgeliefert und der Markt lehnte es ab. Bei diesem Projekt gab es zwei große Fehler. Der erste bestand darin, dass sich die Firma nicht die Zeit nehmen wollte, die Bedürfnisse der Kunden den Ingenieuren, die in diesem Problembereich neu waren, gründlich zu erklären, nicht einmal dann, als einige von uns dringend nach einer Schulung verlangten. Der zweite Fehler war, dass viele Ingenieure – sowohl alt eingesessene als auch neu eingestellte – sich nicht John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
14 Kapitel 1: Bugs: Woher sie kommen und wie man sie beseitigt darum kümmerten, mehr über den Problembereich zu lernen. Im Ergebnis änderte das Team ständig die Richtung – und zwar jedes Mal, wenn Marketing und Verkauf die Anforderungen neu erklärten. Die Code- basis war so instabil, dass es Monate dauerte, um selbst das einfachste Benutzerszenario ohne Absturz zum Laufen zu bringen. Sehr wenige Firmen schulen überhaupt ihre Ingenieure im jeweiligen Problembereich. Obwohl viele von uns Hochschulabschlüsse in technischen Berufen haben, wissen wir im Allgemeinen nicht viel darüber, wie Kunden unsere Produkte einsetzen. Wenn Firmen angemessene Zeit im Voraus damit verbringen, ihren Technikern den Problembereich näher zu bringen, könnten sie viele Bugs durch missverstandene Anforde- rungen eliminieren. Immerhin liegt der Fehler nicht nur auf der Seite der Firmen. Die Techniker müssen sich ebenfalls ver- pflichtet fühlen, sich mit dem Problembereich zu befassen. Manche Techniker denken gern, dass sie ja Tools erstellen, die eine Lösung ermöglichen, sodass sie ihre Trennung vom Problembereich aufrechterhalten können. Als Techniker sind wir für die Lösung des Problems zuständig und nicht dafür, eine Lösung ledig- lich zu ermöglichen! Beispielsweise steuern Sie nur eine Lösungsmöglichkeit bei, wenn Sie eine technisch funktionierende Benutzeroberfläche entwerfen, die aber nicht den Arbeitsabläufen des Benutzers entspricht. Ein weiteres Beispiel für das Ermöglichen einer Lösung ist das Erstellen Ihrer Anwendung in einer solchen Weise, dass sie das Problem des Benutzers auf kurze Sicht löst, aber nicht nach vorn orientiert ist, um den sich ändern- den Geschäftsanforderungen des Benutzers zu entsprechen. Wenn Sie das Problem des Benutzers lösen und nicht einfach nur eine Lösung ermöglichen wollen, müssen Sie sich – als Softwaretechniker – so sachkundig wie möglich über den Problembereich machen, damit Ihr Softwareprodukt zu einer Erweiterung für den Benutzer wird. Die besten Techniker sind nicht die, die Bits jonglieren können, sondern die, die das Problem eines Benutzers lösen können. Fachliche Unkenntnis oder ungeeignete Schulung Eine weitere signifikante Quelle von Bugs kommt von Entwicklern, die das Betriebssystem, die Sprache oder die Technologie, die ihr Projekt verwendet, nicht verstehen. Leider geben nur wenige Techniker diesen Mangel zu und bemühen sich um Schulung. Stattdessen verbergen sie ihren Wissensmangel und bringen – unabsichtlich – vermeidbare Bugs ein. Allerdings ist in vielen Fällen diese Unkenntnis nicht so sehr ein persönliches Scheitern, sondern eher Ausdruck der Realität in der modernen Softwareentwicklung. Heutzutage sind so viele Ebenen und Wech- selbeziehungen bei der Entwicklung von Software zu berücksichtigen, dass man nicht von einer einzigen Person erwarten kann, alle Winkelzüge jedes Betriebssystems, jeder Sprache und jeder Technologie zu beherrschen. Es ist kein Fehler zuzugeben, dass Sie etwas nicht wissen, und auch kein Zeichen von Schwä- che. Es wirft Sie nicht aus dem Rennen im Kampf und den Expertenthron. In einem gesunden Team wirkt die Anerkennung der Stärken und Grenzen jedes Teammitglieds zum Vorteil des Teams. Indem man die Fertigkeiten auflistet, die die Entwickler besitzen und nicht besitzen, kann das Team von ihren Schulungsin- vestitionen maximal profitieren. Indem die Schwächen jedes Entwicklers gestärkt werden, ist das Team besser in der Lage, sich an unvorhergesehene Umstände anzupassen, und erweitert im Gegenzug die Fähig- keiten des gesamten Teams. Außerdem kann das Team Entwicklungszeit genauer einkalkulieren, wenn Teammitglieder bereit sind zuzugeben, was sie nicht wissen. So können Sie Zeit für Schulungen einrichten und einen realistischeren Zeitplan erstellen. John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
Was sind Bugs? 15 Eine Technologie lässt sich am besten erlernen, wenn man aktiv mit ihr arbeitet. Als NuMega mich vor Jahren losschickte, um Microsoft Visual Basic zu lernen, damit wir Produkte für Visual Basic-Entwickler schreiben konnten, erstellte ich einen Zeitplan dafür, was ich gedachte zu lernen, und mein Chef war begeis- tert. Die Idee war, eine Anwendung zu entwickeln, die den Benutzer beleidigte und die passend »Der Belei- diger« (The Insulter) genannt wurde. Version 1 war eine einfache Form mit einer einzelnen Schaltfläche, die beim Anklicken eine zufällige Beleidigung aus der Liste der fest kodierten Beleidigungen einblendete. Die zweite Version las Beleidigungen aus einer Datenbank und erlaubte es, neue Beleidigungen mithilfe eines Formulars hinzuzufügen. Die dritte Version stellt eine Verbindung zum Microsoft Exchange-Server her und erlaubte es, Beleidigungen per E-Mail an andere Mitarbeiter in der Firma zu schicken. Mein Manager war sehr erfreut zu sehen, wie und was ich vorhatte, um die Technologie zu lernen. Genau genommen ist es für Ihren Manager nur wichtig, dass er seinem Chef sagen kann, was Sie Tag für Tag tun. Wenn Sie Ihrem Manager diese Informationen geben, sind Sie sein Lieblingsmitarbeiter. Als ich meine erste Begegnung mit Microsoft .NET hatte, habe ich schnell die Beleidiger-Idee entstaubt und sie wurde zu Beleidiger .NET! Im Abschnitt »Voraussetzungen für das Debuggen« später in diesem Kapitel muss ich noch mehr sagen zu den Fertigkeiten und Kenntnissen, die für Entwickler entscheidend sind. Fehlen von Qualitätsverpflichtungen Der letzte Grund, dass Fehler in Projekten auftreten, ist meiner Meinung nach der schwer wiegendste. Jede Firma und jeder Techniker, mit dem ich jemals gesprochen habe, hat behauptet, der Qualität verpflichtet zu sein. Leider fehlt manchen Firmen und Technikern die wirkliche Verpflichtung, die für Qualität entschei- dend ist. Wenn Sie schon einmal in einer Firma, die sich der Qualität verpflichtet hat, oder mit einem qualitätsbewussten Ingenieur gearbeitet haben, wissen Sie das vielleicht. Sie verbreiten einen tiefen Stolz auf das, was sie produzieren, und sind bereit, ihre Anstrengungen auf alle Teile der Entwicklung und nicht nur die attraktiven Teile auszudehnen. Anstatt sich beispielsweise in den Details eines Algorithmus zu verlieren, greifen sie zu einem einfacheren Algorithmus und wenden ihre Zeit dafür auf, daran zu arbeiten, wie sich dieser Algorithmus am besten testen lässt. Letztlich kaufen Kunden keine Algorithmen, sondern hochquali- tative Produkte. Firmen und Einzelpersonen mit einer echten Verpflichtung zur Qualität weisen viele gemeinsame Eigenschaften auf: sorgfältige Vorausplanung, personelle Verantwortlichkeit, solide Qualitäts- kontrolle und ausgezeichnete Kommunikationsfähigkeiten. Viele Firmen und Einzelpersonen wickeln die wichtigen Softwareentwicklungsaufgaben (d. h. Zeitplanung, Kodierung usw.) völlig mechanisch ab, doch nur diejenigen, die auf die Details achten, liefern hochqualitative Produkte rechtzeitig aus. Als gutes Beispiel für eine Qualitätsverpflichtung lässt sich meine erste monatliche Revision bei NuMega anführen. Ich war erstens erstaunt, so schnell einen Überblick zu erhalten, wenn man normalerweise nach Rückmeldungen vom Chef betteln muss. Zu den wichtigen Teilen der Revision gehörte es, die Anzahl der Bugs aufzuzeichnen, die ich für das Produkt protokolliert hatte. Ich war allerdings auch überrascht zu entdecken, dass NuMega diese Statistik als Teil meines Leistungsüberblicks auswertete, denn obwohl das Aufspüren von Fehlern ein unverzichtbarer Teil für die Aufrechterhaltung der Produktqualität ist, hatte keine andere Firma, bei der ich beschäftigt war, jemals etwas so Offensichtliches überprüft. Die Entwickler wissen, wo die Bugs stecken, aber sie müssen einen Anreiz erhalten, um diese Bugs in das Bugverfolgungs- system einzugeben. NuMega hat die Lösung gefunden. Glauben Sie mir: Als ich mich mit dem Eingabeteil für die Fehlerzählung in meinem Bericht angefreundet hatte, habe ich alles was ich finden konnte (egal wie trivial es war) protokolliert. Angesichts all der Fachautoren, Qualitätstechniker, Entwicklungsingenieure und Manager, die alle darum wetteiferten, die meisten Bugs zu protokollieren, konnten nur wenige Bugs durch John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
16 Kapitel 1: Bugs: Woher sie kommen und wie man sie beseitigt die Maschen fallen. Vor allem aber hatten wir eine realistische Vorstellung davon, wo wir an einem Projekt zu einem bestimmten Zeitpunkt standen. Zwei zusätzliche Beispiele von der technischen Seite stammen aus den beiden ersten Ausgaben dieses Buchs. Die Begleit-CD der ersten Ausgabe hatte über 2,5 MB Quellcode. Die zweite Ausgabe, die sowohl systemei- genes als auch .NET-Debugging behandelt, bringt über 6,9 MB Quellcode mit (und das war kein kompilier- ter Code, sondern lediglich der Quellcode!). Das ist eine riesige Codemenge und ich freue mich zu sagen, dass das um vieles mehr ist, als was Sie mit den meisten Büchern bekommen. Vielen Lesern ist allerdings nicht bewusst, dass ich nahezu 60 Prozent der Zeit für beide Bücher nur mit dem Testen des Codes ver- bracht habe. Die Leser sind wirklich enthusiastisch, wenn sie einen Fehler im Code von Bugslayer finden. Letztlich möchte ich aber keinen Anlass geben für E-Mails der Art »Erwischt! Ich habe einen Fehler in der Bugslayer-Kolumne gefunden!«. In beiden Büchern habe ich das Null-Fehler-Ziel verfehlt. Für die erste Ausgabe wurden fünf und für die zweite Ausgabe 13 Fehler gemeldet. Mit den phänomenalen Testwerkzeugen, die zu Microsoft Visual Studio 2005 gehören, habe ich hart daran gearbeitet, um null Fehler in dieser Ausgabe zu erreichen. Das klassische Softwarebuch Software Reliability: Measurement, Prediction, Application von John D. Musa, Anthony Iannino und Kazuhira Okumoto (McGraw-Hill Book Company, 1987) stellt fest, dass der durchschnittliche Code einen Fehler auf zehn Codezeilen enthält. Was ist das Geheimnis, so viel Code zu produzieren und die Fehlerzahl niedrig zu halten? Es ist ganz einfach: Auf Teufel komm raus testen. In der Tat ist dies ein derar- tig großes Thema, dass ich ihm ein ganzes Buch zum Testen nach diesem hier gewidmet habe und das Testing .NET 2.0 Applications heißen soll. Als Entwicklungsmanager folge ich einem Ritual, von dem ich sicher weiß, dass es eine Verpflichtung zur Qualität fördert: Jedes Teammitglied hat bei jedem Meilenstein zuzustimmen, dass das Produkt einsatzbe- reit ist. Wenn irgendwer im Team nicht davon überzeugt ist, dass das Produkt bereit ist, wird es nicht ausge- liefert. Ich beseitige lieber einen kleineren Bug und durchleide noch einen vollen Tag zum Testen, als irgendetwas zu verschicken, auf das das Team nicht stolz ist. Dieses Ritual stellt nicht nur sicher, dass jeder im Team an die Qualität glaubt, sondern lässt jedem im Team am Ergebnis teilhaben. Ein interessantes Phänomen habe ich festgestellt: Die Teammitglieder niemals die Freigabe wegen eines Bugs eines anderen gestoppt; der Eigentümer des Bugs ist ihnen immer zuvorgekommen. Die Qualitätsverpflichtung einer Firma legt die Stimmung für die gesamte Entwicklungsanstrengung fest. Diese Verpflichtung beginnt mit dem Einstellungsvorgang und erstreckt sich über die endgültige Qualitäts- sicherung auf dem Release-Kandidaten. Jede Firma sagt, dass sie die besten Leute einstellen möchte, doch wenige Firmen bieten verlockende Gehälter und Vergünstigungen. Außerdem sind einige Firmen nicht gewillt, die Tools und Ausstattung bereitzustellen, die Techniker brauchen, um hochqualitative Produkte zu erzeugen. Leider scheuen zu viele Firmen die Ausgabe von $500 für ein Tool, mit dem sich ein hässlicher Absturzfehler in Minuten beseitigen lässt, geben aber bereitwillig Tausende von Dollars aus, um ihre Ent- wickler zu bezahlen, damit sie wochenlang damit zubringen, denselben Bug aufzuspüren. Die Verpflichtung zur Qualität dokumentiert eine Firma auch dadurch, wenn sie die härteste Entscheidung im Geschäftsleben trifft – Leute entlassen, die sich nicht an die vom Unternehmen eingerichteten Standards halten. Wenn Sie ein großartiges Team voller Leute auf der rechten Seite der Glockenkurve aufbauen, müssen Sie daran arbeiten, dass sie dort bleiben. Wir kennen alle die Person, deren Job anscheinend darin besteht, Sauerstoff zu verbrauchen, die aber ständig Gehaltserhöhungen und Sonderleistungen bekommt, während Sie sich zu Tode arbeiten, Nachtschichten einlegen und auch an Wochenenden einsatzbereit sind, damit das Produkt fertig wird. Das Ergebnis ist, dass gute Leute schnell erkennen, dass es die Anstrengung John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
Was sind Bugs? 17 nicht Wert ist. Sie lassen in ihrem Arbeitseifer nach oder, was noch schlimmer ist, sehen sich nach anderen Jobs um. Als Projektmanager an einem Projekt habe ich mich zwar davor gefürchtet, doch habe ich jemanden zwei Tage vor Weihnachten entlassen. Ich wusste, dass Leute im Team fühlten, dass sich dieser Einzelne nicht an die Standards gehalten hatte. Wären sie aus dem Weihnachtsurlaub zurückgekommen und diese Person wäre immer noch da gewesen, hätte ich das Team verloren, das wir so mühevoll zusammengestellt hatten. Da mit die schlechte Leistung dieses Mitarbeiters schon längere Zeit bekannt war, hatte ich die richtigen Gründe für meine Entscheidung. Glauben Sie mir, ich hätte lieber wieder in der Armee gekämpft, als diese Person zu feuern. Es wäre viel einfacher gewesen, ihn gewähren zu lassen, doch ich hatte eine Verpflichtung dem Team und der Firma gegenüber, den Qualitätsjob zu tun, für den ich eingestellt worden war. Es war besser, diesen Hügel zu überwinden, als alle anderen Mitarbeiter zu deaktivieren und ihre Leistung zu bremsen. Mir ist keine Entlassung leicht gefallen, aber sie waren notwendig. Eine Qualitätsverpflichtung ist äußerst schwierig und bedeutet, dass Sie Dinge tun müssen, die Sie in der Nacht nicht schlafen lassen. Doch müssen Sie diese Fähigkeiten mitbringen, damit Sie großartige Software liefern und sich um Ihre Mitarbei- ter kümmern können. Wenn Sie einem Unternehmen angehören, das am Fehlen von Qualitätsverpflichtung leidet, werden Sie feststellen, dass es keineswegs leicht ist, eine Firma über Nacht in ein qualitätsbewusstes Unternehmen umzuwandeln. Als Manager können Sie für die Ingenieure, die für Sie arbeiten, die Richtung und den Ton angeben und sich bei den höheren Leitungsebenen für die Erweiterung einer Qualitätsverpflichtung über das gesamte Unternehmen stark machen. Als Ingenieur können Sie an Ihrem Code arbeiten, um ihn im Projekt am robustesten und erweiterungsfähigsten zu machen, sodass Sie ein Beispiel für andere abgeben. Debuggen planen Nachdem wir uns mit den Typen und Ursprüngen von Bugs beschäftigt haben und Sie gewisse Vorstellun- gen davon besitzen, wie Sie Fehler vermeiden oder lösen, ist es an der Zeit, über den Ablauf des Debuggens nachzudenken. Obwohl viele erst über das Debuggen nachdenken, wenn sie einen Absturz während der Kodierungsphase erlitten haben, sollten Sie gleich von Anfang an in der Anforderungsphase das Debuggen berücksichtigen. Je mehr Sie Ihre Projekte im Voraus planen, desto weniger Zeit – und Geld – müssen Sie damit aufbringen, sie später zu debuggen. Wie bereits weiter vorn in diesem Kapitel erwähnt, kann das Einschleichen von Features den Ruin für Ihr Projekt bedeuten. Meistens führen nicht geplante Features zu Bugs und katastrophalen Folgen bei einem Produkt. Das bedeutet allerdings nicht, dass Ihre Pläne in Stein gemeißelt werden müssen. Manchmal müssen Sie ein Feature ändern oder dem Produkt hinzufügen, um konkurrenzfähig zu sein oder um die Bedürfnisse des Benutzers besser zu erfüllen. Bevor Sie in den Code eingreifen, müssen Sie unbedingt erst genau ermitteln – und einplanen –, was sich ändern wird. Und denken Sie daran, dass das Hinzufügen eines Features nicht nur den Code beeinflusst, sondern sich auch auf das Testen, die Dokumentation und manchmal sogar Marketingbotschaften auswirkt. Wenn Sie Ihren Produktionszeitplan korrigieren, sollten Sie allgemein die Regel beachten, dass die Zeit für das Hinzufügen oder Entfernen eines Features exponen- tiell wächst, je weiter Sie im Produktionszyklus vorangeschritten sind. Im seinem ausgezeichneten Buch Code Complete (Microsoft Press, 2004, 2. Auflage, Seiten 29–30) behandelt Steve McConnell die Kosten einer Fehlerbeseitigung. Einen Fehler während der Anforderungs- und Pla- nungsphasen zu beseitigen, kostet sehr wenig. Schreitet das Produkt voran, nehmen jedoch die Kosten einer John Robbins: Microsoft .NET 2.0 Anwendungen debuggen. Microsoft Press 2007 (ISBN 978-3-86645-408-8)
Sie können auch lesen
