Arbeiten Sie nicht mehr in Silos.

Je mehr Sie die Kultur haben, "auf der Hälfte der Codebasis zu bleiben", desto wahrscheinlicher ist es, dass:

• Code wird schief gehen, weil niemand Fragen stellt.
• Es wird lange dauern, bis Sie Code finden und verstehen, wenn etwas schief geht.
• Sie können nicht erklären, warum Design Es wurden Entscheidungen getroffen.
• Sie brechen am Ende etwas anderes, wenn Sie den Code "reparieren", den Sie noch nie gesehen haben.
• Sie sehen am Ende so aus, als würden Sie ihn nicht verstehen.

Da Sie gerade herausgefunden haben, dass Sie das Schuldspiel spielen, ob Sie wollen oder nicht: Letztendlich wird Ihre Antwort auf "Ich weiß nicht, das ist nicht meine" hinauslaufen Code ".

Im Moment können Sie versuchen, etwas diplomatischer zu sein:

Ich fürchte, ich bin damit nicht vertraut Teil der Codebasis.

Das ist nicht wirklich mein Stil, aber vielleicht hatte (Teamleiter) einen Grund, es so zu codieren.

Sie haben nicht Recht hineinspringen und kritisieren. Wenn Sie unterschiedliche Stile haben, ist es durchaus möglich, dass die Art und Weise, wie der Code geschrieben wird, Vorteile bietet, die Sie einfach nicht sehen. Selbst wenn nicht, hat Ihr Direktor diesen Code vermutlich schon einmal genehmigt und möglicherweise Ihren Lead eingestellt. Bieten Sie stattdessen verschiedene Methoden an: "Ich hätte diese zu einer Methode kombiniert" usw. In dieser Situation gibt es keine "gute" Antwort, sondern konzentrieren Sie sich auf die praktischen Aspekte, um den Fehler zu beheben und die Version zu testen und bereitzustellen.

... aber das wird beim nächsten Mal nicht funktionieren.

Sie haben immer noch eine Menge 'Problemcode', den Sie bis dahin ignoriert haben jetzt, kann es sich aber nicht leisten, weiter zu ignorieren. Ihr Teamleiter ist möglicherweise nicht über die Codequalität besorgt, aber wenn sein Code das nächste Mal umfällt, werden Sie gefragt, warum Sie das Problem nicht behoben haben.

• Führen Sie Codeüberprüfungen durch.
• Versuchen Sie, den Code des anderen zu dokumentieren, Randfälle zu erklären usw.
• Stellen Sie sicher, dass Ihr gesamter Code getestet wird. Führen Sie die Codeabdeckung für Ihre Tests aus.
• Teilen Sie Aufgaben so auf, dass einer von Ihnen Tests schreibt und der andere Code erzeugt, der die Tests erfüllt. Rollen tauschen.
• Wenn eine neue Entwicklung ansteht, bitten Sie darum, Aufgaben zugewiesen zu werden, die Sie dazu zwingen, mit Code zu arbeiten, den Sie zuvor noch nicht verwendet haben.

Auch wenn Sie dies tun Setzen Sie sich am Ende nicht den dunkelsten Bereichen der Codebasis Ihrer Kollegen aus. Sie werden zumindest anfangen, genügend Muster in den Dingen zu bemerken, die Ihr Kollege tut, um Fehler beim nächsten Mal schneller zu diagnostizieren.

Ehrliche, direkte Kommunikation ist in Ordnung. Bringen Sie Lösungen, keine Probleme. Sie können mit Ihrem Chef die folgenden Punkte ansprechen:

1. Sie haben festgestellt, dass das Problem mit dem Produktionscode vermeidbar war.
2. Ihr Fix hat das Problem behoben - aber nicht Erstellen Sie stabilen, wartbaren Code.
3. Empfehlen Sie Codeüberprüfungen, um zukünftige Probleme zu vermeiden.
ol>

Codeüberprüfungen sind magische Orte, an denen Nachwuchsentwickler neue Techniken und Best Practices in die Produktion einführen können, ohne die Federn zu zerzausen. Der Fokus liegt auf dem Code, nicht auf der Person. Lassen Sie sich nicht über das aktuelle Beispiel hinaus herablassen, überanweisen oder verallgemeinern. Geben Sie einfach an, dass es für diesen speziellen Fall ein nützliches Muster gibt, mit dem Sie Erfolg hatten. Seien Sie genau über ein einzelnes Problem, das bei jeder Änderung auftreten kann. "Wenn wir dies ändern, geht Speicher verloren. Wenn wir dies ändern, schlägt dies bei schlechten Eingaben wie dieser, die zuvor aufgetreten sind, ordnungsgemäß fehl." In umstrittenen Situationen wie diesen "drehen Sie den Code" - jeder überprüft den Code, aber die Person zu Ihrer Linken in der Besprechung nimmt die Änderungen vor (oder die nächstgrößere oder den nächsten Geburtstag usw.). Jeder profitiert davon und niemand verliert zu diesem Zeitpunkt das Gesicht - obwohl Menschen, die die meisten Änderungen benötigen, im Laufe der Zeit offensichtlich werden.

