Wie gehe ich mit einem Kollegen um, dem die Codequalität nicht besonders am Herzen liegt?

Soll ich das mit meinem Teamleiter besprechen?

Nein. Das jüngste Mitglied mit nur ein paar Jahren Erfahrung sollte sich bei Teamleitern nicht über die Codequalität des ältesten Mitglieds beschweren.

Lassen Sie den Teamleiter sich darum kümmern – es gibt absolut keine Möglichkeit, dass Sie ihnen etwas sagen, was sie nicht bereits wissen. Die Gründe, warum sie es tolerieren (oder es vielleicht sogar als Gegenleistung für eine schnellere Markteinführung fördern), könnten mit der Zeit deutlicher werden.

Wenn die Kultur (wie durch das Verhalten des leitenden Entwicklers und Teamleiters belegt) nicht Ihren Qualitätspräferenzen entspricht, müssen Sie sich möglicherweise woanders umsehen.

Allerdings kann auch ein jüngeres Mitglied mit gutem Beispiel vorangehen. Stellen Sie sicher, dass Ihre Arbeit erstklassig ist und die Qualität über jeden Zweifel erhaben ist. Stellen Sie sicher, dass Sie alle Ihre Fristen einhalten. Stellen Sie sicher, dass Sie anderen helfen, wo es nötig ist. Vielleicht merken es andere und wollen das auch.

Wir haben derzeit keine dedizierten Code-Reviews und ich sehe mich derzeit nicht in der Lage, darauf zu drängen.

Später, wenn Sie sich innerhalb der Gruppe als lokaler Experte für Codequalität etabliert haben, können Sie auf Prozessänderungen drängen. Vielleicht könnten Sie anbieten, zu diesem Zeitpunkt Code-Reviews zu leiten oder dabei helfen, die Programmierstandards Ihrer Gruppe zu verfeinern und durchzusetzen.

Sie entwickeln Code für ein Unternehmen, also müssen Sie nicht nur wie ein Entwickler denken, sondern auch wie ein Geschäftsmann. Diese Denkebene wächst normalerweise, wenn Sie mehr Dienstalter erreichen.

Alle Codierungsrichtlinien, selbstdokumentierender Code, wartbarer Code und andere glänzende Dinge, die von verschiedenen Experten in Büchern erwähnt werden, sind großartig zu befolgen, aber wenn Sie die Leute davon überzeugen wollen, ihnen zu folgen, brauchen Sie einen überzeugenderen Grund als diesen:

Dinge, die meiner Meinung nach nicht in unsere Hauptfiliale gehen sollten

Sie benötigen Daten, um Ihre Ansprüche zu sichern. Sie können sicherlich zu Ihrem Chef gehen und vorschlagen, all die glänzenden Sachen zu übernehmen (obwohl Sie ein Junior sind), aber seien Sie darauf vorbereitet, die Frage zu beantworten: "Welche Vorteile hätte das für das Projekt?"

Vage Aussagen wie „es macht den Code lesbarer/wartbarer/prüfbarer/etc.“ (oder viel schlimmer, "so und so empfiehlt es") überzeugt niemanden, seine bewährten Methoden zu ändern.

Denken Sie daran, dass der "arme" Code Ihrer Vorgesetzten seit Ewigkeiten die Arbeit erledigt. „Job erledigen“ gehört zu den wichtigsten Dingen im Geschäftsleben. Den Leuten zu sagen, dass es einen besseren Weg gibt, ihre Arbeit zu erledigen, nur mit Ihrer „Meinung“, um sie zu untermauern, wird sie nicht davon überzeugen, das Risiko einzugehen.

Ich würde Sie auf jeden Fall ermutigen, das Team dazu zu drängen, das glänzende Zeug zu übernehmen, aber seien Sie bereit, die erforderliche Anstrengung zu unternehmen, um die Daten zu sammeln, die Ihre Behauptungen stützen.

