it-swarm.dev

Wie kann ich während der Überprüfung taktvoll Verbesserungen des schlecht gestalteten Codes anderer vorschlagen?

Ich glaube fest an sauberen Code und Code-Handwerkskunst, obwohl ich derzeit einen Job habe, bei dem dies nicht als oberste Priorität angesehen wird. Ich befinde mich manchmal in einer Situation, in der der Code eines Peers durcheinander mit chaotischem Design und sehr wenig Sorge um zukünftige Wartung ist, obwohl er funktionsfähig ist und wenig bis gar keine Fehler enthält.

Wie können Sie Verbesserungen bei einer Codeüberprüfung vorschlagen, wenn Sie der Meinung sind, dass so viel geändert werden muss und eine Frist ansteht? Denken Sie daran, dass das Vorschlagen von Verbesserungen nach der Frist bedeuten kann, dass die Priorität insgesamt aufgehoben wird, wenn neue Funktionen und Fehlerbehebungen hinzukommen.

134
Yony
  1. Überprüfen Sie Ihre Motivation. Wenn Sie der Meinung sind, dass der Code geändert werden sollte, sollten Sie in der Lage sein, einen Grund zu formulieren, warum Sie der Meinung sind, dass er geändert werden sollte. Und dieser Grund sollte konkreter sein als "Ich hätte es anders gemacht" oder "es ist hässlich". Wenn Sie nicht auf einen Nutzen hinweisen können, der sich aus Ihrer vorgeschlagenen Änderung ergibt, ist es nicht sinnvoll, Zeit (a.k.a. Geld) für die Änderung aufzuwenden.

  2. Jede Codezeile im Projekt ist eine Zeile, die gepflegt werden muss. Code sollte so lang sein, wie es sein muss, um die Arbeit zu erledigen und leicht verständlich zu sein, und nicht länger. Wenn Sie den Code verkürzen können, ohne die Klarheit zu beeinträchtigen, ist das gut. Wenn Sie es schaffen und gleichzeitig die Klarheit erhöhen, ist das viel besser.

  3. Code ist wie konkret: Es ist schwieriger, ihn zu ändern, nachdem er eine Weile gesessen hat. Schlagen Sie Ihre Änderungen frühzeitig vor, wenn Sie können, damit sowohl die Kosten als auch das Risiko von Änderungen minimiert werden.

  4. Jede Änderung kostet Geld. Das Umschreiben von Code, der funktioniert und wahrscheinlich nicht geändert werden muss, kann zu unnötigem Aufwand führen. Konzentrieren Sie sich auf die Abschnitte, die Änderungen unterliegen oder die für das Projekt am wichtigsten sind.

  5. Form folgt Funktion und manchmal auch umgekehrt. Wenn der Code unordentlich ist, besteht eine höhere Wahrscheinlichkeit, dass er auch Fehler enthält. Suchen Sie nach diesen Fehlern und kritisieren Sie eher die fehlerhafte Funktionalität als die ästhetische Attraktivität des Codes. Schlagen Sie Verbesserungen vor, mit denen der Code besser funktioniert und , um die Überprüfung des Codes zu vereinfachen.

  6. Unterscheiden Sie zwischen Design und Implementierung. Eine wichtige Klasse mit einer beschissenen Oberfläche kann sich durch ein Projekt wie Krebs ausbreiten. Dies wird nicht nur die Qualität des restlichen Projekts beeinträchtigen, sondern auch die Schwierigkeit erhöhen, den Schaden zu reparieren. Auf der anderen Seite sollte eine Klasse mit einer gut gestalteten Oberfläche, aber einer miesen Implementierung keine große Sache sein. Sie können die Klasse jederzeit erneut implementieren, um eine bessere Leistung oder Zuverlässigkeit zu erzielen. Wenn es richtig funktioniert und schnell genug ist, können Sie es in Ruhe lassen und sich sicher fühlen, dass die Kruft gut eingekapselt ist.

Um alle oben genannten Punkte zusammenzufassen: Stellen Sie sicher, dass Ihre vorgeschlagenen Änderungen einen Mehrwert bieten.

162
Caleb

