Ich arbeite derzeit in einem Projekt mit 3 anderen Entwicklern. Einer von ihnen hat keine wirkliche Erfahrung mit einer der Technologien, die wir verwenden (ein ORM), aber er ist höher in der Hierarchie und nimmt Kritik nicht gut an, besonders von denen in den Rängen unter ihm (wie ich).
Er ist unzufrieden damit, wie die Technologie funktionieren soll, und richtet alle möglichen Problemumgehungen ein, um das Tool nicht so zu verwenden, wie es verwendet werden soll.
Ich kann sehen, dass diese Problemumgehungen dem Projekt langfristig schaden werden, ich habe es ihm bereits gesagt, aber er war einfach anderer Meinung, sagte, dass ich falsch liege, und machte weiter.
Ich habe darüber nachgedacht, einfach darauf zu warten, dass er den Code in das Repository schiebt und ihn dann trotzdem ändert, aber ich möchte ihn nicht so umgehen. Ich habe darüber nachgedacht, zum Manager zu gehen und ihm zu sagen, was los ist, aber ich möchte nicht dieser Typ sein. Um ehrlich zu sein, denke ich gerade darüber nach, etwas zu tun, was ich hasse – die Chatprotokolle zu speichern, um zu beweisen, dass ich widersprochen habe, und den Dingen ihren Lauf zu lassen. Ich weiß, dass es dem Projekt schaden wird, aber alle anderen Optionen scheinen mir zu schaden .
Was ist schlimmer? Unprofessionell zu sein und das Projekt negativ beeinflussen zu lassen oder professionell zu sein und von meinen Kollegen gehasst zu werden? Er wird mich hassen, wenn ich entweder ändere, was er getan hat (nachdem er meine Korrekturen ausdrücklich abgelehnt hat) oder dem Manager von ihm erzähle.
Edit: Einige Leute sind anscheinend skeptisch. Dude verwendet ein ORM (Doctrine2), das einige Einschränkungen bezüglich der Vererbung auf mehreren Ebenen aufweist. Alle „Blätter“ müssen sich in der obersten Klasse DiscriminatorMap befinden, und daher sind ihre IDs FKs, die auf die oberste Klasse in der Hierarchie zeigen, nicht auf die unmittelbaren Eltern der Klasse. Er hielt es für wichtiger, Blätter zu haben, die auf ihre Eltern zeigen, und die Zuordnung falsch zu halten (er stimmt nicht zu, dass die Aufgabe eines ORM darin besteht, die Datenbank zu verwalten, er möchte dies manuell tun -- "nein, so wird die Datenbank sein falsch"). Offensichtlich hat eine defekte Zuordnung einige der nativen Funktionen von Doctrine-Repositories (wie z. B. findOneBy) beschädigt. Seine Lösung bestand darin, die fehlerhafte Zuordnung beizubehalten und die nativen Funktionen von Doctrine zu überschreiben, um das Problem zu „beheben“.
Im Allgemeinen müssen Sie einfach Ihren Job machen .
Wenn Ihre Aufgabe darin besteht, die Arbeit anderer in Ihrem Team zu überprüfen (möglicherweise durch eine formelle Codeüberprüfung), müssen Sie sie überprüfen, Ihre Ergebnisse präsentieren und mit den Konsequenzen leben.
Wenn Ihre Aufgabe nicht darin besteht, die Arbeit anderer zu überprüfen, müssen Sie sie loslassen.
Oft führen in der Softwarewelt viele Wege zum „gut genug“. Auch wenn die Herangehensweise Ihres Kollegen anders sein kann als Ihre (und „falsch“ sein kann oder auch nicht), liegt die von ihm gewählte Herangehensweise möglicherweise außerhalb Ihrer Kontrolle. Wenn ja, lassen Sie es los und machen Sie mit der Arbeit weiter, die wirklich Ihr Job ist.
Die Ausnahme hier ist, wenn jemand einen kritischen Fehler macht, der anderen körperlich oder finanziell schaden könnte. In diesem Fall sollten Sie erwägen, der Whistleblower zu sein, mit dem Vorgesetzten zu sprechen und die Konsequenzen zu akzeptieren (Ausgrenzung durch Ihre Kollegen usw.). Wenn Sie diesen Weg gehen, stellen Sie sicher, dass Sie mit Ihrer Schlussfolgerung richtig liegen, und stellen Sie sicher, dass das Risiko, zu schweigen, zu hoch ist.
Zusätzlich zu der Antwort von Joe Strazzere, wenn Sie so leidenschaftlich daran interessiert sind, Ihr Lieblings-ORM richtig zu verwenden, wie wäre es, wenn Sie einen Anwendungsfall nehmen und Ihrem Kollegen zeigen, wie Dinge explodieren können? Und wenn die Dinge reibungslos verlaufen, bringen Sie dem Typen bei, wie man das Ding benutzt.
Eines der wichtigsten Dinge, die Sie meiner Meinung nach tun können – Sie können in Code-Review-Meetings auf die Probleme hinweisen, die Sie vorhersehen, und Lösungen dafür vorschlagen. Wenn andere Reviewer das Problem nicht sehen, müssen Sie natürlich einen Anwendungsfall bereithalten für Probleme, die Sie sehen. Ich weiß aus ORM-Erfahrung, dass, wenn Sie es nicht richtig machen, es die traumatischste Sache zum Debuggen/Reparieren sein kann. Von der Reaktionszeit der Anwendung bis hin zu beschädigten Daten.
Als Entwickler ist meine oberste Priorität am Ende des Tages das Wohlergehen der Anwendung/des Projekts. Ich arbeite daran, effizienten Code zu schreiben, der seine Höchstleistung erbringt und nicht kaputt geht. Dafür werde ich bezahlt und das ist mein größtes Interesse bei der Arbeit.
Sie müssen ein gutes Argument zu Papier bringen, warum die Verwendung des ORM in der beabsichtigten Weise besser ist. Dies muss den unmittelbaren Nutzen und den langfristigen Nutzen spezifizieren. Sie müssen auch alle seine Bedenken ansprechen, die er hat, wenn es darum geht, das ORM so arbeiten zu lassen, wie es beabsichtigt war. Du musst seine Ängste beruhigen, deshalb ändert er es. Wenn Sie all diese Dinge organisiert aufschreiben und in einem Meeting mit den anderen beiden Entwicklern besprechen können, haben Sie vielleicht eine Chance, ihn von Ihrem Ansatz zu überzeugen.
Stellen Sie sicher, dass Sie bereits mit dieser Technologie gearbeitet haben. Erläutern Sie, wie Sie es richtig verwendet haben, und es sind keine Probleme aufgetreten. Zeigen Sie ihm auch, dass die Entwicklergemeinschaft rund um dieses Tool Sie sehr dazu ermutigt, das ORM seine Magie wirken zu lassen.
IDrinkandIKnowThings
IDrinkandIKnowThings
Enderland
Pedro Cordeiro
Pedro Cordeiro
Alex
AakashM