Was sagen Sie in einer Codeüberprüfung, wenn die andere Person eine überkomplizierte Lösung erstellt hat? [geschlossen]

Neulich habe ich den Code überprüft, den jemand in meinem Team geschrieben hat. Die Lösung war nicht voll funktionsfähig und das Design viel zu kompliziert - das heißt, es wurden unnötige Informationen gespeichert, unnötige Funktionen erstellt, und im Grunde hatte der Code eine Menge unnötiger Komplexität wie Vergolden, und es wurde versucht, nicht vorhandene Probleme zu lösen.

In dieser Situation frage ich: "Warum wurde das so gemacht?"

Die Antwort ist, dass die andere Person Lust hatte, es so zu machen.

Dann frage ich, ob eine dieser Funktionen Teil der Projektspezifikation war oder ob sie für den Endbenutzer von Nutzen sind oder ob dem Endbenutzer zusätzliche Daten präsentiert würden.

Die Antwort ist nein.

Also schlage ich vor, dass er die ganze unnötige Komplexität löscht. Die Antwort, die ich normalerweise bekomme, ist "Nun, es ist schon fertig".

Ich bin der Meinung, dass dies nicht getan wird, dass es fehlerhaft ist, dass es nicht das tut, was die Benutzer wollen, und dass die Wartungskosten höher sind, als wenn es auf die von mir vorgeschlagene einfachere Weise getan würde.

Ein äquivalentes Szenario ist: Der
Kollege verbringt 8 Stunden damit, den Code von Hand umzugestalten, was in 10 Sekunden in Resharper automatisch möglich gewesen wäre. Natürlich traue ich dem Refactoring von Hand nicht, da es von zweifelhafter Qualität und nicht vollständig getestet ist.
Wieder lautet die Antwort: "Nun, es ist schon erledigt."

Was ist eine angemessene Antwort auf diese Haltung?

Mentalität / Haltung

• Mit gutem Beispiel vorangehen
• Privat ermahnen (eins zu eins, außerhalb der Codeüberprüfung)
• Ermutigen Sie die Teammitglieder zu einer einfachen Denkweise

Team Management

• Verbringen Sie mehr Zeit mit der Spezifikation eines Arbeitselements (z. B. Architektur, Algorithmus-Gliederung, UI-Wireframe usw.).
• Ermutigen Sie die Teammitglieder, sich über den Umfang eines Arbeitselements zu informieren
• Ermutigen Sie die Teammitglieder, Möglichkeiten zur Implementierung eines Arbeitselements zu erörtern
• Nehmen Sie für jedes Arbeitselement vor Beginn angemessene Schätzungen vor und bemühen Sie sich, diese zu erfüllen
• Überwachen Sie die "Verbesserung" der Teammitglieder.
  • Prüfen Sie, ob sich das Teammitglied verbessert, nachdem Sie ermahnt oder die richtige Vorgehensweise gezeigt haben.

Spielstärke

• Planen Sie einige Zeit für Paarprogrammierungssitzungen oder Einzeltrainingssitzungen ein, um die Entwickler-Tools optimal zu nutzen (Refactoring, Code-Review).

Projekt- (Risiko-) Management

• Code-Review öfter asynchron durchführen (Hinweis)
  • Anmerkung zu "asynchron"
    • Der Code-Prüfer sollte Benachrichtigungen / Einladungen erhalten, um Änderungen zu prüfen, sobald diese festgeschrieben sind
    • Der Codeüberprüfer sollte die Möglichkeit haben, den Code vor einem Meeting mit dem Entwickler zu überprüfen.
    • Wenn eine Klärung durch den Entwickler erforderlich ist, machen Sie dies informell per IM / E-Mail, ohne eine negative Meinung abzugeben

Was sagen Sie in einer Codeüberprüfung, wenn die andere Person eine überkomplizierte Lösung erstellt hat?

Sie sagen: "Sie haben eine übermäßig komplizierte Lösung entwickelt."

Also schlage ich vor, dass er die ganze unnötige Komplexität löscht. Die Antwort, die ich normalerweise bekomme, ist "Nun, es ist schon erledigt."

