Bei der Programmierung handelt es sich bei der Ententechnik um eine Technik, bei der Sie einen offensichtlichen, einfachen Überblick über Ihren Code erhalten, in der Hoffnung, dass er während der Überprüfung die Aufmerksamkeit auf sich zieht und große, zeitaufwändige Designänderungen abschwächt.
Es gab dieses eine Team in meiner Firma, das dafür bekannt war, zum Zeitpunkt der Überprüfung sehr wählerisch zu sein. Wenn wir Lib A verwenden würden, würden sie Lib B wollen. Aber wenn wir Lib B verwendet hätten, würden sie Lib A wollen. Sie sind mit diesem Designmuster nicht zufrieden und möchten ein anderes sehen. Aber ich schwöre, wenn wir ursprünglich das Muster verwendet hätten, das sie vorgeschlagen hatten, hätten sie das andere gewollt. Es war, als müssten sie einige Kommentare hinzufügen, um den Wert zu demonstrieren. Diese großen Änderungen waren problematisch, da aus einer einstündigen Aufgabe mehrere Stunden werden konnten, die sich im Laufe der Tage hinzogen und den Fortschritt blockierten. Und ich weiß, was Sie denken: Warum nicht vorher mit diesem Team über die Änderung sprechen? Wir machten. Wir hatten Besprechungen, um die Änderung zu besprechen, zu erklären, wie das Design die Abwärtskompatibilität aufrechterhält, und um sicherzustellen, dass sie sich gehört fühlten, Input hatten und an Bord waren. Es war egal. Als die Codeüberprüfung eintraf, war alles, was vereinbart wurde, vergessen.
Irgendwann mussten ein Mitarbeiter und ich eine Änderung an einer Bibliothek vornehmen, die wir benutzten, damit wir die nutzen konnten Änderung in unserem Programm. Es war eine kleine Änderung, aber wir seufzten, hockten uns hin und machten uns auf den Weg zur Codeüberprüfung. Wir haben die Änderung paarweise programmiert und kurz durchgearbeitet, bevor wir sie zur Codeüberprüfung eingereicht haben. Da ich die Tendenz dieses anderen Teams kannte, hartnäckig zu sein, hatte ich eine Idee:
Teamkollege: Sollten wir dies hier durch die Kurzschrift-Syntax der neuesten Version der eingeführten Sprache ersetzen?
Ich: Gute Idee ... lassen Sie es vorerst.
Es gab einige andere Fälle. Nichts Kritisches wie das Hinterlassen eines Fehlers, aber Dinge wie das Verlassen der Syntax, von denen wir wussten, dass sie dem anderen Team nicht gefallen haben, lassen Raum für das Extrahieren von Methoden oder das Umbenennen von Variablen. Es hat wunderbar funktioniert. Sie kommentierten jede Ente und wir antworteten mit: "Danke! Jetzt reparieren!" und das war's. Die Codeüberprüfung war in ungefähr 10 Minuten beendet und wir konnten fortfahren, ohne blockiert zu werden.
Aber das brachte mich zum Nachdenken, gibt es ethische Probleme? Ich mache das nicht besonders gerne und für kein anderes Team. In diesem einen Fall konnten wir jedoch eine potenzielle 2-stündige Hin- und Her-Codeüberprüfung in 10 Minuten umwandeln. Ein Gewinn in meinem Buch. Ich bin gespannt, was andere denken oder ob sie alternative Lösungen für den Umgang mit schwierigen Teams haben.
Aus Gründen der Klarheit bearbeiten: Diese Frage wird immer wieder gestellt, daher wollte ich sie hier ansprechen.
Wenn das Team die Zeit aller verschwendet, warum nicht mit ihnen konfrontieren, zurückschieben oder mit dem Management sprechen?
Wir folgten zuerst allen üblichen / offiziellen Kanälen . Sie hatten kein letztes Wort bei der Codeüberprüfung (obwohl es für mich ein politischer Verlust gewesen wäre, ihr Buy-In nicht zu bekommen), und alles, was absolut dumm oder gefährlich war, würden wir nicht berücksichtigen, aber manchmal würde es mehr sparen, wenn wir uns der Anfrage anschließen Zeit auf lange Sicht. Ich würde gerne kleine Dinge wie "Leerzeichen gegen Tabulator" oder "Klammerplatzierung" ändern. Größere Dinge, die ich zurückdrängen und nach einem Grund fragen würde, warum es sich lohnt, Zeit für die Änderung zu investieren. Manchmal hat es funktioniert, manchmal nicht. Ich und andere hatten sie entweder bei der Arbeit oder beim Mittagessen oder bei einem Bier einzeln angesprochen und gesagt, dass diese Änderungen des Code-Review-Designs den Fortschritt und die Arbeit beeinträchtigen würden. Ich habe ihr Verhalten dem Management als problematisch gemeldet, und andere haben es möglicherweise auch.
Idealerweise würde ihnen gesagt, dass ihr Verhalten inakzeptabel sei, sie würden den Fehler ihrer Wege erkennen und sich ändern. Aber Menschen sind keine Computer und müssen nichts tun, was ich oder jemand anderes gerne sehen würde, unabhängig davon, wie viel Zeit und Geld das Unternehmen verschwendet hat. Jeder Kritik könnte mit "Wir verschwenden keine Zeit, wir stellen sicher, dass der Code richtig gemacht wird. Das ist sicherlich etwas mehr Zeit im Voraus wert, nicht wahr?" Es ist leider nicht wirklich schwarz und weiß und am Ende, wie ich irgendwo unten erwähnte, entschied ich, dass dies kein Hügel war, auf dem ich sterben wollte. Vor allem, weil meine direkten Interaktionen mit diesem Team selten waren.
Es ist schwer zu erklären, außer es als "wählerisch um der Seligkeit willen" zu beschreiben. Zum Beispiel haben wir versucht, stilistische Dinge zu automatisieren, da dies eine Aufgabe für den Editor ist, aber sie haben sich verworrene Regeln ausgedacht, mit denen der Editor einfach nicht konsequent umgehen konnte. Ich glaube nicht, dass sie bösartig waren. Sachen wie, vielleicht würden sie eine Woche lang Muster A wirklich lieben. Wenn ich das weiß, würde ich sicherstellen, dass Muster A für ihren Code verwendet wird, wo dies angebracht ist. Aber zu einem bestimmten Zeitpunkt lesen sie irgendwo, dass Muster A schlecht ist und jeder Muster B verwenden sollte. Dies wird möglicherweise nicht in vorläufigen Entwurfsdiskussionen angesprochen, und ich würde nicht daran denken, zu fragen, weil ich dachte, dass sie Muster A mögen, aber es würde zur Überprüfungszeit kommen. Sie hatten ein seltsames kleines Lehen und regierten es mit eiserner Faust, aber sie waren schon lange in der Firma und das Management mochte sie. Sie waren letztendlich eine nette Gruppe von Leuten, nur etwas seltsam. Es ist nur eines dieser seltsamen Dinge am Arbeitsplatz, die wahrscheinlich verrückt klingen, wenn Sie nicht auf etwas Ähnliches stoßen.