Professionalität: Schutz der Codequalität

Eine Antwort hinzufügen, weil die anderen Antworten darum herumtanzen, aber nie wirklich in der kürzestmöglichen Formulierung spezifisch ausrufen:

Sie brauchen eine "Definition of Done"

Allgemein akzeptierte Definitionen von Done umfassen nicht nur funktionierenden Code , sondern auch funktionierende Unit-Tests und Dokumentation . Bis diese Dinge abgeschlossen sind, ist die Aufgabe nicht erledigt und der Code kann und sollte nicht freigegeben werden.

Während Sie das Konzept oft unter dem Dach von Agile/Scrum finden, ist dieser Arbeitsrahmen nicht notwendig, um diese Idee umzusetzen.

https://www.scruminc.com/definition-of-done/

https://www.agilealliance.org/glossary/definition-of-done/

Aus meiner Sicht ist nicht die Politik schuld, sondern die Person, die versucht, die Politik zu missbrauchen.

Als Ingenieur bin ich für die Codequalität verantwortlich. Inwiefern soll ich dafür kämpfen?

Solange Sie für etwas verantwortlich sind, sollten Sie es so lange befolgen, bis Sie beweisen können, dass eine Abweichung nicht von „Sie“ verursacht wurde . Angesichts des von Ihnen erwähnten Kontexts sieht es so aus, als würden Sie für die richtige Sache kämpfen. Es geht nicht nur um die "Codierungsrichtlinien", das Ziel ist es, einen Code zu haben , der tatsächlich läuft und die erwartete Ausgabe erzeugt.

Ist es angebracht, dass ich meine Vorgesetzten bitte, ihre Entscheidungen schriftlich festzuhalten?

In diesem Fall sehr wohl ja. Sie haben eine negative Bewertung abgegeben, und wenn Sie jemand bittet, auf die Blocker zu verzichten und zuzulassen, dass dieser Code seinen Platz im Produktionscode findet, stellen Sie sicher, dass dies zu einem späteren Zeitpunkt auf die „Frage“ zurückgeführt werden kann.

Wenn die Codequalität aufgrund organisatorischer Probleme leidet (wie ein Auftragnehmer entlohnt wird), ist es angemessen, dass ich „ein Richter“ bin oder das Problem mit meinen Vorgesetzten oder der Personalabteilung bespreche?

Ich würde nicht sagen, dass es die Personalabteilung ist, die damit umgehen kann, dies sollte Ihren Vorgesetzten und technischen Managern mitgeteilt werden, die die Auswirkungen verstehen können.

Sie haben bereits einige der richtigen Dinge ausprobiert, die Sie in diesem Szenario ausprobieren können, aber es gibt noch eine Sache, die ich vorschlagen würde:

Weisen Sie nicht auf die schuldige Person hin, sondern auf den problematischen Teil des Codes und versuchen Sie auch, die Probleme zu dokumentieren, die Sie vorhersehen können, wenn dieser Code es bis zur endgültigen Version schafft. Weisen Sie auch auf einige Fälle hin, in denen Sie einige der geringfügigen Fälle zugelassen haben, die Sie in der Vergangenheit zugelassen haben, in der Erwartung, dass dies in Zukunft behoben, aber nie getan wird.

Scheint, als ob der Projektmanagementprozess problematisch ist. Manchmal ist es besser, ein teilweise abgeschlossenes Feature zu haben, anstatt nicht verfügbar zu sein, aber es gibt einen Silberstreif am Horizont. Der Punkt hier ist, dass die Tracking-Perspektive verbessert werden muss. Die bloße Lieferung des Codes (oder die Ausgabe einer Pull-Anfrage) sollte nicht das Maß für die Lieferung sein, es liegt in der Verantwortung des Eigentümers sicherzustellen, dass der Code überprüft und mit dem (endgültigen) Produktionscode zusammengeführt wird.

Etwas zusammenfassen:

• Stellen Sie sicher, dass die Überprüfungskommentare nicht nur das Problem im Code erwähnen, sondern auch die nachteiligen Nebeneffekte, die es mit sich bringt, wenn es erlaubt wird, zusammengeführt zu werden. Zitieren Sie die Regeln/Richtlinien, auf deren Grundlage Sie diese Kommentare abgeben, damit deutlich wird, dass Sie nicht „pingelig“ sind, sondern berechtigte Bedenken gemäß den etablierten Richtlinien äußern.
• Versuchen Sie, eine Frist für die Lieferung festzulegen, die weit vor der tatsächlichen Lieferzeit liegt, damit genügend Zeit für alle erforderlichen Änderungen / Korrekturen bleibt.
• Fordern Sie an, dass die primären Testberichte mit der Pull-Anforderung verknüpft werden – auf diese Weise haben Sie mehr Beweise, um Ihre Punkte zu begründen.