Als zusätzlichen Tipp hoffe ich, dass Sie nicht den Ton verwenden, den Sie in diesem Beitrag verwendet haben, wenn Sie sich daran machen, Ihre Senioren zu überzeugen. „Haha, ihr seid scheiße, ich werde euch beibringen, wie es geht“ wird definitiv nicht funktionieren, „Ich habe einen Vorschlag zur Verbesserung von X, und ich denke, das sind die Gründe, warum wir davon profitieren würden. Was denkst du?“ hat deutlich bessere Chancen angenommen zu werden.

Ich habe das in meiner vorherigen Firma erlebt. Es endete nicht gut.

Wir haben zu zweit den Code geschrieben und der ältere Kollege war ein großer Fan von Copy-and-Paste-Programmierung. („Denken Sie daran, das ist kein Problem.“) Derselbe Codeblock wurde ungefähr 50 Mal um die Codebasis herum verstreut, wobei dieselbe Gedankenvorlage befolgt wurde. Damit konnte ich leben, obwohl ich das nicht so mochte. Null-Checks durch try...catchmit leerer Ausnahmebehandlung waren üblich. Nach einiger Zeit fing ich an, das Zeug zu refaktorisieren und mir wurde gesagt, dass ich die Arbeit behindere, weil er nach den Änderungen nicht mehr in der Lage ist, "aus seinem Gedächtnis" zu programmieren, indem er sich auf die ältere Struktur verlässt. Trotz der Qualität der Fixes und der Entfernung vieler Fehler wurde mir gesagt „Ich habe den Code beschädigt“, weil sich im Geschäftsleben niemand um kleinere Codeprobleme kümmert und das einzige Kriterium darin besteht, die Arbeit in minimalen Stunden zu erledigen und zufriedene Kunden zu bekommen. Die Arbeit mit dem Code führte zu meiner Unzufriedenheit und ich verpasste auch Fristen, die ich nicht schnell genug "kopieren und einfügen" konnte, weil ich das Gefühl hatte, nicht so ein "schneller und unkomplizierter Programmierer" werden zu wollen, wie es von mir erwartet wurde.

Ich verstehe, dass es unter Programmierern einige "praktische" Leute gibt. Sie sind oft sehr produktiv und achten nicht besonders auf Details. Wenn Ihnen dieser Ansatz nicht gefällt, überlegen Sie, ob Sie im Unternehmen bleiben oder es verlassen.

Ich glaube nicht, dass du viel in der Situation kannst. Wenn Sie Qualitätsprobleme mit Ihrem Teamleiter gegenüber einem hochrangigen Mitglied ansprechen, kann dies zu vielen unangenehmen Momenten und Gesprächen führen. (Es sei denn, es liegt ein schwerwiegender Fehler vor, aufgrund dessen der Code überhaupt nicht ausgeführt wird). Andernfalls könnten Sie als jemand wahrgenommen werden, der eine hohe Meinung von sich selbst (oder eine niedrige Meinung von anderen) hat.
Ich verstehe Ihre Besorgnis, und ich denke, Sie sollten in der Lage sein, diese Probleme anzusprechen, aber meiner Erfahrung nach laufen diese Dinge im Allgemeinen nicht gut.

Mein Vorschlag wäre, Ihr Bestes zu geben, um den Code in der gewünschten Qualität zu halten und andere tun zu lassen, was sie tun. Außerdem können Sie von Zeit zu Zeit kausal über die Codequalität sprechen, ohne mit dem Finger auf eine bestimmte Person zu zeigen. Irgendwann werden die Leute Ihre Bemühungen bemerken und alle Revisionsverläufe überprüfen können. Sie werden dich dafür erkennen. Außerdem befinden Sie sich möglicherweise irgendwann in einer relativ leitenden Position, in der Sie vom Team eine bessere Codequalität „verlangen“ können.

An diesem Punkt denke ich, dass Sie sich die zusätzliche Mühe machen und das Beste tun sollten, um die Codequalität selbst aufrechtzuerhalten und allen zu zeigen, dass Sie ein Trottel für einen sauberen Code sind!