Es gibt einen Sweet-Spot für die Wertschöpfung durch Refactoring. Änderungen müssen drei Dinge bewirken:

  • code verbessern, der sich wahrscheinlich ändert
  • klarheit erhöhen
  • kosten am wenigsten Aufwand

Überlegungen:

  1. Wir wissen, dass sauberer Code kostengünstiger zu schreiben und zu warten ist und mehr Spaß macht, daran zu arbeiten. Ihre Aufgabe ist es, diese Idee an Menschen in Ihrem Unternehmen zu verkaufen. Denken Sie wie ein Verkäufer, nicht wie ein arroganter Nörgler (dh nicht wie ich).
  2. Sie können nicht gewinnen, Sie können nur weniger verlieren.
  3. Konzentrieren Sie sich darauf, echten Mehrwert zu schaffen - nicht nur Schönheit. Ich mag es, wenn mein Code schön aussieht, aber manchmal muss ich akzeptieren, dass preiswerte Dinge wichtiger sind.
  4. Ein guter Weg, um den Sweet Spot zu finden, besteht darin, dem Pfadfinderprinzip zu folgen. Wenn Sie an einem Codebereich arbeiten, lassen Sie ihn immer in einem besseren Zustand, als Sie ihn gefunden haben.
  5. Eine kleine Verbesserung ist besser als keine Verbesserung.
  6. Nutzen Sie automatisierte Werkzeuge. Zum Beispiel können Tools, die nur ein bisschen Formatierung bereinigen, einen world Unterschied machen.
  7. Verkaufen Sie andere Ideen, die im Übrigen die Klarheit des Codes verbessern. Zum Beispiel fördert das Testen von Einheiten das Zerlegen großer Methoden in kleinere.
16
Kramii

Wenn der Code ohne schwerwiegende Fehler funktioniert und eine wichtige Frist (wie bei Effekt-Gewinn- und Verlustrechnung oder Unternehmens-PR) unmittelbar bevorsteht, ist es zu spät, Verbesserungen vorzuschlagen, die größere Änderungen erfordern. Selbst Verbesserungen am Code können Risiken für die Projektbereitstellung verursachen. Die Zeit für Verbesserungen war früher im Projekt, als mehr Zeit für Investitionen in die zukünftige Robustheit der Codebasis blieb.

14
hotpaw2

Die Codeüberprüfung dient drei Zwecken:

  1. Auf Fehler prüfen

  2. Überprüfen Sie, wo der Code verbessert werden kann

  3. Lehrmittel für jeden, der den Code geschrieben hat.

Bei der Bewertung der Design-/Codequalität geht es natürlich um # 2 und # 3.

So weit wie # 2:

  • Machen Sie SEHR klar, welche Vorteile die vorgeschlagenen Änderungen gegenüber den zu behebenden Kosten haben. Wie bei jeder Geschäftsentscheidung sollte es sich um eine Kosten-Nutzen-Analyse handeln.

    Z.B. "Der X-Ansatz für das Design würde die Wahrscheinlichkeit des Auftretens von Fehler Y bei der Änderung von Z erheblich verringern, und wir wissen, dass dieser Code alle 2 Wochen Änderungen vom Typ Z erfährt. Die Kosten für die Behandlung von Produktionsausfällen aufgrund von Fehler Y + Auffinden des Fehlers + Das Reparieren und Freigeben der Fix + Opportunitätskosten, wenn die nächsten Talente nicht geliefert werden, ist $A; Die Kosten für die Bereinigung des Codes und die Opportunitätskosten (z. B. der Preis für verspäteten Versand oder mit weniger Funktionen) betragen $B. Bewerten Sie jetzt - oder lassen Sie Ihren Teamleiter/Manager - $A vs $B und entscheide.

    • Dies wird den intelligenten Teamleitern helfen, dies effektiv zu verwalten. Z.B. Sie treffen eine rationale Entscheidung unter Verwendung der vollständigen Informationen

    • Dies erhöht (insbesondere wenn Sie dies gut formulieren) IHREN Status - z. Sie sind jemand, der intelligent genug ist, um die Vorteile eines besseren Designs zu erkennen, UND klug genug, um es nicht religiös zu fordern, ohne geschäftliche Überlegungen abzuwägen.

    • UND für den wahrscheinlichen Fall, dass Fehler Z auftritt, erhalten Sie viel mehr Einfluss auf die nächsten Vorschläge.