Endlich:

Trotzdem haben mir einige Kollegen privat gesagt, dass ich mit dieser Einstellung nicht sehr weit kommen würde,

Nun, das ist kein sehr gutes Zeichen. Das Zulassen von schlechtem Code ist nicht nur schlecht für die Qualität, es ist auch ein Hinweis darauf, dass diejenigen, die die Genehmigung befürworten, die Zeit und Mühe, die für den Überprüfungsprozess aufgewendet wurden, nicht anerkennen und im Gegenzug die Arbeit von einem oder nicht anerkennen mehr Mitarbeiter. Wenn dies so weitergeht, finden Sie vielleicht besser eine Organisation, die die Bemühungen ihrer Mitarbeiter wertschätzt.

Versuchen Sie, die Akzeptanzkriterien objektiv zu gestalten.

Als Ingenieur bin ich für die Codequalität verantwortlich. Inwiefern soll ich dafür kämpfen?

Ja, die Codequalität liegt in Ihrer Verantwortung, aber das bedeutet nicht, dass Sie sicherstellen müssen, dass die Codequalität auf höchstem Niveau ist. Ihre Aufgabe ist es, sicherzustellen, dass die Codequalität auf einem angemessenen Niveau ist. Qualitativ hochwertiger Code kann Fehler vermeiden und später die Wartbarkeit verbessern, ist jedoch normalerweise mit Kosten (Geld oder Zeit) verbunden, weshalb er nicht immer benötigt wird, insbesondere wenn Sie keine Software für Herzschrittmacher oder Flugzeuge schreiben.

Sie schreiben, dass Sie in der Forschung und Entwicklung arbeiten, und in diesem Bereich ist es üblich, Prototypen zu schreiben, die in 90 % der Fälle weggeworfen werden.

Es ist schwierig, den richtigen Kompromiss zwischen Codequalität, Geschwindigkeit und Kosten zu finden, und wenn dies nicht zentral erfolgt, kann dies leicht zwischen verschiedenen Entwicklern variieren.

Wenn Sie derjenige sind, der immer nein zu neuen Funktionen sagt, die vom Unternehmen benötigt werden, werden Sie in erster Linie als Störenfried wahrgenommen. Vielleicht wird in 4 Jahren jemand erkennen, dass Sie immer Recht hatten, auf Qualität zu drängen, aber es könnte sein, dass Sie bis dahin bereits entlassen wurden.

Der Weg dorthin führt über objektive Kriterien für die Codequalität, die von den Geschäftsbeteiligten unterstützt werden

Fehlende Dokumentation

Ist der gesamte andere Code dokumentiert, oder fehlt er nur in Joes Code? Welche Auswirkungen hat es, keine Dokumentation zu haben?

Formatierung gemäß unseren Richtlinien

Dies sollte ein klarer Fall sein, Sie haben Richtlinien (ich nehme an, sie werden von Unternehmen oder Abteilungen genehmigt), die für alle gelten. Manchmal sind Richtlinien jedoch veraltet und niemand befolgt sie. Wenn andere Senioren ihnen folgen, sollten Sie sicher sein, darauf zu bestehen.

Fehlende Prüfungen

Es gibt keine globale Regel, dass Code bestimmte Arten von Tests haben muss oder überhaupt Tests haben muss. Nur weil es für sie im Allgemeinen eine gute Idee ist, bedeutet das nicht, dass es eine Praxis ist, die Sie in Ihrem Unternehmen durchsetzen.

Architektur, die nicht mit dem kompatibel ist, was wir in der Zukunft erreichen wollten. Leistungsprobleme.

Diese finde ich am schwierigsten, da es sehr schwer zu beurteilen ist, ob die Codearchitektur gut oder schlecht ist. Aber man kann zwei objektive Kriterien haben: a.) Sind nicht-funktionale Anforderungen erfüllt? (Nur wenn Sie zuvor nichtfunktionale Anforderungen definiert haben) b.) Passt der Code in die Gesamtsystemarchitektur (Nur wenn Sie eine dokumentierte Systemarchitektur haben)

Absolut nicht funktioniert

Dies ist ein Kinderspiel, niemand sollte Sie für nicht funktionierenden Code kritisieren. Es sei denn, Sie gehen über Bord und verlangen perfekten Code, wo guter Code ausreichen würde.