Wir haben derzeit keine dedizierten Code-Reviews und ich sehe mich derzeit nicht in der Lage, darauf zu drängen.

Ja, das ist es, was Sie brauchen (auch wenn Sie nicht glauben, dass Sie es können).

Alles andere als regelmäßige Codeüberprüfungen wird diese Probleme nicht lösen.

Wenn Ihr Team groß genug ist, finden Sie jemanden, mit dem Sie wöchentliche Code-Reviews durchführen können. Sie brauchen nur zwei Personen, um loszulegen. Und wenn ein neuer Entwickler eingestellt wird, lassen Sie ihn mitmachen. Code-Reviews sind tatsächlich eine großartige Möglichkeit, das Onboarding durchzuführen. Natürlich wird dies Ihr unmittelbares Problem nicht lösen, aber vorausgesetzt, Sie finden einen anderen Teamkollegen, der bereit ist, mitzumachen, sollte es einfach sein, die Erlaubnis Ihres Teamleiters zu erhalten, den Ball zum Laufen zu bringen.

Verlassen Sie sich nur nicht darauf, dass dieser andere vorhandene Entwickler mitmacht, es sei denn, Sie haben bereits eine große Anzahl von Teammitgliedern, die daran teilnehmen (was Jahre dauern kann, aber letztendlich müssen Sie irgendwo anfangen, sonst werden Sie nie anfangen).

Und stellen Sie sicher, dass Sie dabei helfen, diese Code-Reviews so effizient und wertfrei wie möglich durchzuführen. Selbst wenn der Teamleiter Hilfe anbietet, verlassen Sie sich nicht darauf, dass er das Thema so gründlich recherchiert wie Sie und diese Code-Reviews so effizient wie möglich leitet, da dies im Grunde Ihre Idee ist, es zu versuchen.

Auch dies löst nicht Ihr unmittelbares Problem. Sie wollten seinen Code verbessern, nicht nur Ihren. Leider entstehen neue Gewohnheiten wie diese nicht einfach über Nacht. Sie brauchen Zeit, um sich zu entwickeln.

Bezüglich des Beitrags von Masked Man:

Was die Notwendigkeit von Daten betrifft, um Ihre Behauptungen in Bezug auf Nullprüfungen, Schluckfehler, schlechte Klassennamen usw. zu untermauern. Das Buch Code Complete enthält alle Daten, die Sie benötigen, um solche Behauptungen zu untermauern. Außerdem könnten Sie wahrscheinlich einige dieser Dinge innerhalb Ihrer Codebasis verfolgen, indem Sie Ihr derzeit vorhandenes Analysepaket verwenden. Sie könnten beispielsweise zählen, wie oft Ihre Anwendung stillschweigend fehlschlägt, selbst wenn eine wichtige Information fehlt.

Aber ich würde vorschlagen, dass Sie keine Zeit damit verschwenden. Es ist einfach schneller, den Fehler zu beheben, als zu versuchen, die Folgen dieses Fehlers im Auge zu behalten. Und da das Ego dieses Entwicklers auf dem Spiel steht, werden die Daten seine Meinung sowieso nicht ändern. Das Gleiche gilt für Ihren Teamleiter. Auch wenn er Ihnen im Prinzip zustimmt, muss er die Vorteile guter Programmierpraktiken gegen die Nachteile abwägen, die durch ständige Auseinandersetzungen mit Ihrem jeweiligen Teamkollegen entstehen.

Erstens weiß Ihr Kollege vielleicht, was er tut, und hat Gründe dafür. Wenn Sie beispielsweise eine agile Entwicklung durchführen und Kunden wöchentlich Prototypen zeigen, kann es eine absolut legitime Strategie sein, so viele Funktionen so schnell wie möglich zu implementieren, damit die Kunden/Benutzer das Design sehen und ihre Meinung dazu äußern können , und kümmern Sie sich später um Grenzfälle, Fehlerfälle und Codequalität, wenn Sie wissen, dass Sie sich auf die Anforderungen geeinigt haben.

