Wie man Vereinbarungen auf Codebasis mit Kollegen trifft, wenn man unterschiedliche Meinungen hat

Ich arbeite als Frontend-Entwickler und habe einen neuen Kollegen in meinem Team. Er ist erfahrener als ich, aber ich weiß mehr über die Anwendung, an der wir arbeiten.

Also machen wir die Code-Review des Codes des anderen und ich weiß, dass er sehr auf Code-Styling und Konsistenz in der gesamten Anwendung steht.

Jetzt habe ich seinen Code überprüft und einige Vorschläge zum Code-Styling und zu Konventionen gemacht, und ich habe immer begründet, warum ich das für besser halte.

Er antwortete auf meine Vorschläge im Wesentlichen, indem er sagte, dass er nicht einverstanden sei, und gab einige Beispiele.

Ich habe seine Aussage dann erneut anhand dieser Beispiele beantwortet und versucht, erneut zu erklären, warum ich es so vorziehe, wie ich es vorgeschlagen habe.

Er antwortete dann, er möchte dieses Gespräch verschieben. Ich nehme an, dass er mir immer noch nicht zustimmt, und ich werde es nie erraten. Und ich denke, diese Diskussion wird nie wieder auftauchen.

Meine Frage ist, wie ich ihn dazu bringen kann, mir zuzustimmen, ohne ihn zu zwingen? Und was soll ich tun, wenn er in meinen Punkten nie einer Meinung sein wird? Ich mag es auch nicht, dass er beschlossen hat, diese Diskussion zu verschieben. Soll ich ihn fragen, wann wir das dann besprechen?

Viele IDEs erlauben Formatierungsregeln. Wo ich arbeite, vermeiden wir Ihr Problem vollständig, indem wir einen vordefinierten Satz von Codierungsstilen haben und das automatische Format die Dateien nach diesen Regeln formatiert. Als einziger Zeitstil kommt dann "Bitte auto-formatieren Sie Ihren Code" und das war's. Die Regeln wurden im Unternehmen vereinbart und können diskutiert werden, aber jeder muss sich an das halten, was vereinbart wurde.
Wir verwenden Linters und IDEs, aber es geht mehr darum, die Regeln herauszufinden, denen wir folgen wollen. und das sorgt für viele diskussionen.
Warte mal, wer von euch plädiert für "Verbesserungen", die sich vom aktuellen Hausstil / Art und Weise, wie man Dinge tut, unterscheiden. Du oder er?

Antworten (2)

Das passiert fast überall (du bist also nicht allein). Ich gebe dir den Rat, den ich allen gebe:

Hören Sie auf, in Ihren Code-Reviews stilistische/kosmetische Ideale zu kommentieren.

Ja, es wäre schön, wenn eine Codebasis stilistisch konsistent wäre, aber die Realität ist, dass dies niemals passieren wird, wenn 2 oder mehr Personen an einem Projekt arbeiten. Es kann so anfangen, aber es wird nie so enden. Hier ist eine Liste dessen, worauf ich bei einer Codeüberprüfung in der Reihenfolge ihrer Wichtigkeit achte:

  1. Logikfehler
  2. Verpasste Anforderungen
  3. Edge-Fälle
  4. Stil (nur wenn der Code keinen Sinn ergibt und überarbeitet werden muss)

Wenn ich meinen gesamten Code-Review-Prozess durchlaufe und nichts finde, was nicht zu diesen 4 Dingen passt, dann könnte ich den Stil kommentieren und sehr deutlich machen, dass es nur meine Präferenz ist. Ich tue dies, weil ich nicht glaube, dass ein Code-Review jemals keine Vorschläge für den Autor enthalten sollte. Solange der Code sinnvoll ist, kommentieren Sie den Stil nicht, es sei denn, es gibt buchstäblich nichts anderes zu kommentieren.

Selbst dann soll dies wirklich nur zeigen, dass Sie den Code tatsächlich gelesen haben und in der Lage sind, Vorschläge zu machen. Wenn der Kollege den von Ihnen empfohlenen stilistischen Ansatz nicht implementieren möchte, lassen Sie es in Ruhe (es sei denn, es führt zu Lesbarkeitsproblemen / ist bis zum Refactoring verwirrend).