So weit wie # 3:

  • SEHR klar definieren "muss Fehler beheben" von "Dies ist eine bewährte Methode und sollte wirklich behoben werden, wenn wir Ressourcen schonen können - siehe beigefügte Pro/Contra-Analyse" Designverbesserungen (die oben für # 2 beschriebenen Dinge anhängen) vs " Dies sind allgemeine Richtlinien, die Ihnen meiner Meinung nach dabei helfen würden, die Robustheit Ihres Codes zu verbessern, damit Sie die optionalen Änderungen des Codes einfacher verwalten können. Bitte beachten Sie den Wortlaut - es geht nicht darum, "Ihren Code so zu machen, wie ich es will" - es geht darum, "wenn Sie dies tun, erhalten Sie die Vorteile a, b, c". Der Ton und die Herangehensweise sind wichtig.
9
DVK

Ich beginne meinen Kommentar immer mit "Ich würde", was signalisiert, dass meine einfach eine von vielen Ansichten ist.

Ich gebe auch immer einen Grund an.

"ich würde diesen Block in eine Methode extrahieren weil der Lesbarkeit."

Ich kommentiere alles; groß und Klein. Manchmal mache ich mehr als hundert Kommentare zu einer Änderung. In diesem Fall empfehle ich auch die Paarprogrammierung und biete mich als Flügelmann an.

Ich versuche aus Gründen, eine gemeinsame Sprache zu etablieren. Lesbarkeit, TROCKEN, SRP usw.

Ich habe auch eine Präsentation zu Clean Code und Refactoring erstellt, in der erklärt wird, warum und wie, was ich meinen Kollegen vorgehalten habe. Ich habe es bisher dreimal gehalten, und eine von uns verwendete Beratung hat mich gebeten, es erneut für sie zu halten.

Aber manche Leute hören sowieso nicht zu. Dann bleibt mir der Rang ziehen. Ich bin der Designleiter. Die Codequalität liegt in meiner Verantwortung. Diese Änderung wird auf meiner Uhr im aktuellen Zustand nicht durchkommen.

Bitte beachten Sie, dass ich mehr als bereit bin, auf meine Kommentare zurückzutreten. Aus technischen Gründen, Fristen, Prototypen usw. habe ich noch viel über das Codieren zu lernen und werde immer auf die Vernunft hören.

Oh, und ich habe kürzlich angeboten, dem ersten in meinem Team ein Mittagessen zu kaufen, der eine nicht triviale Änderung eingereicht hat, zu der ich keinen any Kommentar hatte. (Hey, du musst auch Spaß haben. :-)

Wählen Sie Ihre Schlachten, wenn eine Frist bevorsteht, dann tun Sie nichts. Wenn jemand anderes das nächste Mal Code überprüft oder wartet und weiterhin Probleme damit hat, sollten Sie sich mit der Idee an ihn wenden, dass Sie sich als Team beim Überprüfen von Code mehr auf die Codequalität konzentrieren sollten, damit Sie später nicht so viele Probleme haben.

Sie sollten den Wert sehen, bevor sie die zusätzliche Arbeit erledigen.

[Diese Antwort ist etwas breiter als die ursprünglich gestellte Frage, da dies die Weiterleitung für so viele andere Fragen zu Codeüberprüfungen ist.]

Hier sind einige Prinzipien, die ich nützlich finde:

Privat kritisieren, öffentlich loben. Lassen Sie jemanden eins zu eins über einen Fehler in seinem Code informieren. Wenn sie etwas Brillantes getan haben oder eine Aufgabe übernommen haben, die niemand wollte, loben Sie sie bei einem Gruppentreffen oder in einer E-Mail an das Team.

Teilen Sie Ihre eigenen Fehler mit. Ich teile die Geschichte meiner katastrophalen ersten Codeüberprüfung (erhalten) mit Studenten und Nachwuchskollegen. Ich habe die Schüler auch wissen lassen, dass ich ihren Fehler so schnell erkannt habe, weil ich es vor mir selbst geschafft habe. In einer Codeüberprüfung könnte dies folgendermaßen aussehen: "Ich denke, Sie haben hier die Indexvariablen falsch angegeben. Ich überprüfe dies immer, weil ich meine Indizes falsch angegeben und ein Rechenzentrum heruntergefahren habe." [Ja, das ist eine wahre Geschichte.]

Denken Sie daran, positive Kommentare abzugeben. Ein kurzes "Schön!" oder "ordentlicher Trick!" kann den Tag eines Junior oder unsicheren Programmierers machen.

Angenommen, die andere Person ist intelligent, aber manchmal nachlässig. Sagen Sie nicht: "Wie erwarten Sie, dass der Anrufer den Rückgabewert erhält, wenn Sie dies nicht tun?" tatsächlich zurückgeben?! " Sagen Sie: "Sieht so aus, als hätten Sie die Rückgabeerklärung vergessen." Denken Sie daran, dass Sie in Ihren frühen Tagen schrecklichen Code geschrieben haben. Wie jemand einmal sagte: "Wenn Sie sich nicht für Ihren Code von vor einem Jahr schämen, lernen Sie nicht."

Speichern Sie den Sarkasmus/Spott für Freunde, die nicht an Ihrem Arbeitsplatz sind. Wenn der Code episch schrecklich ist, scherzen Sie anderswo darüber. (Ich finde es bequem, mit einem anderen Programmierer verheiratet zu sein.) Zum Beispiel würde ich die folgenden Cartoons (oder diese ) nicht mit meinen Kollegen teilen.

enter image description hereWTFs/minute

6
Ellen Spertus

Ihre Frage lautet "Wie überprüfe ich schlecht gestalteten Code?" :

Die Antwort IMO ist einfach. Sprechen Sie über das DESIGN des Codes und darüber, wie das Design fehlerhaft ist oder nicht den Anforderungen entspricht. Wenn Sie auf ein fehlerhaftes Design hinweisen oder "die Anforderungen nicht erfüllen", wird der Entwickler dies tun gezwungen, seinen Code zu ändern, weil er nicht das tut, was er tun muss.

Wenn der Code "funktional ausreichend" ist und/oder "die Spezifikation erfüllt" und/oder "die Anforderungen erfüllt":

Wenn Sie ein Peer zu diesem Entwickler sind, haben Sie keine direkte Macht, mit der Sie ihm "sagen" könnten, dass er Änderungen vornehmen soll.

Es stehen Ihnen noch einige Optionen zur Verfügung:

  1. Sie müssen Ihren persönlichen "Einfluss" (eine indirekte Form der "Macht") und/oder Ihre Fähigkeit, "überzeugend" zu sein, einsetzen.
  2. beteiligen Sie sich an der Gruppe "Code Process" Ihres Unternehmens und beginnen Sie, "Code Maintenance" zu einer höheren Priorität zu machen.
  3. Beißen Sie auf die Kugel und lernen Sie, wie Sie beschissenen Code schneller/flüssiger lesen, damit Sie nicht auf beschissenem Code hängen bleiben (es hört sich so an, als würden Sie immer wieder aufgehängt oder verlangsamt, wenn Sie auf beschissenen Code stoßen).
    • Dies macht Sie auch zu einem stärkeren Programmierer.
    • Und Sie können den beschissenen Code korrigieren, wenn Sie an beschissenem Code arbeiten.
    • Und so können Sie auch an mehr Projekten arbeiten, da viele Projekte beschissenen Code haben, der funktioniert ... aber viel beschissenen Code.
  4. Mit gutem Beispiel vorangehen. Verbessere deinen Code ... aber versuche nicht, ein Perfektionist zu sein.
    • Denn dann wirst du "der langsame Typ, der Termine nicht einhalten kann, immer kritisiert und denkt, er sei besser als alle anderen".

Ich finde, es gibt keine Silberkugel. Sie müssen alle drei verwenden und Sie müssen kreativ sein, wenn Sie alle drei verwenden.

5

Ich befinde mich manchmal in einer Situation, in der der Code eines Peers mit unordentlichem Design und sehr wenig Sorge um zukünftige Wartung durchsetzt ist, obwohl er funktionsfähig ist und wenig bis gar keine Fehler enthält.

Dieser Code ist fertig. Ab einem bestimmten Punkt werden Neugestaltungen zu kostspielig, um sie zu rechtfertigen. Wenn der Code bereits mit wenigen bis gar keinen Fehlern funktioniert, ist dies ein unmöglicher Verkauf. Schlagen Sie einige Möglichkeiten vor, um dies in Zukunft zu bereinigen und fortzufahren. Wenn der Code in Zukunft nicht mehr funktioniert, überprüfen Sie den Wert eines Redesigns erneut. Es kann niemals brechen, was großartig wäre. In jedem Fall sind Sie an dem Punkt angelangt, an dem es sinnvoll ist, darauf zu setzen, dass es nicht kaputt geht, da die Kosten jetzt oder später gleich sind: langwierige, schreckliche Neugestaltung.

Was Sie in Zukunft tun müssen, sind engere Entwicklungsiterationen. Wenn Sie in der Lage gewesen wären, diesen Code zu überprüfen, bevor alle Arbeiten zum Ausbügeln von Fehlern investiert worden wären, wäre es sinnvoll gewesen, eine Neugestaltung vorzuschlagen. Gegen Ende ist es nie sinnvoll, größere Umgestaltungen vorzunehmen, es sei denn, der Code ist grundsätzlich nicht wartbar geschrieben und Sie wissen mit Sicherheit, dass der Code bald nach der Veröffentlichung geändert werden muss.

Überlegen Sie sich angesichts der Wahl zwischen den beiden Optionen (Refactor oder kein Refactor), was sich nach einem intelligenteren Verkauf anhört:

Hey Boss, wir waren im Zeitplan und hatten alles zum Laufen, aber jetzt werden wir eine Menge Dinge neu aufbauen, damit wir in Zukunft Feature X hinzufügen können.

oder

Hey Boss, wir sind bereit zu veröffentlichen. Wenn wir Feature X jemals hinzufügen müssen, kann dies einige zusätzliche Tage dauern.

Wenn Sie eines davon sagen würden, würde Ihr Chef wahrscheinlich sagen:

Wer hat etwas über Feature X gesagt?

Das Fazit ist, dass manchmal ein bisschen technische Verschuldung Sinn macht, wenn Sie bestimmte Fehler nicht korrigieren konnten, als es billig war (frühe Iterationen). Wenn Sie ein Qualitätscode-Design haben, werden die Renditen immer geringer, je näher Sie einem abgeschlossenen Feature und der Frist kommen.

5

Wenn ein Löffel Zucker dazu beiträgt, dass die Medizin sinkt und das, was falsch ist, kurz und bündig ausgedrückt werden kann - es sind nicht 20 Dinge falsch -, führe ich mit einer Form ein, die besagt, dass ich keinen Einsatz habe, kein Ego in das investiert, was ich will gehört werden. Normalerweise ist es so etwas wie:

Ich frage mich, ob es besser wäre, ...

oder

Macht es Sinn, ...

Wenn die Gründe ziemlich offensichtlich sind, gebe ich sie nicht an. Dies gibt anderen Menschen die Möglichkeit, ein gewisses geistiges Eigentum an dem Vorschlag zu übernehmen, wie in:

"Ja, das ist eine gute Idee, denn <Ihr offensichtlicher Grund hier>."

Wenn die Verbesserung ziemlich offensichtlich ist, aber nicht so sehr, dass ich wie ein Idiot aussehe, weil ich nicht daran denke, und der Grund dafür einen Wert widerspiegelt, der mit dem Hörer geteilt wird, dann schlage ich sie manchmal nicht einmal vor, sondern:

Ich frage mich, ob es einen Weg gibt, um ... <gemeinsame Wertanweisung hier>

Dies ist nur für den Umgang mit wirklich empfindlichen Menschen gedacht - bei den meisten meiner Kollegen lasse ich sie es einfach haben!

5
Ed Staub

Codeüberprüfungen zielen nicht immer auf Verbesserungen ab.

Eine Überprüfung gegen Ende eines Projekts, wie dies hier der Fall zu sein scheint, dient nur dazu, dass jeder weiß, wo er anfangen muss, wenn Fehler auftreten (oder für ein besser gestaltetes Projekt, was möglicherweise für eine spätere Wiederverwendung verfügbar ist). Was auch immer das Ergebnis der Überprüfung sein mag, es ist einfach keine Zeit, etwas zu ändern.

Um tatsächlich Änderungen vorzunehmen, müssen Sie den Code und das Design viel früher im Projekt diskutieren - Code ist viel einfacher zu ändern, wenn er nur vorhanden ist, wenn über mögliche Ansätze gesprochen wird.

3
Tom Clarkson

Es gibt zwei bemerkenswerte Probleme in der Frage, den taktvoll Teil und den Frist kommt Teil. Dies sind unterschiedliche Themen - das erste ist eine Frage der Kommunikation und der Teamdynamik, das zweite ist eine Frage der Planung und Priorisierung.

taktvoll. Ich gehe davon aus, dass Sie gebürstete Egos und negative Rückschläge gegen die Bewertungen vermeiden möchten. Einige Vorschläge:

  • Haben Sie ein gemeinsames Verständnis für Kodierungsstandards und Designprinzipien.
  • Kritisieren oder überprüfen Sie niemals den Entwickler, nur den Code. Vermeiden Sie das Wort "Sie" oder "Ihr Code". Sprechen Sie einfach über den zu überprüfenden Code, der von jedem Entwickler getrennt ist.
  • Setzen Sie Ihren Stolz auf die Qualität des Codes abgeschlossen, sodass Überprüfungskommentare, die zur Verbesserung des Endergebnisses beitragen, geschätzt werden.
  • Vorschlagen Verbesserungen statt Nachfrage. Führen Sie immer einen Dialog, wenn Sie nicht einverstanden sind. Versuchen Sie, den anderen Standpunkt zu verstehen, wenn Sie nicht einverstanden sind.
  • Lassen Sie die Bewertungen in beide Richtungen gehen. Das heißt, Lassen Sie die Person, die Sie überprüft haben, als Nächstes Ihren Code überprüfen. Keine "Einweg" -Bewertungen.

Der zweite Teil ist das Priorisierung. Sie haben viele Verbesserungsvorschläge, aber da sich die Frist nähert, bleibt nur Zeit, einige zu beantragen.

Nun, zuerst möchten Sie vermeiden, dass dies überhaupt passiert! Sie tun dies, indem Sie fortlaufende, inkrementelle Überprüfungen durchführen. Lassen Sie einen Entwickler nicht wochenlang an einem Feature arbeiten und überprüfen Sie es dann im letzten Moment. Zweitens sollten Codeüberprüfungen und Zeit für die Implementierung von Überprüfungsvorschlägen Teil der regelmäßigen Planung und Schätzungen für jede Aufgabe sein. Wenn nicht genügend Zeit für eine ordnungsgemäße Überprüfung vorhanden ist, ist bei der Planung ein Fehler aufgetreten.

Nehmen wir jedoch an, dass dabei ein Fehler aufgetreten ist und Sie nun mit einer Reihe von Überprüfungskommentaren konfrontiert sind und keine Zeit haben, alle zu implementieren. Sie müssen Prioritäten setzen. Nehmen Sie dann die Änderungen vor, die später am schwierigsten und riskantesten zu ändern sind, wenn Sie sie verschieben.

Die Benennung von Bezeichnern im Quellcode ist für die Lesbarkeit und Wartbarkeit unglaublich wichtig. aber Es ist auch ziemlich einfach und risikoarm, Änderungen in Zukunft vorzunehmen. Gleiches gilt für die Code-Formatierung. Konzentrieren Sie sich also nicht auf dieses Zeug. Auf der anderen Seite sollte die Vernunft öffentlich zugänglicher Schnittstellen höchste Priorität haben, da sie in Zukunft nur schwer zu ändern sind. Persistente Daten sind schwer zu ändern. Wenn Sie zum ersten Mal inkonsistente oder unvollständige Daten in einer Datenbank speichern, ist dies in Zukunft nur schwer zu beheben.

Bereiche, die durch Unit-Tests abgedeckt werden, sind risikoarm. Sie können diese später jederzeit beheben. Bereiche, die nicht, aber die könnten Unit-getestet werden, haben ein geringeres Risiko als Bereiche, die können nicht Unit-getestet werden.

Angenommen, Sie haben einen großen Codeabschnitt ohne Komponententests und alle Arten von Problemen mit der Codequalität, einschließlich einer fest codierten Abhängigkeit von einem externen Dienst. Indem Sie stattdessen diese Abhängigkeit einfügen, können Sie den Codeblock testen. Dies bedeutet, dass Sie in Zukunft Tests hinzufügen und dann daran arbeiten können, den Rest der Probleme zu beheben. Mit der fest codierten Abhängigkeit können Sie nicht einmal Tests hinzufügen. Gehen Sie also zuerst zu diesem Fix.

Aber bitte versuchen Sie zunächst zu vermeiden, in dieses Szenario zu geraten!

1
JacquesB

Im Falle eines lähmend schlechten Designs sollte Ihr Fokus auf der Maximierung der Kapselung liegen. Auf diese Weise wird es einfacher, die einzelnen Klassen/Dateien/Unterprogramme durch besser gestaltete Klassen zu ersetzen.

Konzentrieren Sie sich darauf, sicherzustellen, dass die öffentlichen Schnittstellen der Komponenten gut gestaltet sind und dass die internen Abläufe sorgfältig verborgen sind. Auch Datenspeicher-Wrapper sind unerlässlich. (Große Mengen gespeicherter Daten können sehr schwer zu ändern sein. Wenn Sie also in andere Bereiche des Systems "Implementierungsblut" bekommen, sind Sie in Schwierigkeiten.).

Wenn Sie die Barrieren zwischen den Komponenten überwunden haben, konzentrieren Sie sich auf die Komponenten, die am wahrscheinlichsten größere Probleme verursachen.

Wiederholen Sie diesen Vorgang bis zum Abgabetermin oder bis das System "perfekt" ist.

1
deworde

Anstatt direkte Vorabkritik an jemandes Code zu üben, ist es immer besser, in unseren Kommentaren während der Codeüberprüfung mitzuwirken.

Ein Weg, dem ich folge, ist

  1. es wird optimal sein, wenn wir es so machen.
  2. Wenn Sie es auf diese Weise schreiben, läuft es schneller.
  3. Ihr Code ist viel besser lesbar, wenn Sie "dies", "dies" und "dies" tun.

Solche Kommentare werden ernst genommen, auch wenn Ihre Fristen anstehen. Und wird wahrscheinlich im nächsten Entwicklungszyklus implementiert.

1
Jay D

Erhöhen Sie die Qualität der Codeüberprüfungen.

Abgesehen von der Qualität des zu überprüfenden Codes gibt es eine Qualität der Codeüberprüfung selbst:

  • Sind die vorgeschlagenen Änderungen wirklich eine Verbesserung gegenüber der vorhandenen?
  • Oder nur eine Ansichtssache?
  • Hat der Rezensent richtig erklärt, es sei denn, etwas sehr Offensichtliches: warum?
  • Wie lange hat es gedauert? (Ich habe monatelange Überprüfungen gesehen, bei denen der Entwickler für die Lösung aller zahlreichen Zusammenführungskonflikte zuständig ist.).
  • Ton?

Es ist viel einfacher, eine Überprüfung des Codes von guter Qualität zu akzeptieren, als eine meist fragwürdige Ego-Pflege.

0
h22

Die Codeüberprüfung muss in den Kultur- und Entwicklungszyklus integriert werden, damit sie funktioniert. Es ist unwahrscheinlich, dass die Planung einer umfassenden Codeüberprüfung am Ende der Entwicklung von Feature X funktioniert. Zuallererst wird es schwieriger sein, Änderungen vorzunehmen, und es ist wahrscheinlich, dass sich jemand schämt - was zu Widerstand gegen die Aktivität führt.

Sie sollten frühzeitige und häufige Commits haben, verbunden mit Überprüfungen auf Commit-Ebene. Mit den vorhandenen Code-Analyse-Tools werden die meisten Überprüfungen schnell durchgeführt. Automatisierte Tools zur Code-Analyse/-Überprüfung wie FindBugs und PMD helfen Ihnen dabei, eine große Klasse von Designfehlern aus der Tür zu bekommen. Sie helfen Ihnen jedoch nicht dabei, Probleme auf architektonischer Ebene zu lösen, sodass Sie ein solides Design haben und das Gesamtsystem anhand dieses Designs beurteilen müssen.

0
kgambrah