Respekt für Mitentwickler [geschlossen]

Eine Sache, die in einer solchen Situation helfen kann, ist Code-Reviews für alle Änderungen zu verlangen. Es ist weniger wahrscheinlich, dass Menschen sinnlose Änderungen vornehmen, wenn eine andere Person sie zuerst überprüfen muss. Wenn sie tatsächlich einen anderen Entwickler davon überzeugen können, dass ihre Veränderung eintreten sollte, ist es vielleicht doch nicht so sinnlos.

  

... entscheidet sich, Ihren Code oder die   Schnittstellen zu Ihrem Code nur weil   er / sie mag das nicht   Variablen- / Klassennamen, die Sie verwendet haben.

     

Mein wirkliches Problem damit ist, dass (a)   es ist eine Verschwendung von Zeit und (b) es zeigt a   eklatante Respektlosigkeit gegenüber dem Kerl   Entwickler, der den Code in der geschrieben hat   erster Platz.

     

Meine viszerale Antwort ist zu peitschen ...

Ich sehe einige sehr interessante Dinge in diesen Aussagen.

1. Benennung ist WIRKLICH, WIRKLICH wichtig. Es lohnt sich, den Code neu zu schreiben, damit er korrekt ist.
2. Es ist nicht IHR Code
3. Wie ist es respektlos?

Sie nehmen es zu persönlich.

Ich habe einmal mit jemandem zusammengearbeitet, der ausgeflippt ist, als ich "seinen" Code geändert habe. Sein Code ist so schrecklich; es war fehlerhaft und nicht zu pflegen. Er blieb immer zu spät, kämpfte gegen Feuer und zerbrach Dinge - im Grunde genommen ein negativer Faktor. Ich schrieb seinen ganzen schlechten Code für ein großes Stück Funktionalität für ein Projekt an einem Wochenende um und als er am Montag zurückkam, hatte er einen Zischanfall. Ich sage nicht, dass deine Sachen schrecklich sind, aber vielleicht musst du dich beruhigen und objektiver sein.

Nimm es nicht so persönlich. Geh zurück und denke darüber nach - vielleicht musste "dein" Code korrigiert werden

Wir könnten vielleicht bessere Antworten geben, wenn Sie den Code und die Änderungen oder zumindest eine bessere Vorstellung von der Situation mit ein oder zwei Beispielen veröffentlichen.

BEARBEITEN: Nachdem ich gesehen habe, dass der Code geändert wurde und herausgefunden habe, dass der Build fehlerhaft ist, muss ich den Ton dieser Antwort ändern. Ich verstehe Steve Frustration - und ich stimme zu - das ist keine gute Veränderung. Es macht eine bestimmte Typdefinition allgemeiner und nicht sehr beschreibend.

Während ich denke, dass einige meiner Punkte gültig sind, sieht es in diesem Fall so aus, als seien die Änderungen nicht angebracht.

Das Problem des "Eigentums" des Codes ist irrelevant. Wenn die Codeänderungen nutzlos sind, sollte jeder im Team nicht glücklich sein. Wenn sie gute Veränderungen sind, dann sollte sich jeder darüber freuen. Wenn es Meinungsverschiedenheiten gibt, müssen Sie alle einen gemeinsamen Nenner finden.

Das Bauen zu brechen ist keine gute Sache.

Steve, tut mir leid, wenn ich hart heruntergekommen bin - es sieht so aus, als ob Sie in diesem Fall gerechtfertigt sind, aber nicht weil es "Ihr" Code ist.

Heey,

Jungs! Wir alle müssen zu TALK !

Sitze einfach zusammen und SPRECHE ! Es gibt immer Gründe, sich zu ändern, und es gibt immer Gründe dafür.

Entscheiden Sie gemeinsam !

Gehen Sie nicht einfach zu StackOverflow oder einem Forum und sagen Sie diese Art von Fragen.

