Wie überprüfe ich meinen eigenen Code? [geschlossen]

Ich arbeite an einem Projekt solo und muss meinen eigenen Code pflegen. In der Regel wird die Codeüberprüfung nicht vom Autor des Codes durchgeführt, sodass der Überprüfer den Code mit frischen Augen betrachten kann - ich habe jedoch keinen solchen Luxus. Welche Methoden kann ich anwenden, um meinen eigenen Code effektiver zu überprüfen?

Verwenden Sie zunächst Tools, um so viel wie möglich zu überprüfen. Tests (die mit einer angemessenen Codeabdeckung abgesichert sind) geben Ihnen ein gewisses Vertrauen in die Richtigkeit des Codes. Statische Analysewerkzeuge können viele Best-Practice-Aspekte erfassen. Es wird immer Probleme geben, bei denen Sie menschliche Augen brauchen, um zu bestimmen, und Sie werden nie so gute Arbeit leisten, wenn Sie Ihre eigenen Sachen überprüfen, wie bei jemand anderem. Es gibt jedoch einige Dinge, die Sie tun können, um zu helfen

• Prüfungstests existieren und bestehen (haben möglicherweise eine Ziel-Testabdeckung, obwohl Sie dies in bestimmten Fällen möglicherweise brechen müssen, aber Sie sollten in der Lage sein zu rechtfertigen, warum)
• Statische Analyse besteht (es wird auch falsche Negative geben, aber das ist in Ordnung, solange Sie begründen können, warum es dann in Ordnung ist, sie zu unterdrücken).
• Führen Sie eine Checkliste mit weiteren zu überprüfenden Dingen (fügen Sie diese idealerweise als neue statische Analyseregeln hinzu, wenn möglich). Stellen Sie sicher, dass Sie alles überprüfen, was die SA nicht überprüfen kann, z natürlich eines der 2 schwierigen Probleme, die der Informatik bekannt sind)
• Wenn ein Fehler festgestellt wird, prüfen Sie, ob die Ursache systembedingt ist, und prüfen Sie, warum er in früheren Tests oder Überprüfungen nicht gefunden wurde

Dies ist natürlich hilfreich, wenn Sie auch anderen Code überprüfen

Schauen Sie sich die Code Review Stack Exchange-Site an. Es dient zum Teilen von Code aus Projekten, an denen Sie zur Begutachtung arbeiten :

Code Review Stack Exchange ist eine Frage-und-Antwort-Website, auf der Sie eine Peer Review Ihres Codes durchführen können. Wir arbeiten zusammen, um die Fähigkeiten von Programmierern weltweit zu verbessern, indem wir Arbeitscode übernehmen und verbessern.

Wenn Sie in den folgenden Bereichen Feedback zu einem bestimmten Arbeitsstück Code aus Ihrem Projekt suchen…

• Best Practices und Verwendung von Entwurfsmustern
• Sicherheitsprobleme
• Performance
• Richtigkeit in unerwarteten Fällen

Sie können auch Tools zur statischen Codeanalyse verwenden, um bestimmte Probleme zu erkennen. In einigen Fällen werden jedoch Fehlalarme ausgegeben, und Sie können nicht vorschlagen, wie das Design verbessert werden kann.

Ich habe mehrere völlig verschiedene Personen in meinem Kopf entwickelt. Einer von ihnen ist nicht einmal ein Programmierer! Wir unterhalten uns, diskutieren die neuesten Nachrichten und überprüfen den Code des jeweils anderen.

Ich kann meinen Ansatz nur empfehlen.

ps Er scherzt nicht.

Ich stimme der Meinung von jk-s zu, dass eine Einzelbewertung nicht so effizient ist wie eine 2-Personen-Bewertung. Sie können jedoch versuchen, das Beste daraus zu machen:

Kurzfristige Überprüfung (kurz nachdem der Code erstellt wurde)