Zweitens ist Ihr Kollege möglicherweise jemand, der gut darin ist, das große Ganze zu sehen, und schlecht darin, die kleinen Details durchzuziehen. Ich war an einer Reihe von Projekten beteiligt, bei denen diese Art von Person die Vision hatte und die Richtung vorgab und einen großen Beitrag zum Erfolg des Projekts leistete (obwohl solche Leute am Ende oft keinen Code selbst schreiben). In diesem Fall muss es jemanden geben, der sich um Details kümmert. Sie könnten diese Beschreibung von sich selbst erkennen (oder auch nicht), besonders wenn Sie sie ihnen auf positive Weise präsentieren. Versuchen Sie, ohne Anstoß zu erregen, herauszufinden, ob ihre Einschätzung der eigenen Stärken und Schwächen (und damit, wo sie Hilfe von Mitspielern benötigen) mit Ihrer übereinstimmt.

Versuchen Sie drittens, sich auf die Schwächen zu konzentrieren, die sich greifbar manifestieren, anstatt obsessiv zu werden, „wie Ihrer Meinung nach guter Code geschrieben werden sollte“. Vermeiden Sie subjektive Kritik (keine zwei Programmierer sind sich in allen Aspekten des guten Stils einig). Konzentrieren Sie sich auf die Bereiche des Codes, an denen Sie ein berechtigtes Interesse haben. Schreiben Sie Testfälle, die fehlschlagen, und protokollieren Sie Fehler dagegen. Fügen Sie dem Code Kommentare oder TODOs hinzu, z. B. „E/A-Fehler hier behandeln“.

Sie sagen , dass Sie streng auf die Codequalität achten, aber Sie sind nicht verantwortlich, also spielt das aus Unternehmenssicht keine Rolle.

Was zählt, ist die Haltung des Unternehmens zur Codequalität.

Wenn es eine strenge Unternehmensrichtlinie gibt, können Sie diese verwenden, um jede Diskussion mit Ihrem Kollegen zu unterstützen, aber der Versuch, zu Ihrem Vorgesetzten zu gehen, führt zu einer Menge Konflikte, daher sollten Sie dies am besten wegen allgemeiner Stilbedenken vermeiden, die nicht zu einer Katastrophe führen.

Wenn es diesbezüglich keine strengen Unternehmensrichtlinien gibt, sind die einzigen Dinge, die ich in Betracht ziehen würde (entweder mit Ihrem Kollegen oder Vorgesetzten), Dinge anzusprechen, die wahrscheinlich dazu geführt haben oder in der Vergangenheit dazu geführt haben, dass der Code gebrochen wurde.

Gehen Sie zuerst auf Ihren Kollegen zu. Sagen Sie ihm nicht, wie die Dinge sein müssen (weil Sie nicht davon ausgehen sollten, dass Sie es besser wissen, und es gibt keinen schnelleren Weg, jemanden in die Defensive zu bringen). Fragen Sie ihn nach den Gründen dafür, es auf seine Weise zu tun, und antworten Sie mit einem Argument, das die damit verbundenen Probleme anspricht, falls Sie welche finden können (vielleicht hat er einen guten Grund, die Dinge so zu tun, wie er es tut).

Wenn das nicht funktioniert, können Sie dies mit Ihrem Vorgesetzten besprechen.

Seien Sie nicht anklagend oder erwähnen Sie das andere Teammitglied überhaupt nicht - bringen Sie einfach eines der Probleme zur Sprache und zeigen Sie auf ein oder zwei Beispiele in Ihrer Codebasis und fahren Sie mit dem gleichen bescheidenen Ansatz fort, der oben erwähnt wurde.

Ihr Vorgesetzter überprüft möglicherweise, wer den Code geschrieben hat (falls möglich), oder bittet Sie, dies zu überprüfen, und dies kann dazu führen, dass Ihr Vorgesetzter das Problem mit diesem Kollegen anspricht. Aber all dies liegt im Ermessen Ihres Vorgesetzten. Ja, dies könnte dazu führen, dass Ihr Kollege denkt, Sie hätten ihn „verraten“, also fahren Sie auf eigene Gefahr fort.