Der neue Entwickler tut es - er bekommt Antworten von der Community wahrscheinlich positiv ( yeahh, schlechter Code sollte umgestaltet werden ).
Der aktuelle Entwickler tut es - er bekommt auch Antworten von der Community: " Was für ein Idiot könnte solche Veränderungen machen! "

Und das Ergebnis ist: Eine kontraproduktive, destruktive, beleidigende Umgebung für eine lange Zeit.

Wer will es?

Nur setzen Sie Ihre Argumente auf den Tisch und das war's.
New Dev braucht auch eine Einführung.
Der alte Entwickler muss TOO auflisten.

Dies sollte kollaborative Arbeit sein UND sich nicht gegenseitig verärgern.

Entscheidet zusammen, redet als DAS TEAM .

Und ... stellen Sie besser Fragen wie "Wie ist es besser, das zu überarbeiten?"

Prost.

In jedem Softwareentwicklungsteam mit einer Größe & gt; 1, Standardisierung ist der Schlüssel. Nicht nur für jeden Entwickler, um den Code des anderen zu verstehen, sondern damit die Leute, die in 2 Jahren, 5 Jahren und 10 Jahren kommen, jeden Teil des Codes betrachten und ein klares und konsistentes Muster sehen können. Werden Sie ... und der Rest des Teams ... immer noch da sein und jahrelang an diesem Projekt arbeiten?

Wenn Sie beide "nur Ihre Art, Dinge zu tun" haben und es keinen formellen Standard für das Projekt / die Firma gibt, schlage ich vor, dass Sie mit dem Team und / oder Ihrem Chef zusammenarbeiten, um einen formellen Standard vorzuschlagen. Es gibt bereits viele Standards für die verschiedenen Umgebungen, die Sie entweder als Standard oder als Ausgangspunkt verwenden können.

Wenn es einen formellen Standard gibt, ist jeder im Team verpflichtet, es zu befolgen ... egal wie "besser" sie sich ihren Weg vorstellen.

So viel zu den harten Fähigkeiten.

Jetzt auf der Soft-Skills-Seite ...

Sie und Ihr Kollege müssen eine gesunde Beziehung entwickeln oder sich dafür entscheiden, an verschiedenen Orten zu arbeiten. Tit-for-tats, die dazu führen, dass Menschen das Gefühl haben, dass sie auspeitschen wollen, werden alle unglücklich machen, ganz zu schweigen davon, dass sie das Projekt, für das alle bezahlt werden, ernsthaft gefährden. Suchen Sie nach einer Person, die Sie beide respektieren (vielleicht Ihrem Chef, vielleicht einem respektierten und besonnenen leitenden Mitglied des Teams, vielleicht HR, wenn Sie eine gute Personalabteilung haben). Erklären Sie dieser Person, was das Problem ist und dass Sie sich unbewertet und respektlos fühlen. Bitten Sie um Hilfe, sprechen Sie mit Ihrem Kollegen über die Situation und vereinbaren Sie eine bessere Art der Zusammenarbeit.

Schließlich müssen Sie offen sein für die Möglichkeit, dass Ihr Kollege subjektiv korrekte Änderungen vornimmt, auch wenn die Art und Weise, wie er es tut, Sie beleidigt. Trennen Sie die korrekte Codierung von den richtigen zwischenmenschlichen Interaktionen. Mach das Richtige für das Projekt.

Nun, wenn dieser Typ deinen Code pflegen will, lass ihn machen, was er will. Denken Sie daran, dass es nicht "Ihr" Code ist. Der Code gehört zu der Firma, für die Sie arbeiten. Du hast den Code geschrieben und du wurdest dafür bezahlt. Lassen Sie das Management tun, was immer Sie damit machen wollen.

Nimm die Dinge nicht persönlich, mach weiter.