Ich benutze Git als lokales Repository. Immer wenn ich ein Feature beendet oder einen Fehler behoben habe, übertrage ich die Änderungen in das Repository.

Bevor ich einchecke, vergleiche ich, was ich in meinem Code geändert habe und überlege:

• spiegeln Variable / Methode / Klassennamen immer noch wider, wofür sie verwendet werden?

Langzeitüberprüfung (6 Monate nach Erstellung des Codes)

Ich frage mich:

• Kann ich in einem Satz beschreiben, was eine Klasse / Methode / Variable tut?
• Wie einfach ist es, eine Klasse für sich zu verwenden (ohne die anderen Klassen) oder einen Test für Unittest zu schreiben?

Legen Sie zunächst Ihren Code so lange wie möglich beiseite. Arbeite an etwas anderem, einem anderen Teil des Codes. Auch nach einem Tag werden Sie erstaunt sein, was Sie finden.

Zweitens dokumentieren Sie Ihren Code. Viele Programmierer hassen es, ihren Code zu dokumentieren, aber setzen Sie sich und schreiben Sie Dokumentation, wie man den Code verwendet und wie es funktioniert. Wenn Sie Ihren Code anders betrachten, werden Sie Fehler finden.

Es wurde gesagt, dass wahre Meisterschaft eines Faches die Fähigkeit ist, es jemand anderem beizubringen. Mit der Dokumentation versuchen Sie, jemand anderem Ihren Code beizubringen.

Verwandeln Sie diese Debugging-Technik in eine Codeüberprüfungstechnik: http://en.wikipedia.org/wiki/Rubber_duck_debugging

Das Konzept wirkt Wunder, wenn Sie sich in eine richtige Denkweise versetzen, um Code so zu verarbeiten, als wäre er neu.

Zusätzlich zu den nützlichen Tools, die in anderen Antworten erwähnt wurden, ist es meiner Meinung nach hilfreich, Ihre Denkweise zu ändern, wenn Sie eine Codeüberprüfung durchführen. Es ist albern, aber ich sage mir: "Ich setze meinen Code-Review-Hut auf". Ich mache das gleiche mit QA.

Dann ist es wichtig zu beschränken sich auf diese Einstellung. Sie sind entweder der Rezensent oder der Rezensent, Sie können nicht beide gleichzeitig sein. Als Rezensent mache ich objektive Notizen, um sie dem Rezensenten mitzuteilen. Ich ändere den Code nicht, während ich ihn überprüfe. Das sollte ein Überprüfer nicht tun.

Die Formalität fühlt sich manchmal etwas absurd an, aber wenn ich alleine arbeite, stelle ich fest, dass ich oft in viele Richtungen gezogen werde. Daher kann es sein, dass ich die Überprüfungsschleife nicht unbedingt schließe, bevor etwas anderes eintritt - diese Formalität (und ich spreche wirklich über grobe Notizen in einem Wiki-Tool) ist nützlich, um sicherzustellen, dass die Überprüfung durchgeführt wird. Ebenso füge ich mit aufgesetztem QA-Hut Tickets für Fehler hinzu, bevor ich sie behebe.

Es scheint, dass die allgemeine Meinung ist, dass Selbstüberprüfung nicht effektiv ist. Ich bin nicht einverstanden und ich denke, dass eine Selbstüberprüfung viele Probleme aufdecken kann, wenn sie gründlich durchgeführt wird.

Hier einige Tipps aus meiner langjährigen Erfahrung:

• Halten Sie eine grobe Checkliste bereit. Dies sind Dinge, die Sie markieren möchten, während Sie Ihren Code lesen.
• Schalten Sie Ihre Codeüberprüfung offline. Es mag verschwenderisch klingen, aber nehmen Sie Ausdrucke, die Sie mit Anmerkungen versehen und hin- und herblättern können, oder das digitale Äquivalent von schön hervorgehobenen PDFs, die mit einem iPad synchronisiert sind, das dann offline geschaltet wird. Gehen Sie von Ihrem Schreibtisch weg, damit Sie Ihren Code ohne Ablenkung überprüfen können.
• Tun Sie es am frühen Morgen und nicht am Ende eines Arbeitstages. Frisches Augenpaar ist besser. Tatsächlich könnte es hilfreich sein, einen Tag vor der erneuten Überprüfung des Codes nicht mit dem Code zu arbeiten.

Nur zu Ihrer Information - diese Richtlinien waren Teil der Empfehlungen in Oracle vor ein paar Jahren, als ich dort arbeitete, wo das Ziel darin bestand, Fehler "vorgelagert" zu erkennen, bevor der Code getestet wurde. Es hat sehr geholfen, obwohl es von vielen Entwicklern als langweiliger Job angesehen wurde.

Die Personal Software Process-Technik für Überprüfungen kann hilfreich sein, wenngleich historische Daten über Ihre Arbeit und die Qualität der Produkte erforderlich sind.

Sie beginnen mit historischen Daten zu Ihren Arbeitsprodukten, insbesondere Anzahl und Art der Mängel. Es gibt verschiedene Methoden zum Klassifizieren von Fehlern, wie z. B. diese aus einem PSP-Kurs . Sie können Ihre eigenen entwickeln, aber die Idee ist, dass Sie in der Lage sein müssen, zu sagen, welche Fehler Sie auf dem Weg machen.

Sobald Sie wissen, welche Fehler Sie machen, können Sie eine Checkliste entwickeln, die Sie während einer Überprüfung verwenden können. Diese Checkliste behandelt die häufigsten Fehler, die Sie machen und die Ihrer Meinung nach am besten in einer Überprüfung aufgefangen werden können (im Gegensatz zur Verwendung eines anderen Tools). Verwenden Sie bei jeder Überprüfung eines Arbeitsprodukts die Checkliste, um nach Fehlern zu suchen, diese zu dokumentieren und zu beheben. Überarbeiten Sie diese Checkliste von Zeit zu Zeit, um sicherzustellen, dass Sie sich auf echte, relevante Probleme in Ihrem Code konzentrieren.

Ich würde auch empfehlen, die Werkzeugunterstützung zu verwenden, wenn dies sinnvoll ist. Statische Analysetools können dabei helfen, einige Fehler zu finden, und einige unterstützen sogar die Stilprüfung, um die Konsistenz und einen guten Codestil zu gewährleisten. Die Verwendung einer IDE mit Codevervollständigung und Syntaxhervorhebung kann Ihnen auch dabei helfen, Probleme zu vermeiden oder zu erkennen, bevor Sie auf "Erstellen" klicken. Unit-Tests können Logikprobleme abdecken. Und wenn Ihr Projekt ausreichend umfangreich oder komplex ist, kann die fortlaufende Integration all dies zu einem regelmäßig ablaufenden Prozess zusammenfassen und nette Berichte für Sie erstellen.

Solo zu arbeiten bedeutet, dass Sie, sofern Sie nicht völlig unbekannten Personen vertrauen, Code in Ihrem Namen zu überprüfen, die Art und Weise überprüfen müssen, in der Sie Ihre Software schreiben, um die Codequalität aufrechtzuerhalten.

In erster Linie sollten Sie ein Mittel haben, um sicherzustellen, dass Ihr Code den Anforderungen entspricht, und zweitens, dass sich Ihr Code relativ leicht ändern lässt, wenn Sie später entscheiden, dass Sie etwas falsch gemacht haben. Mein Vorschlag wäre, aus folgenden Gründen einen verhaltensorientierten Entwicklungsansatz anzuwenden :

