Making something a function is not only for reuse but also to reduce complexity. Moving 6 lines of code out of a 20-line block is good, moving two lines out proly not, so it depends what you did.

You need to discuss the whys, not the whats. Ask all the time why, might help you understand how others (later maintainers) see your code.

And insist on politeness if he is rude, things can always be discussed polite.

Peer review is opinion-based. He's not your boss. You can take the information constructively, or you can ignore it altogether. If he's pointing out things that are objective (i.e. ways to measurably improve performance, maintainability, reliability, scalability) work with those, but with the other stuff you can't let it bother you so much. Someone's always going to have an opinion different from yours.

Peer Review ist in der Branche weit verbreitet. Es hört sich für mich so an, als würden Sie es persönlich nehmen, wenn jemand etwas über Ihren Code sagt, was daran zu erkennen ist, dass Sie ihm "zeigen" möchten, was mit seinem Denken / Code nicht stimmt.

Mein erster Rat ist: immer mit der Ruhe. Mein Rat ist, zu versuchen, das, was sie sagen, von "kritisch" bis vielleicht "schön zu haben" zu priorisieren.

Auf der anderen Seite denke ich manchmal, dass Unternehmen eine inkonsistente Struktur haben, wenn es um Code-Review / Peer-Review geht. In erster Linie sollte eine "Best Practice" -Richtlinie festgelegt werden, wenn es um die Codierung geht. Von Namenskonventionen bis hin zur Integration von Datenbanken in den Code sollten Dinge festgelegt werden. Es muss nicht auf branchenweiten Best Practices basieren, sondern sollte lose darauf basieren und in Ihre Branche passen.

Einige Orte haben ungeschriebene Best Practices, aber ich denke, die meisten Orte fehlen . Was ich tun würde, ist zuerst die Person zu bitten, ihre Kommentare von "kritisch, muss haben" bis "schön zu haben" zu priorisieren. Wenn ALLES kritisch ist, muss und Sie keine bewährten Methoden haben, würde ich zum Chef gehen und erklären, dass es bewährte Methoden geben muss, da die Codeüberprüfung einer Person sehr locker ist, während eine andere überkritisch ist, um alles zu ändern Befolgen Sie jedoch keine festgelegten Richtlinien.

Denken Sie daran, dass das allgemeine Ziel der Peer Review darin besteht, dass jemand Ihren Code überprüft, um festzustellen, ob Sie geschäftslogische, sicherheitsrelevante oder allgemein leicht lesbare Codes übersehen. Ich schlage vor, einige Codierbücher in die Hand zu nehmen und zu prüfen, ob etwas, was diese Person sagt, mit dem übereinstimmt, was in der Branche am besten bekannt ist. Wenn das, was er sagt, weit verbreitet ist und andere in Ihrem Unternehmen zustimmen, würde ich diese Person eher als Mentor sehen als als jemanden, der "Sie herausholen" will.

Bearbeiten: Wenn Sie der Meinung sind, dass dieser Mitarbeiter schlecht ist, versuchen Sie, Open-Source-Code auf github einzureichen. Es ist sicher, dass Ihr Code in 95% der Fälle abgeschossen wird. Sie können sich nicht von Emotionen antreiben lassen. Stattdessen muss man es vom Standpunkt des allgemeinen Konsenses aus betrachten und was jeder für das Beste hält. Es gibt Zeiten, in denen ich eine Woche lang an einem Code arbeite und dieser einer Peer-Review unterzogen wird. Letztendlich entscheiden wir uns, dies nicht zu tun, und ich speichere ihn einfach. Manchmal kommt es zurück, manchmal geht es tot. Nimm es einfach nicht persönlich.

Blaming is a bad title. He is not blaming you for a program crashing that was not you fault. He is disagreeing with some code practices. There some code practices that are clearly bad (repeated code blocks) and lot in the middle that people are not going to all agree on. Try and turn it into acceptable code practices rather than best. Is a single use function acceptable - I hope yes. Try and get it moved from optimal code to acceptable. Does it perform? Can it be maintained?

Ein Teil des Bürolebens, insbesondere für Programmierer, besteht darin, manchmal mit etwas herausfordernden Persönlichkeiten umzugehen. Sie können Sie beleidigen, Ihre Gefühle verletzen.

Manchmal versuchen Sie, die guten Teile zu extrahieren und die schlechten Teile zu verlassen. Ich hatte einen ehemaligen Chef, bei dem Sie häufig Schimpfwörter verwendeten. Es würde mich nerven, aber ich habe mir auf die Oberlippe gebissen.

Wenn er sagt "Diese Codezeile sieht aus wie @ # $ @ * & und ich bin ernsthaft @ # $ @ # $ @ #" dann Ich nickte mit dem Kopf und versuchte, geduldig zu sein.