Ich musste Überstunden machen, um Probleme mit Joes Code zu beheben, denn sobald er genehmigt und bezahlt ist, fühlt er sich nicht mehr wohl und niemand macht ihn für die Fehlerbehebung verantwortlich.

Das ist das Problem. Sie könnten das beste Argument der Welt über die Codequalität vorbringen, aber wenn seine Bezahlung auf Funktionen basiert, dann wird er genau das tun. Warum sollte er schließlich seine Zeit damit verschwenden, bereits akzeptierte Codes zu korrigieren, wenn er dafür nicht bezahlt wird?

Ich erinnere mich an eine Zeit in der Geschichte, als LOC (Lines of Code) die wichtigste Methode war, um befördert oder bezahlt zu werden. Sie würden den ganzen Tag für einfache Dinge schreiben. Es ist sehr schwierig, Funktionen hinzuzufügen oder sogar mitzumachen.

Joe kam normalerweise mit einer Geschichte auf mich zu, wie er nicht bezahlt würde, wenn sein Code nicht rechtzeitig akzeptiert wurde.

Er hat dir sogar gesagt, dass er es nicht reparieren würde, weil er dafür nicht bezahlt wird.

Das erste Argument ist, herauszufinden, wie man diese Vertragsbedingungen festlegt. Letztendlich liegt es an Ihrem Unternehmen, aber Ihre Top-3-Argumente sind:

1. Du verschwendest Zeit damit, zu „reparieren“, was er kaputt gemacht hat. Wirst du dafür bezahlt, seine Fehler zu beheben, oder wirst du für andere Dinge bezahlt? Das würde ich klären.
2. Bezahlen per Funktion ist pleite. Sie können dies in Verbindung mit #1 erklären.
3. Wenn Nr. 1 Ihre Haupteinstellung ist, müssen Sie erwägen, einen neuen Job zu finden. Wenn sie nicht bereit sind, die Bedingungen zu ändern, müssen Sie trotzdem gehen.

Sie haben Ihre Frage bereits selbst beantwortet:

Joe wird für jedes Feature bezahlt, das er abschließt, und nicht für einen Stundensatz. Mein Eindruck ist, dass Joe versucht, so viele Funktionen wie möglich zu erledigen, wobei er dabei oft an Dokumentations-/Codequalität spart.

Stellen Sie Joe auf einen Stundenvertrag um und sehen Sie, was passiert. Wenn er gut ist, wird sich seine Qualität verbessern - es sei denn, er spielt das System aus, indem er Dinge in die Länge zieht, setzen Sie also angemessene Fristen.

Wenn sich seine Qualität nicht verbessert, ersetzen Sie ihn.

Ich finde, Sie machen Ihren Job ehrenhaft, auch wenn er ziemlich stressig ist. Als Qualitätsingenieur sollten Sie keine sehr minderwertige Arbeit durchgehen lassen.

So wie ich es jetzt sehe, gibt es einige Alternativen - keine davon perfekt.

1. Überzeugen Sie Ihre Chefs schriftlich (E-Mail sollte reichen) von der Übernahme der Verantwortung. Je mehr Bosse, desto besser.
   • eine E-Mail pro Vorfall;
   • eine E-Mail, um sie alle zu beherrschen; dies macht die Qualitätsaktivitäten im Projekt ziemlich zunichte;
2. Geben Sie Ihre Tätigkeit als Qualitätsingenieur auf oder zumindest den Job, die Arbeit anderer anzunehmen / abzulehnen. Du scheinst schon genug Arbeit zu haben;
3. Überzeugen Sie das Management, Joe die Arbeit des Teams annehmen/ablehnen zu lassen. Was auch immer passiert, Joe wird antworten – einschließlich seiner eigenen Arbeit.
4. (Worst Case) Überlegen Sie sich ein anderes Unternehmen, das Ihren Vorstellungen entspricht und beginnen Sie dort mit der „Umstellung“.

Wenn Sie urteilen, dass sowohl Chefs als auch Ihre Kollegen eine schlechte Einstellung zur Notwendigkeit der Qualität der Arbeit haben, scheint Option 4 Ihr bester Freund zu sein.

Ja, du bist unvernünftig. Solange es nicht um Leben oder Tod geht, sollten Sie den Kodex weitergeben, da sich das Management nur um Geld kümmert und technische Schuld nicht etwas ist, das es verstehen kann. Ich habe beschissenen Code geschrieben, weil mir Fristen gesetzt wurden, die nicht genug Zeit lassen, um gute Arbeit zu leisten, und weil ich als Auftragnehmer nicht für Überstunden bezahlt werde. Wenn ich die Frist setzen könnte, dann wäre es anders.