Da ich von einem erfahrenen Programmierer komme, sollten alle Dinge, die Sie sagen, idealerweise vermieden werden, aber keines davon ist unbedingt auf das "WIR ALLE WERDEN STERBEN!" Schwere. Ignorierte Ausnahmen oder fehlende Nullprüfungen können katastrophal sein, aber sie können manchmal auch funktional unnötig sein oder absichtlich weggelassen werden. Die Benennung von Klassen wirkt sich überhaupt nicht auf die Ausführung in irgendeiner mir bekannten Sprache aus (ungeachtet der Reflexion) und ist daher viel weniger schwerwiegend als die oben genannten Bedenken, die zur Laufzeit Probleme verursachen können, und ist im Allgemeinen auch vollständig meinungsbasiert.

Ich habe also das Gefühl, dass es Ihrer Argumentation schadet, alle drei Dinge mit ungefähr der gleichen Schwere zu versehen.

Aber es steht Ihnen natürlich frei, sich zu weigern, in einer Umgebung zu arbeiten, die Ihren Standards nicht entspricht, und Stilbedenken eskalieren, als ob es lebensbedrohlich ernst wäre.

Führen Sie obligatorische Code-Reviews durch.

Sie sind nicht in der politischen Position, eine solche Änderung der Politik einfach zu fordern, aber Sie könnten sie anderen Mitgliedern des Teams vorschlagen und ihre Zustimmung erhalten. Sobald eine deutliche Mehrheit von Ihnen zustimmt, bringen Sie es mit der größeren Gruppe zur Sprache. Hier ist ein guter Grund, warum Sie dies tun sollten: https://www.atlassian.com/agile/code-reviews

Unser Büro macht das und ich liebe es.

Dies ist ein lehrbarer Moment

Ich denke, es ist in Ordnung, sich an den Teamleiter zu wenden, wenn Sie dies als Lernmöglichkeit für Sie positionieren.

Teilen Sie dem Lead mit, dass Sie sich Sorgen um die Codekonsistenz machen und sicherstellen möchten, dass Sie den richtigen Standard befolgen. Sollten Sie schreiben, was Ihrer Meinung nach ein angemessenes Maß an Codequalität ist? Oder sollten Sie eher so etwas wie diesen Senior-Entwickler machen? Vielleicht überbauen Sie.

Indem Sie es auf diese Weise ansprechen, vermeiden Sie Konfrontationen und stellen gleichzeitig sicher, dass der Teamleiter sich des Problems bewusst ist.

PS Ich schlage vor, Sie drängen nicht auf eine sofortige Antwort und seien bereit, sie fallen zu lassen.

Obwohl die Codequalität wichtig sein sollte, muss sie in den Kontext der Erwartungen des Managements und des Qualifikationsniveaus der Teammitglieder gestellt werden. Sich in diesem Bereich verbessern zu wollen, ist eine gute Sache, aber konzentrieren Sie sich auf die Probleme und nicht nur auf die Symptome.

Alles, was Sie vorschlagen, geschieht aus einem bestimmten Grund. Erhalten Benutzer Fehler aufgrund fehlender Nullprüfungen, die ein Debugging erfordern? Jeder Programmierer sollte wissen, je früher diese erkannt werden, desto einfacher sind sie zu beheben.

Nachdem Sie die Verbindungen zwischen diesen Programmierfehlern und den Problemen hergestellt haben, die sie für alle verursachen, sollte Ihr Team nach Möglichkeiten suchen, sie zu beheben. Codeüberprüfungen oder ein Prozess, um mehr als ein Paar Augen auf jede Codezeile zu lenken, werden als bewährte Vorgehensweise angesehen. Wo Sie in Schwierigkeiten geraten, ist, wenn es keine Durchsetzung dessen gibt, was Ihr Team für das Beste hält. Wenn es einem Programmierer erlaubt ist, Dinge auf seine Weise zu tun, wird nichts davon funktionieren.