Aber eines Tages hatten wir ein Besprechungstreffen, und er überprüfte meine Leistung. Dann fragte er mich am Ende des Treffens: "Gibt es einen Vorschlag, den Sie für mich haben?" Und ich sagte: "Nun, ich habe das Gefühl, dass Sie die Sprache ein wenig abschwächen können."

Danach bemerkte ich einen wirklich starken Rückgang der schlechten Langugae. Daher denke ich, dass der beste Zeitpunkt für Ratschläge die Leistungsbeurteilung sein kann. Aber wenn es ein ernstes Problem ist, können Sie immer höflich kommunizieren. Bitten Sie um ein kurzes Treffen. Von Angesicht zu Angesicht ist besser als E-Mail. Aber sei höflich und professionell

Code reviews are mainly done for two reasons: To stop bad design and bugs to enter a code base, and to educate less experienced developers. It seems the latter is not the case here, so the idea behind the code review is to stop bad design and bugs.

In a good environment, if the reviewer finds bad design or bugs, that is appreciated and gladly fixed. There are situations where it is opinion based or style based which way to write code is the best; in that case it is absolutely fine for a reviewer to point out a way that is better, or that the reviewer thinks is better, but that isn't so much and better or so undisputed better that it is worth investing the work for a change.

Your environment seems to be toxic. Code reviews seem to have deteriorated to power fights. So your coworker demands that you remove all small functions that are called only once. Why don't you demand that he extracts code into small functions when you review his code? The outcome, if you both do as you are told, is ridiculous: You change your code to something that you feel is worse, and he changes his code to something that he feels is worse. Totally ridiculous.

What actually needs to happen is that your manager bangs your heads together and tells you how to do code reviews. The reviewer can state objections to the code, and the objections must be answered. That doesn't mean the reviewer can act as a tyrant whose orders need to be obeyed. If I told you "this function should not be a separate function but incorporated in other code" then stating "being a separate function makes this more adaptable and maintainable, and even if it where true then the benefit would be so small that it doesn't justify the effort to make the change and verify that it is correct" is a perfectly reasonable answer.

Codeüberprüfungen und Codestandards sind ein Mittel zum Zweck. Bei korrekter Ausführung besteht das Ziel nicht darin, einen Standard zu erfüllen oder eine mögliche Verbesserung in einer Überprüfung zu finden . Das Ziel besteht vielmehr darin, Software zu schreiben, die für einen bestimmten Anwendungsfall geeignet und nachhaltig / unterstützbar ist.

Anders ausgedrückt, Ihr Ziel ist nicht " perfekter "Code. Ihr Ziel ist "geeigneter" Code. Alles andere ist im Wesentlichen eine Verschwendung von Ressourcen.

Vor diesem Hintergrund lautete Ihre Frage:

Was kann ich hier also noch tun?

Zuerst müssen Sie das Feedback Ihres Mitarbeiters filtern: Ist es hilfreich, Ihren Code auf den gewünschten Standard zu bringen?

1. Wenn ja: Integrieren Sie das Feedback und fahren Sie fort. Es ist leicht zu fühlen, dass er dich persönlich angreift. Sie müssen in der Lage sein, persönliche Emotionen von Ihrer Arbeit zu trennen. Wir alle werden manchmal Lücken in unserem Arbeitsprodukt haben, deshalb machen wir Reviews.
2. Wenn nein: Lassen Sie ihn sein Stück sagen und geben Sie keine emotionale oder argumentative Antwort. Wenn Sie antworten, spielen Sie in sein Spiel (das Spiel, das Sie in Ihrem Update Ihrer Frage bestätigt haben). Zum Spielen eines Spiels sind zwei Personen erforderlich. Wenn Sie aufhören zu spielen, wird das Spiel beendet!
ol>

Wenn es in Ihrer Umgebung keine dokumentierten Standards gibt: Es ist schwieriger, die Entscheidung zwischen dem ersten und dem zweiten Fall zu treffen dein eigener Richter sein. Der Haupttrick ist jedoch, sein Spiel nicht zu spielen. Drehen Sie dies stattdessen um und konzentrieren Sie sich darauf, das hilfreiche Feedback herauszufiltern, das Sie einbeziehen können, und zu lernen, das nicht hilfreiche Feedback zu ignorieren.

Egal, wo Sie arbeiten oder welchen Job Sie haben, es wird immer Leute geben, die nichts anderes wollen, als darauf hinzuweisen, dass Sie nicht gut genug sind oder besser als Sie. Eine der grundlegendsten Lebenskompetenzen, auf die Sie sich konzentrieren können - sowohl für Ihre persönliche Zufriedenheit als auch um sicherzustellen, dass Sie sich als Mitarbeiter verbessern -, besteht darin, zu lernen, wichtige Dinge aus Dingen herauszufiltern, die dies nicht tun.