Wenn es zu spät ist, um etwas zu ändern, warum führen Sie dann eine Codeüberprüfung durch?

"Es ist schon erledigt" ist keine befriedigende Antwort. Fertig bedeutet getestet und funktioniert. Jeder zusätzliche Code, der nichts Sinnvolles bewirkt, sollte ordnungsgemäß gepflegt (gelöscht) werden.

Weisen Sie ihm diese Aufgabe erneut zu und fordern Sie ihn auf, seine Lösung umzugestalten und zu optimieren. Wenn er das nicht tut, weisen Sie ihm einen Programmierer zu und hoffen, dass er etwas von dem Kollegen lernt.

Also schlage ich vor, dass er die ganze unnötige Komplexität löscht. Die Antwort, die ich normalerweise bekomme, ist "Nun, es ist schon fertig".

Das ist keine akzeptable Antwort:

• Wenn es für eine Änderung wirklich zu spät ist, ist die Überprüfung des Codes weitgehend Zeitverschwendung, und das Management muss dies wissen.

• Wenn das wirklich eine Art und Weise ist, zu sagen "Ich möchte mich nicht ändern", dann müssen Sie die Position einnehmen, dass die zusätzliche Komplexität für die Codebasis SCHLECHT ist, WEIL die Probleme / Kosten später auftreten werden. Und das Potenzial für zukünftige Probleme zu reduzieren, der wahre Grund, warum Sie die Codeüberprüfung in erster Linie durchführen.

Und ...

... die Lösung war nicht voll funktionsfähig ...

Dies ist möglicherweise eine direkte Folge der unnötigen Komplexität. Der Programmierer hat es so komplex gemacht, dass er es nicht mehr vollständig versteht und / oder er hat seine Zeit damit verschwendet, seine Komplexität anstatt der Funktionspunkte zu implementieren. Es wäre angebracht, den Programmierer darauf hinzuweisen, dass das Ausschneiden der Komplexität ihn tatsächlich schneller zu einem Arbeitsprogramm bringt.

Nun, es hört sich so an, als ob Sie nicht die Kraft (oder vielleicht das Selbstvertrauen) haben, dies "hart zurückzudrängen". Trotzdem lohnt es sich, ein bisschen Lärm darüber zu machen (ohne es zu personalisieren), in der Hoffnung, dass der beleidigende Programmierer seine Arbeit besser machen wird ... das nächste Mal.

Was ist eine angemessene Antwort auf diese Haltung?

Machen Sie das Management letztendlich darauf aufmerksam ... es sei denn, Sie haben die Möglichkeit, das Problem selbst zu beheben. (Natürlich wird dich das nicht populär machen.)

Sie hatten Recht, sie hatten Unrecht:

• gebrochenes YAGNI- Prinzip
• gebrochenes KISS- Prinzip
• ist der Code vollständig getestet? Wenn nein, dann ist es nicht getan

Was ist eine angemessene Antwort auf diese Haltung?

Führen Sie die richtige Codeüberprüfung durch. Wenn sie sich weigern, die vorgeschlagenen Änderungen ohne Grund umzusetzen, verschwenden Sie keine Zeit mehr mit einer Codeüberprüfung. Sie können das Problem auch an den Chef weiterleiten .

Eine Maßnahme, die unser Team ergriffen hat, um die Situation in solchen Fällen dramatisch zu verbessern, war der Wechsel zu viel kleineren Änderungssätzen .

Anstatt einen Tag oder länger an einer Aufgabe zu arbeiten und dann eine (große) Codeüberprüfung durchzuführen, versuchen wir, viel häufiger (bis zu 10 Mal am Tag) einzuchecken. Dies hat natürlich auch einige Nachteile, z. B. muss der Prüfer sehr reaktionsschnell sein, was seine eigene Ausgabe verringert (aufgrund häufiger Unterbrechungen).

Der Vorteil ist, dass Probleme frühzeitig erkannt und behoben werden können, bevor viel falsch gearbeitet wird.

Sie sollten sich auf die Hauptursache des Problems konzentrieren:

1. Die Ausbildung der Programmierer konzentriert sich auf die zunehmende Komplexität der Programmierer. Die Fähigkeit dazu wurde von der Schule getestet. Daher werden viele Programmierer denken, dass sie ihre Arbeit nicht richtig gemacht haben, wenn sie eine einfache Lösung implementiert haben.
2. Wenn der Programmierer dem gleichen Muster folgt, das er an der Universität hunderte Male gemacht hat, denken die Programmierer genauso - mehr Komplexität ist herausfordernder und daher besser.
3. Um dies zu beheben, müssen Sie die Anforderungen Ihres Unternehmens im Verhältnis zur Komplexität im Vergleich zu den Anforderungen, die normalerweise für die Ausbildung von Programmierern erforderlich sind , streng voneinander trennen . Ein guter Plan ist eine Regel wie "Höchste Komplexitätsstufe sollte nur für Aufgaben reserviert werden, die Ihre Fähigkeiten verbessern sollen - und sollte nicht im Produktionscode verwendet werden".
4. Für viele Programmierer wird es eine Überraschung sein, dass sie in der wichtigen Produktionscode-Umgebung nicht ihre verrücktesten Entwürfe machen dürfen . Reservieren Sie den Programmierern einfach Zeit, um experimentelle Entwürfe zu erstellen, und behalten Sie dann die Komplexität auf dieser Seite des Zauns bei.

(In der Codeüberprüfung ist es bereits zu spät, dies zu ändern.)

Ich weiß nichts, was funktioniert, nachdem der Code geschrieben wurde.

Bevor der Code geschrieben wird, können die Benutzer alternative Vorgehensweisen diskutieren. Der Schlüssel liegt darin, sich gegenseitig Ideen beizusteuern, sodass hoffentlich eine vernünftige ausgewählt wird.

Es gibt einen anderen Ansatz, der mit Auftragnehmern funktioniert - Festpreisverträge. Je einfacher die Lösung, desto mehr Geld kann der Programmierer behalten.

Sie können die Welt nicht reparieren.

Sie können nicht einmal den gesamten Code in Ihrem Projekt reparieren. Sie können die Entwicklungspraktiken für Ihr Projekt wahrscheinlich nicht korrigieren, zumindest nicht in diesem Monat.

Leider ist das, was Sie bei der Codeüberprüfung erleben, nur allzu häufig. Ich habe in einigen Organisationen gearbeitet, in denen ich häufig 100 Codezeilen durchgesehen habe, die in zehn Zeilen hätten geschrieben werden können, und ich habe die gleiche Antwort erhalten, die Sie erhalten haben: "Es ist bereits geschrieben und getestet" oder "Wir suchen" Bugs, keine Neugestaltung. "

Es ist eine Tatsache, dass einige Ihrer Kollegen nicht so gut programmieren können wie Sie. Einige von ihnen mögen ziemlich schlecht darin sein. Mach dir darüber keine Sorgen. Ein paar Klassen mit schlechten Inplementierungen werden das Projekt nicht zum Erliegen bringen. Konzentrieren Sie sich stattdessen auf die Teile ihrer Arbeit, die sich auf andere auswirken. Sind die Unit-Tests angemessen (falls vorhanden)? Ist die Schnittstelle verwendbar? Ist es dokumentiert?

Wenn die Schnittstelle zum fehlerhaften Code in Ordnung ist, kümmern Sie sich nicht darum, bis Sie ihn warten müssen, und schreiben Sie ihn dann neu. Wenn sich jemand beschwert, rufen Sie einfach das Refactoring an. Wenn sie sich immer noch beschweren, suchen Sie nach einer Position in einer anspruchsvolleren Organisation.

Das Projekt sollte eine Standardrichtlinie enthalten, die die verfügbaren Qualitätsprüfungsverfahren und -werkzeuge steuert.

Die Leute sollten wissen, was sie tun sollen und welche Tools für die Verwendung in diesem Projekt akzeptiert werden.

Wenn Sie dies noch nicht getan haben, organisieren Sie Ihre Gedanken und tun Sie es.