1. BDD bedeutet, zuerst einen Code-Test zu schreiben. Dadurch wird sichergestellt, dass der gesamte Code von Tests abgedeckt wird.
2. BDD ist im Wesentlichen TDD, jedoch mit einem etwas anderen Fokus und einer anderen "Sprache". Dies impliziert, dass Sie Ihren Code während der Arbeit kontinuierlich überarbeiten und anhand Ihrer Tests sicherstellen, dass Ihre Überarbeitungsbemühungen weiterhin sicherstellen, dass Ihr Code Ihren Produktspezifikationen entspricht.
3. Die BDD-Sprache fordert dazu auf, Tests in Form von Aussagen zu verfassen, die Anforderungen im Wesentlichen als Komponententests kodieren.

Die Idee hier ist also, dass Ihre kontinuierliche Überarbeitung des Codes, auch nachdem Sie Ihre Tests bestanden haben, bedeutet, dass Sie Ihren eigenen Code effektiv überprüfen und Ihre Komponententests als "zusätzliches Augenpaar" verwenden, das sicherstellt, dass Ihr Code nicht funktioniert. Sie weichen von den Anforderungen ab, die in den Tests kodiert werden. Eine hohe Testabdeckung basierend auf den Anforderungen stellt außerdem sicher, dass Sie Ihren Code in Zukunft ändern können, ohne die Anforderungen zu verletzen.

Das eigentliche Problem für Sie ist, ob Sie in der Lage sind, potenzielle Probleme in Ihrem Code zu erkennen, die auf einen Umgestaltungsbedarf hinweisen. Es gibt verschiedene Profilerstellungstools auf dem Markt, die Ihnen dabei helfen können, sowie verschiedene andere Tools, die sich mit Codequalitätsmetriken befassen. Diese können oftmals Aufschluss über viele Dinge geben, die Codeüberprüfungen übersehen können, und sind ein Muss, wenn Sie Projekte selbst entwickeln. In der Realität ist Erfahrung jedoch der Schlüssel, und sobald Sie die Gewohnheit haben, bei Ihrem Refactoring gnadenlos zu sein, werden Sie Ihren eigenen Code wahrscheinlich viel kritischer sehen. Wenn Sie es noch nicht getan haben, empfehlen wir Ihnen, Martin Fowlers Refactoring- Buch als Ausgangspunkt zu lesen und nach einer guten BDD-API zu suchen, die in der von Ihnen gewählten Sprache für Sie geeignet ist.

Immer, wenn ich in der gleichen Situation war wie Sie, habe ich versucht, das Problem zu lösen, dass ich zu nah am Code bin, um ihn objektiv untersuchen zu können. Es versteht sich von selbst, dass ein Tool nicht denselben Wert wie ein erfahrener Prüfer liefern kann, aber Sie können es dennoch verwenden, um Bereiche mit schlechtem Design zu lokalisieren.

Ein Tool, das ich in dieser Hinsicht ziemlich nützlich fand, war SourceMonitor . Es ist ein bisschen simpel, aber es gibt eine gute Meinung auf mittlerer Ebene über Ihren Code, z. B. die Anzahl der Methoden in einer Klasse und die Komplexität jeder Methode. Ich war immer der Meinung, dass diese Art von Informationen genauso wichtig (wenn nicht wichtiger als) ist, wie die Durchsetzung von Codierungsstilen mit Tools wie StyleCop usw. (die wichtig sind, aber häufig nicht die Ursache der größten Probleme sind). Verwenden Sie diese Tools mit den üblichen Haftungsausschlüssen: Wissen Sie, wann eine Faustregel verletzt werden muss, und etwas, das in einem Code-Metrik-Tool nur grün ist, ist nicht automatisch von guter Qualität.

Ich kann Ihnen nicht sagen, wie oft ich einem Code-Reviewer etwas erklärt habe und die Glühbirne in meinem Kopf geht an und sagt: "Hey, warte eine Minute." Daher finde ich oft meine eigenen Fehler in der Codeüberprüfung, die die andere Person nicht gesehen hat. Sie könnten das also versuchen, indem Sie den Code so erklären, als säße eine Person neben Ihnen, die zu verstehen versuchte, was Sie getan haben und warum.