Meiner Meinung nach, wenn Ihr Code-Review hauptsächlich aus Styling besteht, überprüfen Sie ihn möglicherweise nicht genug. Ich kann an einer Hand abzählen, wie oft ich mich nur zum Stil äußern konnte.

Ich würde mich schon freuen, wenn nur eine Person an dem Projekt arbeitet und es einen einheitlichen Stil in der gesamten Codebasis gibt. Aber wenn es keine automatischen Werkzeuge für Einrückungen und dergleichen gibt, haben Sie normalerweise kein Glück.
Mir gefällt Ihre Bewertung von Code-Reviews und was darin zu sagen ist, aber ich möchte einen Punkt hinzufügen. Auch positives Feedback ist erlaubt. Wenn etwas wirklich cool ist, spricht nichts dagegen, darauf hinzuweisen!
@simbabque Ich stimme voll und ganz zu, ich mache das auch. Vor allem für neuere Leute. Etwas zu sagen wie „Mir gefällt wirklich, wie du mit X umgehst“ oder „Ich hätte nicht an Y gedacht“ kann zu ihrem Selbstvertrauen und Selbstwertgefühl beitragen
Was ist, wenn Sie sich zu einem Randfall äußern, dem aber auch nicht zustimmen können (z. B. „dieser Randfall ist ‚unmöglich‘ usw.?“). Sie brauchen immer noch einen Weg, um Meinungsverschiedenheiten zu lösen.
An diesem Punkt müssten Sie eine Diskussion führen. Wenn Sie Ihre Vorschläge (schriftlich) gemacht haben, führen Sie eine Diskussion. Wenn der Autor nur stur ist und es nicht will, ist das sein gutes Recht. Sie haben es während einer Codeüberprüfung angesprochen, und es liegt an dieser Person, sicherzustellen, dass die Kommentare aus der Codeüberprüfung implementiert werden. Wenn sie sich dagegen entscheiden, hoffen sie besser, dass der Grenzfall nicht auftaucht, denn es sieht ziemlich schlecht aus, wenn er identifiziert wurde und sie sich dagegen entschieden haben.
"Hören Sie auf, in Ihren Code-Reviews stilistische/kosmetische Ideale zu kommentieren.". Könnte in einem kleinen Unternehmen arbeiten, aber versuchen Sie, Code für ein multinationales Ingenieurbüro zu schreiben, und kommen Sie damit durch. Pferde für Kurse, etc...

Der wichtige Aspekt besteht darin, die „er sagte, ich sagte“-Diskussion aus der Gleichung herauszunehmen.

Sie brauchen ein paar Dinge an Ort und Stelle;

  1. Ein definierter Codierungsstandard. Ignorieren Sie alles, was bereits in Ihren Repos veröffentlicht wurde; Definieren Sie, wie ein gut geschriebener Code für die Zukunft aussehen würde.
  2. Ein definierter Workflow zum Verschieben von Code durch Entwicklung, Peer-Review, QA-Review und Veröffentlichung. Diese Workflow-Definition würde den nächsten Punkt beinhalten ...
  3. Ein statisches Codeanalysetool wie Lint (andere sind verfügbar, abhängig von Ihren Entwicklungssprachen). Wenn der Code die Lint-Prüfung nicht besteht, sollte er nicht zur Peer-Review weitergeleitet werden.

Codierungsstandards sind wichtig. Es gibt immer noch Raum für Individualität in der Art und Weise, wie der Code geschrieben wird, aber ein Basissatz von Codierungsstandards bedeutet, dass zukünftige Entwickler schnell auf die Codebasis kommen können.

Sie werden eine große technische Schuld in der bestehenden Codebasis haben, aber das ist erledigt und funktioniert - gehen Sie weiter, nicht rückwärts. Diese technische Schuld wird als Projekt für alle zukünftigen Entwickler dienen, die dem Team beitreten.

Wie man Vereinbarungen auf Codebasis mit Kollegen trifft, wenn man unterschiedliche Meinungen hat
AntwortenHierDatenschutz-Bestimmungen1y, 0v