Es kann schwierig sein, Änderungen in einem Softwareentwicklungsprozess zu verursachen. Insbesondere, wenn Sie nicht von Natur aus die Person sind, die den Prozess "besitzt" (ich gehe davon aus, dass dies nicht der Fall ist, wenn Sie die Struktur der Organisation beschreiben).

Sehen Sie sich die Kultur und Strategie der Führung an . Interessieren sie sich für die Softwarequalität? Ich weiß, dass diese Frage schwer zu beantworten ist, aber Sie werden wahrscheinlich keine qualitätsbezogene Initiative vorantreiben können, wenn es keine Kultur der Akzeptanz von Qualität gibt.

Jedes Mal, wenn ich einen Änderungsvorschlag mache, Wenn Sie einen Leistungsindikator oder eine Metrik aufrufen möchten, suche ich nach drei Dingen, die mir bei der Entscheidung helfen, ob mein Vorschlag bestehen bleibt oder nicht:

1. Ist er umsetzbar? Gibt es eine vernünftige Annahme, dass die Codeüberprüfung tatsächlich zu spezifischen Änderungen führt? Wissen Ihre Teamkollegen, wonach sie suchen? Gibt es einen Softwarestandard, gegen den das Team arbeitet? Wird es aufgrund des von Ihnen vorgeschlagenen Prozesses tatsächlich spezifische Verbesserungen geben?
2. Ist dies messbar? Möchten Sie, dass die Software nach der Überprüfung "besser" wird? Oder möchten Sie speziell, dass es weniger Fehler gibt? Verfolgen Sie Fehler?
3. Ist es strategisch? Ist (messbar stetig verbessert) die Qualität der Software für das Unternehmen von Bedeutung? Gibt es implizite oder explizite Erwartungen an die Führung oder ein klar definiertes Endziel oder einen klar definierten Weg nach vorne? Können Sie zeigen, dass die Softwarequalität einen direkten Einfluss darauf hat, dass das Unternehmen seine Ziele erreicht?
ol>

Viele Menschen haben viele großartige Ideen, und es gibt immer Möglichkeiten für jeden Prozess (Softwareentwicklung) enthalten) kann verbessert werden - aber IME ist es selten, dass Vorschläge in eine Gruppe aufgenommen werden, es sei denn, sie bestehen diese drei Tests.

Ich habe Folgendes versucht: Bitten Sie sie einfach, vorsichtig zu sein und kritisch

Kein Wunder, dass das nicht funktioniert hat. Sie müssen wahrscheinlich viel spezifischer sein. "Sei vorsichtig" ist nicht hilfreich. "Können Sie mir helfen, indem Sie meinen Code auf XYZ-spezifische Fehler überprüfen?" "Können Sie sicherstellen, dass ich angemessen kommentiert habe?" usw.

Nach jeder zu schnellen Überprüfung wird darauf hingewiesen, dass es sehr schnell ging.

Siehe oben

Aufmerksamkeit auf sich ziehen Dinge, bei denen ich mir nicht sicher bin, wenn ich Code zur Überprüfung einreiche

Wahrscheinlich Ihre beste Idee!

Fragen zu dem Code stellen, den ich einreiche, um sie zu erzwingen um es zu studieren

Waren die Fragen speziell mit der Verbesserung der Codequalität verbunden, oder haben Sie nur versucht, sie dazu zu bringen, den Code tatsächlich zu lesen? Ich habe das Gefühl, dass Sie Letzteres gemeint haben, was Ihnen nicht hilft, die drei oben genannten Tests zu bestehen.

Überprüfen Sie ihren Code gemäß den Standards, von denen ich erwarten würde, dass sie meinen p überprüfen >

Welche Standards? Haben Sie einen tatsächlichen, dokumentierten Standard? Oder erwarten Sie nur, dass sie die Dinge verstehen, die Sie in ihrem Code finden?

Außerdem möchte ich nur sagen: Willkommen in der realen Welt! Ich finde, dass es üblich ist, dass Absolventen (die es oft gewohnt sind, sich im luftleeren Raum zu entwickeln und daran gewöhnt sind, dass ihre Arbeit inspiziert / benotet wird) mit dem Mangel an Formalität in der realen Welt zu kämpfen haben, insbesondere wenn sie in kleinen Teams und bei arbeiten neuere Unternehmen.

Ein Punkt - Die Dinge sind für alle Teams unterschiedlich. Wenn also etwas nicht funktioniert, versuchen Sie es anders.

Zwei Punkte