Die Codeüberprüfung sollte eine Checkliste mit Standardelementen enthalten. Wenn Sie "es ist schon erledigt" bekommen und es nicht, dann persönlich, möchte ich nicht für die Arbeit dieses Entwicklers als Projektmanager oder Senior-Entwickler verantwortlich sein. Diese Haltung darf nicht toleriert werden. Ich kann verstehen, wie man etwas oder sogar alles streitet, aber sobald eine Lösung akzeptiert ist, sollte Lügen nicht toleriert werden und das sollte klar gesagt werden.

Ihr Shop muss einige Entwurfsmethoden durchsetzen.

• Anforderungen müssen klar definiert sein.
• Sie müssen Anwendungsfälle entwickeln, die die Anforderungen unterstützen.
• Sie müssen Funktionen angeben, die zur Implementierung der Anwendungsfälle erforderlich sind.
• Sie müssen alle nicht funktionalen Anforderungen (Reaktionszeiten, Verfügbarkeit usw.) angeben.
• Sie benötigen eine RTM (Requiements Tracabilty Matrix), um jede Systemfunktion einem Anwendungsfall und einer tatsächlichen Anforderung zuzuordnen.
• Löschen Sie alle Funktionen, die eine tatsächliche Anforderung nicht unterstützen.
• Schließlich markieren Sie in Ihrer Codeüberprüfung alle Codes, die die definierten Funktionen nicht direkt implementieren oder unterstützen.

Wahrscheinlich nicht, dass es zu kompliziert ist, weil sich die meisten Menschen danach schlecht fühlen. Ich gehe davon aus, dass in diesem Fall bereits viel Code geschrieben wurde, ohne ein Wort darüber zu verlieren. (Warum ist das so? Weil diese Person über genügend Autorität verfügt, sodass ihr Code in der Realität nicht überprüft werden muss?)

Ansonsten sollte die Codeüberprüfung weniger formal, aber häufiger erfolgen. Und bevor Sie große Module schreiben, sollten Sie vielleicht schnell über die Vorgehensweise sprechen.

Wenn Sie "das ist zu kompliziert" sagen, kommen Sie nicht weiter.

Es ist bedauerlich, aber Code Reviews sind oftmals mehr für die Zukunft als für die Gegenwart. Insbesondere in einer Unternehmensumgebung ist ausgelieferter Code immer wertvoller als nicht versendeter Code.

Dies hängt natürlich davon ab, wann die Codeüberprüfung abgeschlossen ist. Wenn dies Teil des Entwicklungsprozesses ist, können Sie jetzt einen gewissen Nutzen daraus ziehen. Wenn die CR jedoch eher als post mortem behandelt wird, sollten Sie am besten darauf hinweisen, was in Zukunft besser gemacht werden könnte. Weisen Sie in Ihrem Fall (wie andere bereits gesagt haben) auf YAGNI und KISS im Allgemeinen und möglicherweise auf einige der spezifischen Bereiche hin, in denen diese Grundsätze angewendet werden könnten.

Was bedeutet zu kompliziert? Wenn Sie eine mehrdeutige Aussage treffen, erhalten Sie als Antwort eine mehrdeutige / unbefriedigende Antwort. Was für einen Menschen zu kompliziert ist, ist für einen anderen perfekt.

Der Zweck einer Überprüfung ist es, auf bestimmte Probleme und Fehler hinzuweisen, nicht zu sagen, dass Sie sie nicht mögen, was die Aussage "übermäßig komplex" impliziert.

Wenn Sie ein Problem sehen (zu kompliziert), sagen Sie etwas Konkreteres wie:

• Würde das Ändern von Teil X in Y den Code nicht vereinfachen oder das Verständnis erleichtern?
• Ich verstehe nicht, was Sie hier in Teil X tun. Ich denke, Sie haben versucht, dies zu tun. Präsentieren Sie eine sauberere Vorgehensweise.
• Wie hast du das getestet? Hast du das getestet? Wenn es zu kompliziert ist, führt dies normalerweise zu leeren Blicken. Wenn Sie nach Tests fragen, wird die Person häufig aufgefordert, ihren Code selbst zu vereinfachen, wenn sie nicht herausfinden konnte, wie der ursprüngliche Code getestet werden kann.
• Hier scheint ein Fehler zu vorliegen, durch Ändern des Codes in diesen wird das Problem behoben.