Eine andere Sache, die ich häufig in Code-Reviews finde, ist, dass der Entwickler die Anforderungen nicht wirklich befolgt hat. Vergleichen Sie also Ihren Code und was er tut, um die tatsächliche Anforderung zu erfüllen.

Wir machen häufig Dinge wie SSIS-Pakete mit ähnlichen strukturellen Anforderungen - für Code-Reviews habe ich eine Checkliste mit zu überprüfenden Dingen entwickelt (ist die Konfiguration korrekt, ist die Protokollierung eingerichtet, wird die Metadaten-Datenbank verwendet, befinden sich die Dateien am Standardspeicherort). usw.). Möglicherweise haben Sie einige Dinge, die Sie bei jeder Codeüberprüfung überprüfen können. Setzen Sie sich und überlegen Sie, was Sie auf eine Checkliste setzen möchten, um sicherzustellen, dass Ihre Codeüberprüfung durchgeführt wird (erster Punkt, stellen Sie sicher, dass die Anforderung erfüllt ist, nächster Punkt hat möglicherweise etwas mit Überfüllungs- und Protokollierungsfehlern zu tun). Wenn Sie Fehler machen und diese korrigieren, können Sie der Liste weitere Elemente hinzufügen (z. B. gehe ich zum nächsten Datensatz in einer Schleife oder wiederhole ich endlos das gleiche erste Element - es dauert nur eine Endlosschleife bis lehre dich, danach zu suchen!).

Geben Sie es 3 Monate, dann gehen Sie zurück und sehen Sie sich Ihren Code an. Ich verspreche dir, wenn du nichts falsches finden kannst (oder fragst, wer diesen Müll geschrieben hat!), Bist du ein besserer Mann als ich!

Normalerweise drucke ich meinen gesamten Code aus, setze mich in eine ruhige Umgebung und lese ihn durch. Dabei finde ich viele Tippfehler, Probleme, Dinge, die man überarbeiten muss, und räume auf. Es ist ein guter Selbsttest, den meiner Meinung nach jeder machen sollte.

Zurück am College war ich Schreiblehrer. Es hat mir sicherlich einige Perspektiven für das Codieren eröffnet, an die viele Entwickler meiner Meinung nach nie gedacht hätten. Eines der wichtigsten ist, Ihren Code laut vorzulesen. Es klingt nicht nach viel, aber ich werde ein perfektes Beispiel geben, mit dem sich wohl jeder identifizieren kann.

Haben Sie jemals eine E-Mail oder einen Artikel geschrieben, mehrmals gelesen, um sicherzustellen, dass er korrekt ist, und ihn dann gesendet, um festzustellen, dass Sie einen eklatanten Rechtschreib-, Tipp- oder Grammatikfehler haben? Ich habe das erst gestern gemacht, als ich einen Kunden gebeten habe, die Shit-Taste anstelle der Shift-Taste zu drücken. Wenn Sie in Ihrem Kopf lesen, sehen Sie, was Sie sehen möchten.

Dies ist eine Abkürzung für die Vorschläge, die andere gemacht haben: "Warte nur einen Tag, eine Woche oder einen Monat". Wenn Sie es laut lesen, fangen Sie die gleichen Dinge. Ich weiß nicht, warum es so effektiv ist, aber nachdem ich mit Hunderten von Studenten zusammengesessen und sie vorgelesen habe, kann ich nur sagen, dass es funktioniert.