• verschiedene Leute sind gut darin und mögen es, verschiedene Dinge zu tun. Sie können Leute dazu bringen, Dinge zu tun, aber es ist eine Verschwendung ihrer Talente.
• Es scheint, dass Sie Codeüberprüfungen verwenden, aber keinen Zweck für sie haben.

Eins

Im ersten Fall sollten Sie sich vielleicht überlegen, wie Codeüberprüfungen ausgeführt werden. In der Vergangenheit habe ich gesehen, dass es von Leuten an ihrem Schreibtisch separat gemacht wurde, und sie haben nur einen Code "ok" oder "abgelehnt", wie sie es für richtig halten. Dies ist effizienter, bedeutet jedoch weniger Kommunikation. Sie können diese Aufgabe auch "solo" ausführen lassen und dann ein- bis zweimal pro Woche die Codeüberprüfungen als Gruppe durchgehen, um die Kommunikation zu verbessern.

Zwei

Der zweite Punkt wirft * die Frage auf: Warum erwarten Sie, dass Ihre Teamkollegen Ihre Fehler in Codeüberprüfungen auffangen? Ich habe sie nie wirklich gesehen, es sei denn, es ist ein ziemlich offensichtlicher Fehler.

Sie sind nicht ausfallsicher zum Testen (so sollten Ihre Fehler abgefangen werden, bevor die Codeüberprüfung überhaupt stattfindet), sondern eher

• Wissensaustausch
• stilistische Konsistenz

Ich werde nicht näher darauf eingehen, warum Sie versucht haben, fehlgeschlagen zu sein. Es läuft darauf hinaus, "Sie geben kein konkretes Ziel", obwohl ich es tun werde Beachten Sie Folgendes:

• Überprüfen ihres Codes gemäß den Standards, von denen ich erwarten würde, dass sie meinen
  • Sicher überprüfen. Dies könnte funktionieren - wenn Sie jemanden nerven, nervt er Sie auf die gleiche Weise, weil er implizit versucht, Ihnen zu zeigen, wie nervig Sie sind (zeigen, nicht sagen). Aber ich denke nicht, dass dies ein idealer Weg ist, um Codeüberprüfungen zum Laufen zu bringen.

Ihr Fehler ist, dass niemand im Team versteht, was das ist Die Codeüberprüfung dient dazu, was das Ziel ist und warum sie es tun.

Sie tun es jedoch , sodass sie verstehen, dass es wichtig ist. Das ist das größte Hindernis, und Sie haben es überwunden. Jetzt müssen Sie ihnen ein Verständnis dafür vermitteln, dass die Codeüberprüfung für den Wissensaustausch bestimmt ist.

Aber vielleicht besitzt Ihr Team alle ihre eigenen Bereiche, sodass Sie die Datenbank besitzen, Danny das Front-End besitzt und Sam das Back-End betreibt . Sie werden Schwierigkeiten haben, Codeüberprüfungen in diesem System zum Laufen zu bringen, da sich niemand wirklich darum kümmert oder weiß, was die andere Person tut.

Vielleicht müssen Sie stattdessen die Arbeit funktionsübergreifend teilen?

Sie müssen sich überlegen, warum Sie die Codeüberprüfungen wollten. Wenn es darum geht, Fehler zu erkennen, müssen Sie in erster Linie ordnungsgemäß testen. Wenn es darum geht, die Teamkommunikation zu verbessern, verbringen sie natürlich weniger Zeit mit Suchen und mehr Zeit mit Kommunikation.

Codeüberprüfungen "weil ich sie in einem Blog gelesen habe" sind weder hilfreich noch überzeugend. Sie zu tun, "weil es die Klarheit des Codes verbessert", aber wenn Sie die Klarheit des Codes nicht messen können, ist es schwer zu zeigen, dass sie funktionieren, nicht wahr?

• Entschuldigung, Puritaner! Sie haben diesen verloren.

Es ist keine High School , sagen Sie diese Wörter:

Diese Codeüberprüfung ist nicht gründlich genug.

Hinweis - Sagen Sie diese Worte entweder Ihrem Vorgesetzten oder den Kollegen.

"Sie sind nicht in der High School", wie sie sagen.

Es ist ein Arbeitsplatz, der einzige Zweck des Unternehmens und der Mitarbeiter ist es, entscheidend Geld zu verdienen. Sprechen Sie deutlich.

Übrigens kann dies Ihnen helfen:

Ich schlage immer vor ..

Was würde Richard Branson sagen?