Jeder kann auf Probleme hinweisen, besonders auf zweideutige. Es gibt eine viel kleinere Untergruppe, die Lösungen präsentieren kann. Ihre Überprüfungskommentare sollten so spezifisch wie möglich sein. Zu sagen, dass etwas zu komplex ist, bedeutet nicht viel. Es kann sogar dazu führen, dass andere denken, SIE seien inkompetent, weil Sie den Code nicht verstehen können. Denken Sie daran, dass die meisten Entwickler keine Ahnung haben, ob es sich um ein gutes oder ein schlechtes Design handelt.

Manchmal lohnt es sich, sich als Gruppe auf einige der "agilen" Prinzipien zu konzentrieren - sie können einer Gruppe oder einem Individuum helfen, die ein wenig vom Kurs abzuweichen scheinen.

Das Fokussieren muss keine große Umarbeitung Ihres Teams bedeuten, aber Sie sollten sich alle hinsetzen und besprechen, welche Praktiken für Sie als Team am wichtigsten sind. Ich würde vorschlagen, zumindest diese (und wahrscheinlich noch einige mehr) zu diskutieren:

• Machst du die einfachste Sache, die funktionieren könnte?
• Sie werden es nicht brauchen (lösen Sie Probleme, die nicht in der Spezifikation waren)
• Schreiben Sie den Test vor dem Codieren (Hilft Ihnen, Ihren Code zu fokussieren)
• Wiederhole dich nicht

Auch gelegentliche (wöchentliche?) Überprüfungen dessen, was funktioniert, was nicht und was noch benötigt wird, können sehr hilfreich sein. Wenn nichts anderes, warum nicht eine Stunde pro Woche einplanen, um Teamwerte und -praktiken zu diskutieren?

Eskalation, wenn Sie einen technisch versierten Manager haben. Das klingt nach einer Gewohnheit, die abgebrochen werden muss.

Wenn der Code nicht gemäß Spezifikation erstellt wurde, sollte die Codeüberprüfung per Definition fehlschlagen. Ich verstehe das Konzept nicht: "Nun, wir haben etwas getan, wonach niemand gefragt hat, und es funktioniert nicht. Deshalb lassen wir es dort, anstatt etwas zu tun, wonach jemand gefragt hat."

Dies ist eine schlechte Angewohnheit für jeden Entwickler. Wenn er / sie an einer Designspezifikation gearbeitet hat, dann ist es ein Nein Nein, wenn sie nicht ohne guten Grund übereinstimmt.

Ein Wort: agil

Es löst sicher nicht alles. Sie sollten jedoch diese Fehler vermeiden, indem Sie Ihre Iterationen (z. B. 1-2 Wochen) einschränken, die laufende Arbeit einschränken und die Planung / Überprüfung von Sprints wirksam einsetzen. Sie benötigen eine bessere Übersicht darüber, was tatsächlich getan wird - während es getan wird.

Für eine normale projektbasierte Entwicklung würde ich einen Scrum- Ansatz empfehlen . Erwägen Sie für Umgebungen mit kontinuierlicher Entwicklung / Integration, insbesondere wenn viele Entwickler an einem oder mehreren verwandten Projekten arbeiten, die Einbindung von Kanban- Elementen . Ein weiterer wirksamer Ansatz ist die Nutzung der Paarprogrammierung , einer definierten Praxis der Extremprogrammierung .

Ihre Situation ist kaum einzigartig. Und selbst in kleinen Teams kann der Prozess erheblich dazu beitragen, die aktuelle Situation zu vermeiden. Mit der richtigen Transparenz und einem angemessenen Rückstand werden Fragen wie diese zu Planungsentscheidungen im Sprint - und ersparen Ihnen die Verwaltung technischer Schulden .

Was ich in der Vergangenheit gesagt habe, ist: "Dieser Code ist komplex und ich bin nicht sicher, was er versucht, ist es möglich, ihn zu vereinfachen oder klarer zu schreiben?"

Sie müssen den Code nach dem Löschen / Zurücksetzen codieren.

"Meine nächste Bewertung ist in 20 Minuten.

"Schönen Tag."

Akzeptiere KEINE Argumente!

Fertig, IMHO

Chris