Die meisten Menschen neigen dazu, ihren Code als ihr eigenes Baby zu betrachten und sie eher mit dem Ego als mit der Realität zu füttern. Überprüfen Sie den Code genau wie alle anderen Codeprüfungen, wenn Sie den Code einer anderen Person sehen. Vergiss ganz, dass du etwas geschrieben hast. Überprüfen Sie jede Codezeile. Eine Checkliste wäre hilfreich, um die Ästhetik der Überprüfung des eigenen Codes zu verbessern. Automatisierte Tools für die Codeüberprüfung können in gewissem Umfang hilfreich sein. Ich habe einige Tools wie klocwork (kommerzielle Software) verwendet. Dies ist sehr nützlich, wenn Sie in großen Projekten arbeiten und mehrere Entwickler daran arbeiten. Konzentrieren Sie sich immer auf die Fehlererkennung und nicht auf die Korrektur.

Es empfiehlt sich jedoch, sich selbst zu überprüfen und später mindestens zwei weitere Personen mit unterschiedlichen Rollen zur Überprüfung einzubeziehen.

Überlegen Sie, ob Sie eine Fagan-Inspektion selbst durchführen - Sie müssen den Prozess anpassen, weil Sie selbst sind, aber Sie sollten in der Lage sein, einiges daraus zu machen. Der Trick wird darin bestehen, den richtigen "Regelsatz" zu finden, um Ihren Code als Solo-Entwickler zu bewerten, und dann die Disziplin zu haben, diese Fragen jedes Mal in einer kritischen, analytischen, gnadenlosen Stimmung zu stellen. Ich vermute, Sie möchten vielleicht zunächst Ihre eigenen 4-5 entscheidenden Fragen erörtern und sie dann im Laufe der Zeit weiterentwickeln. Einige Leute sind gegen formelle Inspektionen, weil sie so zeitintensiv zu sein scheinen ... bevor Sie entscheiden, dass sie zu teuer sind, bedenken Sie alle statistischen Beweise dafür, dass die Durchführung von Inspektionen tatsächlich die Projektzeit verkürzt. Hier ist ein Wikipedia-Link, mit dem Sie weitere Recherchen starten können:

http://en.wikipedia.org/wiki/Software_inspection

Es gab auch einige Bücher, zB Google für "Software Inspection Process" von Strauss und Ebenau.

Eine andere Möglichkeit ist, jemanden für die Inspektion eines wichtigen Projekts zu bezahlen - oder ihn gelegentlich für die Inspektion Ihres gesamten Codes zu bezahlen. Dieser Typ ist ziemlich gut, wir haben ihn einige Male ausgeflogen, um unsere neueren Entwickler zu trainieren:

http://www.javaspecialists.eu/

Abgesehen von allen Empfehlungen für die Codeüberprüfung können Sie Tools wie PMD und findBug verwenden, um den Code auf dem neuesten Stand zu halten.

Dies wurde noch nicht in eine Antwort eingefügt (wurde aber als Kommentar zu einer bestehenden Antwort hinzugefügt)

Überprüfen Sie Ihren Code nach einem erholsamen Schlaf. Beginnen Sie den Tag beispielsweise mit der Überprüfung des Codes, den Sie am Vortag geschrieben haben.

Dies gibt Ihnen natürlich nicht die kollektive Erfahrung eines Teams, aber es gibt Ihnen die Möglichkeit, den Code aus einer neuen Perspektive zu überprüfen.

Wenn Sie beispielsweise einen Code mit einem bösen Hack hinterlassen haben, sind Sie möglicherweise nicht dazu geneigt, ihn zu reparieren, wenn Sie den Code unmittelbar danach überprüfen. Schließlich kennen und akzeptieren Sie das Vorhandensein dieses Hacks, wenn Sie mit der Überprüfung Ihres Codes beginnen. Aber wenn Sie gut geschlafen haben, sind Sie wahrscheinlich motivierter, eine bessere Lösung zu finden.

Wenn wir schlafen, hört das Gehirn tatsächlich nicht auf, an den Problemen zu arbeiten, die wir haben, sodass Sie möglicherweise dort eine Lösung finden, obwohl sich diese Lösungen manchmal auf seltsame Weise anbieten .