Manchmal kann das Ändern von Namen gerechtfertigt sein. Es kann verwirrend sein, wenn die Hälfte des Projekts sich auf das Geschlecht einer Person bezieht, und dann checken Sie einen neuen Code ein, der auf Geschlecht oder etwas verweist. Okay, das könnte ein schlechtes Beispiel sein, da sie technisch gesehen zwei verschiedene Dinge sind und ihre Bedeutung wahrscheinlich immer noch offensichtlich ist. Wenn der Code eines Projekts jedoch zwei verschiedene Begriffe verwendet, um auf dasselbe Konzept zu verweisen, kann das verwirrend sein.

Normalerweise versuche ich, den Code der Leute in Ruhe zu lassen, es sei denn, ich habe eine Begründung für das Refactoring. Glücklicherweise scheint das auch für meine Kollegen zu gelten, also nein, ich hatte noch keine Notwendigkeit, eine solche Charta zu schreiben.

Wie wäre es mit einem automatisierten Build-System? Wenn diese Person also den Code ändert und etwas unterbricht, erhält das Team eine Warnung. Dies löst Ihr Problem damit, dass Sie Ihre Zeit damit verschwenden müssen, etwas zu reparieren, das von jemandem gebrochen wurde. Auf diese Weise wird jeder wissen, dass der eine und der andere etwas verändert hat und den Build durchbrochen hat und für sich selbst sehen kann. Die Regel lautet: "Brechen Sie den Build nicht".

Sie sollten dies mit der Person besprechen, die es getan hat, in einer nicht bedrohlichen Art und Weise.

Ich glaube, jeder Entwickler sollte Verantwortung übernehmen und daher einen Teil des Codes besitzen, aber nicht den gesamten Code. Ich verstehe den Code, den ich besser geschrieben habe (unabhängig davon, wie gut / schlecht es ist) als jeder andere Typ, der es jemals gesehen hat. Daher werden die von mir vorgenommenen Änderungen schneller und weniger fehleranfällig.

Es macht mir nichts aus, wenn jemand den Code ändert, den ich später geschrieben habe, aber ich habe ein paar Bedingungen:

1. Wenn du den Code änderst und dadurch etwas anderes kaputt geht, bist du dafür verantwortlich, und nicht ich.
2. Wenn ich mit den von Ihnen vorgenommenen Änderungen nicht einverstanden bin, werde ich sie so ändern, wie ich es möchte, da ich in Zukunft die Verantwortung für diesen Code übernehmen muss.

Nicht alle Entwickler sollten ständig Änderungen am gesamten Code vornehmen. Nur ein Teil der Zeit, um den Code kennenzulernen (Wissen teilen).

Ich habe noch nie für einen Arbeitgeber gearbeitet, der eine Richtlinie "Jeder kann jederzeit etwas ändern" unterstützt. Entwickler besitzen bestimmte Teile des Codes und sie werden aufgefordert, Änderungen / Refactoring basierend auf einer Entwicklungsdemokratie durchzuführen.

Du berührst meinen Code und brichst etwas, (1) Du hast einen guten Grund für die Veränderung, der alle Entwickler zustimmen, und (2) Du solltest kaputte Dinge lieber nicht kaputt lassen oder mich bitten, die Aufräumarbeiten zu machen Sie, wenn Sie nicht mein Vorgesetzter sind. Ich werde demütigen, wenn das der Fall ist.

Ich stimme Laurence zu, dass Code-Reviews helfen könnten. Dies ist eine Frage, wie Ihr Team zusammenarbeiten sollte. Was könnte helfen, ist der Begriff der Egoless Programmierung - kurz gefasst, in Anbetracht der Code als ein gemeinsames Produkt von das Team, und versuchen, Entscheidungen wegen des Codes zu treffen, und nicht wegen des Ego des Programmierers. Ihr Teamkollege hat gegen das vierte Gebot der egolosen Programmierung verstoßen <: / a> - "Code nicht ohne Rücksprache neu schreiben" Vielleicht, wenn Ihr Team auf diese Prinzipien aufmerksam gemacht wird, werden sich die Dinge verbessern. Ich würde das versuchen.