Irgendwann sollte klar sein, dass der Code dieser Person mehr Probleme verursacht als der von anderen erstellte Code. Es ist Sache des Teams, Probleme mit minderwertigen Darstellern anzugehen. Hoffentlich können sich alle auf der Suche nach besserem Code in diesen Fragen einigen.

Es klingt nicht so, als ob der ältere Kollege hier das Problem ist. Menschen gehen oft den Weg des geringsten Widerstands, wenn sie die Möglichkeit dazu haben. Ihr Problem ist, dass der Prozess nicht die Qualitätsstandards durchsetzt, die Sie für notwendig halten.

Gib mir die Gelassenheit, die Dinge zu akzeptieren, die ich nicht ändern kann, den Mut, die Dinge zu ändern, die ich ändern kann, und die Weisheit, das eine vom anderen zu unterscheiden.

Das Problem, mit dem Sie kämpfen, ist, dass Sie nicht wissen, ob Sie als Junior in der Lage sind, Einfluss auf diesen Prozess zu nehmen. Kannst du sie dazu bringen, sich zu ändern oder nicht?

Ich würde im Grunde versuchen, Informationen in einem lockeren Gespräch (oder mehreren) zu sammeln, um herauszufinden, was sie in der Vergangenheit getan haben und was ihre Einwände gegen die von Ihnen vorgeschlagenen Praktiken sind. Sie werden wahrscheinlich allein dadurch ein Gefühl dafür bekommen, welche Dinge Sie wahrscheinlich beeinflussen können.

Etwas, auf das Sie wahrscheinlich direkten Einfluss haben, wäre, mehr erfahrene Teammitglieder zu bitten, informelle Code-Reviews Ihres Codes durchzuführen. Denken Sie daran, Sie sind ein Junior und daher nutzlos - wenn ein erfahreneres Mitglied des Teams Ihre Arbeit überprüft, wird dies sicherlich die Anzahl der Fehler reduzieren, die Sie einführen, und Ihnen helfen, zu lernen*. Ich denke, es ist unwahrscheinlich, dass Sie nicht eine Person dazu bringen konnten, dem zuzustimmen.

Dadurch haben Sie nicht nur mehr Vertrauen in Ihren eigenen Code (auch wenn Sie es nicht im Code Ihrer Kollegen haben), sondern fördern vielleicht auch eine Atmosphäre, in der Code-Reviews als wertvoller Bestandteil angesehen werden des Prozesses.

* Ich bin scherzhaft.

Niemand mag einen Schwätzer.

Sie machen sich Sorgen um Ihren eigenen Code, und sehr bald werden Ihre Kollegen sehen, dass Sie die Verantwortung für das Produkt übernehmen.

Ich erlebe ein ähnliches Dilemma, in dem ich der Senior-Entwickler bin und meine Kollegen Junior sind, von denen viele nicht an Qualität interessiert sind.

Die Zeit wird diejenigen aussortieren, die keine Leidenschaft für das haben, was sie tun.

Meiner Erfahrung nach ist Code-Styling wirklich schwer durchzusetzen und führt immer zu vielen unfruchtbaren Diskussionen. Es ist eine subjektive Angelegenheit und einige Leute haben wirklich starke Meinungen darüber. Wenn es Ihnen wirklich wichtig ist, sollten Sie Ihr Team davon überzeugen, ein automatisiertes Build-System (z. B. Jenkins) zu implementieren und eine automatisierte Quellcode-Validierung hinzuzufügen. Wenn der Code nicht gelinst ist, wird der Build rot und wird nicht akzeptiert.

Lassen Sie Ihr Senior College mit der Maschine streiten, anstatt sein Junior College.

Soll ich das mit meinem Teamleiter besprechen?

Ja.

Bevor Sie dies tun, lesen Sie jedoch weiter und vergewissern Sie sich, dass Sie das richtige „ this “ ansprechen.