(Sie können den nationalen Geschäftshelden in Ihrem eigenen Land oder in Ihrer eigenen Kultur ersetzen.

Sagen wir genau, dass dies Richard Branson passiert ist (hypothetisch gesehen ist er ein junger Programmierer.) Was würde er sagen? sein Kollege?

Diese Codeüberprüfung ist nicht gründlich genug. Wiederholen wir sie.

Was würde er seinem Chef sagen?

Jacks Codeüberprüfung ist nicht gründlich genug. Lassen Sie es uns wiederholen.

Einfacher geht es nicht. Denken Sie eine halbe Sekunde lang, er würde Zeit damit verschwenden, darüber nachzudenken ... ...... noch etwas? Nein, er würde die obigen Sätze sagen.

Das kannst du auch!

Es ist schwierig, Fehler in einer Codeüberprüfung zu finden. Der Prüfer muss die gesamte Logik des Codes durcharbeiten, um einen obskuren Fehler zu finden - ohne Gewissheit, dass überhaupt ein Fehler vorliegt.

Es ist einfach zu überprüfen, ob Kommentare vernünftig aussehen, wenn Namen sinnvoll sind. und wenn der Code gut strukturiert ist. Sie können auch Fehler wie nicht initialisierte Variablen erkennen, obwohl dies auch ein statisches Code-Analyse-Tool tun könnte.

Wenn Sie Fehler finden möchten, führen Sie mehr Tests und bessere Tests durch. Speichern Sie die Leute für kreative Dinge.

Wir haben ein Formular (ein Word-Dokument), das die Dinge angibt, nach denen bei einer Codeüberprüfung gesucht werden soll. Dinge wie:

• Es werden geeignete Namenskonventionen und Kommentare verwendet.
• Minimieren Sie das Vorhandensein von totem Quellcode.
• Wenn immer möglich, werden starke Datentypen verwendet / li>
• Berechnungen mit NULL-Parametern oder Null-Nenner werden nicht richtig behandelt, was ungültige Wertrückgaben ermöglicht.
• Vermeidung eingebetteter SQL- oder DB-Verbindungen
• Lesbarkeit des Quellcodes in Bezug auf Einrücken, Funktionsbenennung, Datenfluss
• usw. (40+ Elemente in der Liste)

Für jedes Element gibt es ein Kontrollkästchen Pass / Fail / NA mit einem Platz für Kommentare zu diesem Artikel. Dann gibt es einen Gesamtdurchlauf, einen Durchgang mit Ausnahmen oder einen Ablehnungsabschnitt mit einem Kommentarbereich.

Für uns als regulierte Branche ist eine ordnungsgemäße Codeüberprüfung erforderlich, bevor Code verschoben wird - Web, SQL-Skript usw. - in eine Produktionsumgebung. Dies ist Teil der Versionsdokumentation. Wenn wir geprüft werden, ob dies nicht Teil des Release-Pakets ist, kann es zu Geldstrafen und / oder zum Verlust von Arbeitsplätzen kommen.

Viel Glück dabei. Codeüberprüfungen sind etwas, das einige Entwickler nicht mögen und einige Manager nicht betonen. Nachdem sie ein Problem mit Code haben, das nicht ausreichend überprüft wurde, werden sie den Punkt bekommen.

Ich empfehle Ihrem Chef, Github zu verwenden. Es hat eine nette Community-Funktion, in der Kommentare und Bewertungen angeregt werden. Sie haben ein Unternehmenskonto zur Verfügung.

Dinge, die Sie erzwingen können (dies funktionierte, als wir Github hatten):

1. Haben Sie eine Person, die Pull-Anfragen genehmigt, aber nur, wenn es zwei gibt Daumen hoch und alle "TODO" oder Fragen beantwortet
2. Weisen Sie eine oder mehrere Personen zu, die Pull-Anfragen überprüfen. Es kann zufällig oder von Gebietsexperten sein.
3. Alle Fragen müssen beantwortet werden, bevor der Pull in die Hauptniederlassung aufgenommen werden kann.
ol>

Auch das Erstellen eines Code-Handbuchs fördert die Einhaltung. Wie Funktionsnamen, Tabulatoren, Variablennamen, Framework, Einschränkungen der If-else-Ebene, Einschränkungen der Funktionsgröße usw. Auf diese Weise kann jeder zumindest zu nicht akzeptablem Code Stellung nehmen, und darüber hinaus sind sich alle über ein einfach zu lesendes Format einig. Github kann dies auf viele Arten durchsetzen.