Richtlinien für das Einchecken von qualitativ hochwertigem Code

  • Artikel

Aktualisiert: November 2007

Die folgende Liste enthält verschiedene Richtlinien für das Einchecken von hochwertigem Code.

Erforderlich

  • Bestehen Sie darauf, dass nur qualitativ hochwertiger Code eingecheckt wird.

    Lassen Sie nicht zu, dass Code in schlechter Qualität eingecheckt wird, da dies später im Produktzyklus zu Problemen führt. Sie sollten sich im Klaren darüber sein, dass Probleme, die zu kompliziert oder undurchsichtig sind oder zu spät im Produktzyklus erkannt werden, normalerweise in Teams nicht korrigiert werden.

  • Verwenden Sie Prüflisten.

    Notieren Sie sich, welche Arten von Fehlern Ihnen normalerweise unterlaufen, und erstellen Sie anhand dieser Informationen eine Prüfliste für Ihre weitere Arbeit. Zunächst können Sie Fehler, die in Ihrer Gruppe oder Abteilung häufig vorkommen, auflisten und die Liste dann zur eigenen Verwendung personalisieren.

  • Führen Sie Codeüberprüfungen durch.

    Bei Codeüberprüfungen haben Sie die Gelegenheit, den von Ihnen verfassten Code zu erläutern und so selbst besser zu verstehen. Andere Teammitglieder haben die Gelegenheit, Ihren Code aus einem anderen Blickwinkel zu betrachten.

  • Schreiben Sie Komponententests.

    Die beste Möglichkeit zur Gewährleistung einer hohen Qualität besteht im Schreiben von Tests, mit denen Daten und Algorithmen überprüft werden und sichergestellt wird, dass keine Fehler wiederholt auftreten. Es gibt vier Arten von Komponententests:

    • Bei positiven Komponententests wird der Code wie beabsichtigt ausgeführt und das Ergebnis auf seine Richtigkeit überprüft.

    • Bei negativen Komponententests wird der Code absichtlich missbraucht und auf seine Stabilität und eine geeignete Fehlerbehandlung überprüft.

    • Bei Belastungstests wird der Code der größtmöglichen Belastung ausgesetzt in der Absicht, schwer erkennbare Fehler in Bezug auf Ressourcen, zeitliche Steuerung oder wiedereintrittsfähigen Code aufzudecken.

    • Bei Tests durch Einfügen von Fehlern werden Anomalien in der Fehlerbehandlung offenkundig.

    Weitere Informationen finden Sie unter Gewusst wie: Erstellen eines Komponententests.

  • Verwenden Sie Codeanalysetools.

    Die einfachste Methode, um Probleme frühzeitig zu erkennen, besteht darin, die Warnstufe des Compilers zu erhöhen und Codeanalysetools zu verwenden. Vor allem kommt es darauf an, Warnungen niemals zu ignorieren und den Code immer zu korrigieren.

    Weitere Informationen finden Sie unter Erkennen und Korrigieren von C/C++-Codefehlern und Erkennen und Korrigieren von Fehlern in verwaltetem Code.

  • Verwenden Sie im Quellcode keine unangebrachten Begriffe oder Ausdrücke.

    Der Quellcode darf keine unangebrachten Begriffe oder Ausdrücke enthalten. Viele Kunden überall auf der Welt reagieren extrem empfindlich auf bestimmte Ausdrücke oder Namen, insbesondere auf fragwürdige politische Begriffe. Durchsuchen Sie den Quellcode nach Begriffen und Ausdrücken mit unerwünschter politischer Bedeutung, und erfassen Sie möglicherweise gefundene Fehler.

  • Erstellen Sie Arbeitsaufgaben.

    Denken Sie auch an unvollendete Arbeitsvorgänge, und erstellen Sie Arbeitsaufgaben für TODO-Kommentare, REVIEW-Kommentare, BUG-Kommentare und UNDONE-Kommentare. Weitere Informationen finden Sie unter Gewusst wie: Hinzufügen neuer Arbeitsaufgaben.

Vermeiden

  • Features ohne Spezifikation.

    Schreiben Sie keinen Code ohne Spezifikation. Schreiben Sie zunächst eine Spezifikation, und lassen Sie diese überprüfen. Ohne Spezifikation kann das Testteam nicht zwischen ordnungsgemäßer Funktionalität und Fehlern unterscheiden. Wenn Sie keine Spezifikation für den Code verfassen, kann es leicht zu Missverständnissen innerhalb des Teams sowie zwischen Ihnen und dem Kunden kommen, und am Ende wird ein Produkt in schlechter Qualität geliefert. Weitere Informationen finden Sie unter Team Foundation-Teamprojekte.

  • Erreichen des ersten Meilensteins ohne installiertes Produkt.

    Das Testteam muss die Möglichkeit haben, das Produkt auf den Arbeitscomputern zu installieren, auch wenn es sich nur um einen Prototyp handelt. Weitere Informationen finden Sie unter Übersicht über Team Foundation Build.