es ist ein Argumentationsspiel, ein Wissensspiel. Wer ist besser im Code. Imo.

Ich denke, das ist Ihr größtes Problem. Es ist kein Spiel, es ist ein kollaborativer Prozess, um etwas Besseres zu schaffen. Sie müssen lernen, nicht mehr an Gewinnen und Verlieren zu denken. Ich verstehe, warum du so fühlst, wie du es tust, weil es die menschliche Natur ist. Aber mit Erfahrung und pflegendem Vertrauen können Sie dies überwinden und die Gelegenheit schätzen, über Ihre Ansichten nachzudenken.

Es würde viele Kritikpunkte geben, die nicht gültig sind und mit denen Sie nicht einverstanden sind. Sie können sie nicht wirklich beseitigen. So wie niemand ständig fehlerfreien Code schreiben kann, kann niemand jederzeit perfekte Urteile fällen. Sie müssen eine Lücke schließen, nicht zuletzt, weil Sie es auch tun.

Wenn dies passiert, sollten Sie fragen, ob dies erhebliche negative Auswirkungen auf die Codebasis haben würde, wenn ich der Empfehlung folge, mit der ich nicht einverstanden bin? . Wenn nein, folgen Sie der Empfehlung. Die Leute fühlen sich gut, also bekommen Sie dort zumindest Wert. Wenn ja, wägen Sie die beiden Optionen erneut sehr sorgfältig ab. Manchmal geht es nicht nur um Technologie, sondern auch um Menschen. Wirklich gute Entwickler können mit Code UND Menschen arbeiten. Wenn Sie nach dem Abwägen des menschlichen Faktors immer noch der Meinung sind, dass die Auswirkungen netto-negativ sind, sprechen Sie sich dagegen aus. Stellen Sie jedoch sicher, dass Sie IMMER zuerst versuchen, den Grund für die Empfehlung herauszufinden! In vielen Fällen haben Sie diesen Standpunkt noch nicht bemerkt. Und dann wachsen Sie als Entwickler.

Vergessen Sie den Stolz, er ist weit überbewertet!

Lösen Sie die Probleme, indem Sie sie beheben.

• Ihre Funktion wird nur einmal verwendet.

Ehrlich gesagt kann eine Funktion, die nur einmal verwendet wird, leicht verwendet werden inline. Vielleicht gibt es einen guten Grund, es nicht zu inline. Wenn ja, nutzen Sie diesen Grund.

Ich weiß nicht, was dieser Grund sein könnte, aber ich weiß, dass wenn die Funktion wirklich nur einmal verwendet wird, sie nicht durch Tests verwendet wird. Das heißt, Sie haben keinen Komponententest für die Funktion. Schreiben Sie eine, und dann haben Sie eine bessere Codequalität (nicht unbedingt eine bessere Lösung, aber zumindest ein Beweis dafür, dass die Lösung das tut, was beabsichtigt war). Sie haben auch zwei Stellen, an denen die Funktion verwendet wird.

Der Versuch, Wege zu finden, auf denen beide Seiten ein bisschen von dem bekommen können, was sie wollen, kann sich wie eine lästige Pflicht anfühlen. Aber auf lange Sicht werden Sie effektiver sein.

Ich glaube ich verstehe, ich hatte einen Freund, der sich in der gleichen Situation befand. Seine Teamkollegen mochten ihn aus Gründen der Persönlichkeit nicht und standen seinem Code äußerst kritisch gegenüber, während sie viel größere Fehler miteinander übersahen. Sie hielten seinen Code an hohen Standards fest, die sie im Wesentlichen erfanden, so dass er sie unmöglich richtig machen konnte. Am Ende zeigte er nur allen den Mittelfinger und ging.

Vielleicht kann Ihr Manager sie schelten, da sie die Produktion aufhalten, indem sie das Feedback der Bewertungen nutzlos aufblähen, aber im Fall meines Freundes war es ihm egal . Wenn das nicht hilft und Sie dort weiterarbeiten möchten, ist mein Rat, sich darauf zu konzentrieren, zu verstehen, warum sie Sie nicht mögen, und das zu ändern. Andernfalls müssen Sie lernen, Ihre Emotionen zu kontrollieren und die Kritik zu ertragen, auch wenn Sie unfair sind.

Meine Empfehlung ist, dass Sie das Buch Die sanfte Kunst der verbalen Selbstverteidigung von Suzette Hayden-Elgin lesen. Es wird Ihnen helfen, mit Menschen umzugehen, die im Umgang mit Ihnen weniger als professionell sind.