Beheben des Problems

Sie können entweder den gleichen "Codierungsstil" fortsetzen und die unmittelbaren Probleme beheben oder sich die Zeit nehmen, um die allgemeinen Probleme zu beheben, die dies verursachen Codesatz. Ihr Chef muss sich entscheiden. Deshalb bekommt er das große Geld.

Hoffentlich gibt es eine Art Postmortem zu diesem Problem, und Ihr Team muss entscheiden, ob Sie dem anderen Entwickler erlauben, mit der schnellen und schmutzigen Programmierung fortzufahren

Auch hier muss Ihr Chef entscheiden, wie er vorankommen soll. Ich weiß nicht, warum Ihr Chef einen scheinbar höheren Standard für die Codierung des sr-Programmierers nicht erzwingt. Die technischen Schulden mussten letztendlich von allen bezahlt werden.

Alles, was Sie tun können, ist Vorschläge zu machen und Ihr Bestes zu geben, angesichts der Einschränkungen der Entscheidungen Ihres Chefs.

Wenn Sie als Team arbeiten, sind Sie beide für die Qualität des Codes verantwortlich (auch wenn Sie ihn nicht geschrieben haben). Der gesamte Code sollte auf Code überprüft und ein Konsens erzielt werden.

Wenn Sie Probleme haben, einen Konsens zu erzielen, installieren Sie automatisierte Tools, um die Validierung durchzuführen. Lassen Sie nur Commits zu, die die automatisierte Validierung bestehen.

Wie

1. Angenommen, dieser Code war nicht Ihr Projekt.
2. Sie haben nur den spezifischen Fehler (nicht das gesamte Projekt / die gesamte Datei) behoben, um Instabilität zu vermeiden.
3. Schlagen Sie vor, wie die Prozesse insgesamt verbessert werden können.
ol>

• Treffen Sie sich mit Ihrem Direktor und erklären Sie Ihre konstruktive Uneinigkeit mit dem Codierungsstil Ihres Teamleiters. Verwenden Sie Takt.
• Bereiten Sie sich auf etwa 3 Codierungs-, Architektur- oder Prozessbeispiele vor, die Ihre Sichtweise unterstützen.
• Abhängig von der Art der Situation und der Persönlichkeit des Teams Sie möchten möglicherweise den Teamleiter in dieses Meeting einbeziehen.
• Erläutern Sie Ihren Standpunkt, aber streiten Sie sich nicht mit Ihrem Direktor. Hören Sie auf seine / ihre Meinung. Seien Sie bereit, die Besprechung in weniger als einer Stunde abzuschließen.
• Verlassen Sie die Besprechung. Beende deinen Tag. Nach Hause gehen. Zu Abend essen. Schlafen Sie ein.
• Bewerten Sie während Ihres Arbeitswegs am nächsten Arbeitstag Ihr Meeting mit Ihrem Direktor. War er / sie fair?
  • Wenn 'Ja' (auch wenn er / sie nicht mit Ihrem Standpunkt einverstanden war), dann seien Sie bereit, Ihre Arbeitsweise anzupassen (andere Leute haben mit einigen großartigen Antworten geantwortet Ratschläge).
  • Wenn 'Nein' oder wenn Sie das Gefühl haben, dass Sie nicht mit diesem Teamleiter koexistieren können, haben Sie zwei Möglichkeiten: 1. Fragen Sie Ihren Direktor, ob Sie in eine andere Abteilung wechseln können. 2. Beginnen Sie mit der Suche nach einem neuen Job.

Weitere Informationen finden Sie unter Ratschläge zur Suche nach einem neuen Job:

• Verfolgen Sie diese Option nur als letzten Ausweg.
• Versuchen Sie am Arbeitsplatz (und im Leben im Allgemeinen) nach besten Kräften, den Standpunkt der anderen Person zu sehen.
• Aber letztendlich sollten Sie sich nach einem neuen Job umsehen, wenn Sie nicht in der Lage sind, Dinge zum Laufen zu bringen. Das Leben ist einfach zu kurz und es gibt viele Codierungsjobs.