Empfohlen

  • Verwenden Sie einen einheitlichen Codierungsstil.

    Wenn das gesamte Team denselben Codierungsstil verwendet, werden die Lesbarkeit des Produkts sowie die Konsistenz, Verwaltbarkeit und Gesamtqualität verbessert. Wie die Richtlinien im Einzelnen formuliert werden, ist von sekundärer Bedeutung. Es kommt darauf an, dass Richtlinien aufgestellt werden, an die sich dann das gesamte Team hält. Die wesentlichen Vorteile einer Stilvorgabe bestehen darin, dass Konsistenz gewährleistet wird und Codierungsmuster leichter zu erkennen sind. Wählen Sie deshalb einen Stil, und verwenden Sie diesen.

  • Schreiben Sie zuerst Komponententests und erst dann den Code.

    Die Methode der Test-First-Entwicklung stammt aus der agilen Entwicklung und dem Extreme Programming. Indem Sie zuerst Komponententests schreiben, können Sie verschiedene Qualitätsziele erreichen:

    • Sie stellen sicher, dass Komponententests geschrieben werden.

    • Sie sorgen dafür, dass der Code problemlos getestet werden kann, wodurch häufig die Code Cohesion erhöht und eine losere Kopplung zwischen Modulen erreicht wird.

    • Wenn zuerst festgelegt wird, wie der Entwurf getestet werden soll, wird häufig der richtige Entwurf offenkundig.

    Weitere Informationen finden Sie unter Gewusst wie: Erstellen eines Komponententests.

  • Gestalten Sie den Code so, dass er auf andere Plattformen übertragbar ist.

    Wenn Sie bei Entwurf und Programmierung die Portabilität anstreben, wird der Code robuster. Daher empfiehlt sich diese Vorgehensweise, auch wenn Sie nicht die Absicht haben, den Code für eine andere Plattform bereitzustellen. Wenn Sie Code portabel gestalten, erreichen Sie Folgendes:

    • Sie legen bessere Annahmen zugrunde.

    • Sie sind sich über Datentypen und Entwurfsabsicht eher im Klaren.

    • Sie stellen sicher, dass der Code besser geeignet ist, in Zukunft neue Plattformen zu unterstützen.

  • Gestalten Sie vorhandenen Code um, indem Sie ihn in kleinere Funktionen unterteilen.

    Durch eine Umgestaltung können Sie altem Code zu neuem Leben verhelfen. Die Korrektur umfangreicher alter Systeme ist häufig ein schwieriges Unterfangen, da die Interaktionen in solchen Systemen mitunter so komplex sind, dass schon die Änderung eines Kommentars gravierende Folgen haben kann.

    Damit eine Umgestaltung erfolgreich durchgeführt werden kann, müssen Sie zunächst einen starken Komponententest durchführen, um sicherzustellen, dass sich bei der Umgestaltung keine neuen Fehler einschleichen. Unterteilen Sie anschließend umfangreiche Funktionen in Auflistungen kleinerer Funktionen, ohne die Funktionalität zu ändern. Es gelten folgende Richtlinien:

    • Jede kleinere Funktion soll für einen einzigen Aufgabentyp zuständig sein, z. B. Benutzeroberfläche, Datenbankzugriff, COM-Interaktion mit einer einzelnen Schnittstelle usw.

    • Nachdem Sie alle Funktionen in einem Subsystem vollständig umgestaltet haben, können Sie einzelne kleine Funktionen ändern, ohne dass dies Auswirkungen auf das ganze System hat. Sie können Funktionen einzeln hinzufügen, entfernen oder ihre Funktionalität verbessern.

    Weitere Informationen finden Sie unter Umgestalten von Klassen und Typen.

  • Prüfen Sie vorhandenen Code.

    Probleme treten häufig konzentriert in einzelnen Modulen auf. Wenn der neue Code fehlerfrei ist, in bestimmten Modulen des vorhandenen Codes jedoch Probleme vorliegen, überprüfen Sie nur diese Module. Wenn der neue Code und der vorhandene Code zu stark ineinander greifen, hilft häufig eine Umgestaltung bei der Behebung von Problemen. Weitere Informationen finden Sie unter Erkennen und Korrigieren von C/C++-Codefehlern und Erkennen und Korrigieren von Fehlern in verwaltetem Code.

  • Gehen Sie alle Codepfade in einem Debugger durch.

    Eine der besten Möglichkeiten zur Überprüfung von Code besteht darin, diesen in einem Debugger durchzugehen. Überprüfen Sie bei jeder Zeile, ob die erwartete Aktion ausgeführt wird. Das Durchgehen aller Codepfade in einem Debugger entspricht einem Zeile für Zeile durchgeführten Komponententest. Dieses Verfahren ist zwar aufwendig, aber zum Aufspüren von unerwartetem Verhalten sehr wirkungsvoll.

Nicht empfohlen

  • Anforderungsdokument als Spezifikation.

    Versuchen Sie nicht, ein Anforderungsdokument als Spezifikation zu interpretieren. Ihre Interpretation kann sich von der des Programmmanagers oder des Testers erheblich unterscheiden. In diesem Fall entspricht Ihre Implementierung nicht den Erwartungen der anderen Personen.