Tatsächlich steht es Ihnen als Junior-Mitglied nicht zu, zu sagen: „Dieser andere Entwickler schreibt schlechten Code“. Es besteht jedoch ein deutlicher Unterschied darin, was Sie als Qualitätscode für akzeptabel halten und welchen Code andere Teammitglieder für akzeptabel halten. Das ist etwas, das Sie mit Ihrem Teamleiter besprechen sollten. Auf diese Weise geht es viel weniger darum, jemand anderem die Schuld zu geben, als vielmehr darum, einen guten Weg zu finden, um von hier aus weiterzumachen. Dies kann bedeuten, dass Ihr Teamleiter Ihnen sagt, dass Sie Ihren Programmierstandard lockern können. Es kann bedeuten, dass Sie am Ende den richtigen Mittelweg finden.

In jedem Fall fühlen Sie sich unwohl wegen der unterschiedlichen Standards, an die die Leute ihren Code halten, also sollten Sie das besprechen. Es sollte nicht sein, ob jemand anderes Code schreibt, der akzeptabel ist oder nicht.

Wir haben derzeit keine dedizierten Code-Reviews und ich sehe mich derzeit nicht in der Lage, darauf zu drängen.

Tatsächlich sind Sie nicht in der Lage , auf Code-Reviews zu drängen . Sie können jedoch die Verwendung von Codeüberprüfungen vorschlagen. Es kann sogar sein, dass sie erkennen, welche Fortschritte durch ein „frisches Paar Augen“ erzielt werden können, und die Verwendung dedizierter Code-Reviews kann genau so eine Sache sein.

Eine andere Möglichkeit, dies anzusprechen, ohne jemandem auf die Nerven zu gehen, wäre, das Thema schräg anzugehen, als Teil des Entwicklungsprozesses des Teams. Identifizieren Sie einige frühere Fehler, die in der Codebasis beobachtet wurden und die durch respektvolle Compiler-Warnungen oder andere Tools erkannt worden wären, bevor sie Probleme verursachten. Sie können dies dann dem Teamleiter und sogar dem gesamten Team mitteilen und vorschlagen, dass die relevanten Arten von Warnungen aus diesen Überprüfungen in Fehler in Ihrem Build-/Testprozess umgewandelt werden. Niemand mag es, Code überarbeiten zu müssen, nachdem er geschrieben und weitergemacht wurde. Sie können dies als eine einfache Möglichkeit präsentieren, um sicherzustellen, dass Sie alles gleich beim ersten Mal richtig machen und wahrscheinliche Fehlerberichte vermeiden.

Im Laufe der Zeit können Sie mehr Klassen von Fehlern ausfindig machen, die die Prüfer verhindert hätten, und sie der Durchsetzungsliste hinzufügen.

Als zusätzlichen Vorteil vermeidet dieser Ansatz auch den Aufwand für die Behebung von Beschwerden über den Code, die sich für Ihre spezielle Anwendung immer wieder als irrelevant herausstellen. Die Warnungen sind möglicherweise keine Fehlalarme in dem Sinne, dass sie falsch sind, aber sie können Fehlalarme in dem Sinne sein, dass sie keinen Unterschied machen.

Das Wort dafür ist Ursachenanalyse. Wenn Sie nachweisen können, dass diese Commits die Quelle eines oder mehrerer schwerwiegender Fehler sind, besprechen Sie diese Commits während des Teammeetings oder des Fehlerüberprüfungsmeetings als Gruppe, um das Bewusstsein für die negativen Auswirkungen dieser Techniken zu schärfen. Wenn dies nicht der Fall ist, können Sie auch einfach einen Ausschnitt per E-Mail an das Team senden und jemanden um eine Erklärung bitten, damit Sie zumindest die Dokumentation verbessern können.

Verweise

• Verbesserung des Softwareinspektionsprozesses mit Mustern (pdf)

• Der SEI Personal Software Prozess: Verbessern Sie sich