Wie sagt man jemandem, dass er schlechten Code schreibt? [geschlossen]

Ich habe mit einer kleinen Gruppe von Leuten zum Spaß an einem Codierungsprojekt gearbeitet. Es ist eine organisierte und ziemlich zusammenhängende Gruppe. Die Leute, mit denen ich zusammenarbeite, haben verschiedene Fähigkeiten im Zusammenhang mit der Programmierung, aber einige von ihnen verwenden ältere oder völlig falsche Methoden, wie übermäßige globale Variablen, schlechte Namenskonventionen und andere Dinge. Während die Dinge funktionieren, ist die Implementierung schlecht. Was ist ein guter Weg, um sie höflich zu bitten oder ihnen eine bessere Methodik vorzustellen, ohne dass dies ihre Erfahrung und / oder Ausbildung in Frage stellt (oder beleidigt)?

Stellen Sie Fragen, damit sie erkennen, dass das, was sie tun, falsch ist. Stellen Sie beispielsweise folgende Fragen:

Warum haben Sie beschlossen, dies zu einer globalen Variablen zu machen?

Warum hast du ihm diesen Namen gegeben?

Das ist interessant. Normalerweise mache ich meine so, weil [Grund einfügen, warum du besser bist]

Funktioniert das so? Ich normalerweise [Füge ein, wie du sie albern aussehen lassen würdest]

Ich denke, der ideale Weg, dies zu tun, besteht darin, sie subtil zu fragen, warum sie einen bestimmten Weg codieren. Sie werden vielleicht feststellen, dass sie glauben, dass andere Methoden Vorteile haben. Wenn ich nicht wüsste, dass der Grund für ihren Codierungsstil auf Fehlinformationen zurückzuführen ist, würde ich meinen Weg ohne guten Grund niemals als besser beurteilen. Der beste Weg, dies zu tun, besteht darin, sie zu fragen, warum sie diesen Weg gewählt haben. Seien Sie sicher, dass Sie an ihrer Argumentation interessiert sind, denn das ist es, was Sie angreifen müssen, nicht ihre Fähigkeit.

Ein Codierungsstandard wird definitiv helfen, aber wenn es die Antwort auf jedes Softwareprojekt wäre, würden wir alle auf unseren privaten Inseln im Paradies Cocktails trinken. In Wirklichkeit sind wir alle anfällig für Probleme und Softwareprojekte haben immer noch eine geringe Erfolgsquote. Ich denke, das Problem würde eher auf individuelle Fähigkeiten als auf ein Problem mit Konventionen zurückzuführen sein, weshalb ich vorschlagen würde, die Probleme als Gruppe zu bearbeiten, wenn ein Problem seinen hässlichen Kopf zeigt.

Nehmen Sie vor allem NICHT sofort an, dass Ihr Weg besser ist . In Wirklichkeit ist es wahrscheinlich so, aber wir haben es mit der Meinung einer anderen Person zu tun und für sie gibt es nur eine Lösung. Sagen Sie niemals, dass Ihr Weg der bessere ist, es sei denn, Sie möchten, dass sie Sie als selbstgefälligen Verlierer sehen.

Beginnen Sie mit Codeüberprüfungen oder Paarprogrammierung.

Wenn das Team sich nicht dafür entscheidet, versuchen Sie es mit wöchentlichen Designprüfungen. Treffen Sie sich jede Woche für eine Stunde und sprechen Sie über ein Stück Code. Wenn die Leute defensiv wirken, wählen Sie alten Code, an den zumindest zu Beginn niemand mehr emotional gebunden ist.

Wie @JesperE: sagte, konzentrieren Sie sich auf den Code, nicht auf den Codierer.

Wenn Sie etwas sehen, von dem Sie denken, dass es anders sein sollte, andere es aber nicht so sehen, stellen Sie zunächst Fragen, die zu den Mängeln führen, anstatt darauf hinzuweisen. Beispielsweise:

Globals : Glaubst du, wir werden jemals mehr als eine davon haben wollen? Glauben Sie, wir wollen den Zugang dazu kontrollieren?

Veränderlicher Zustand : Glauben Sie, wir wollen dies von einem anderen Thread aus manipulieren?

Ich finde es auch hilfreich, mich auf meine Grenzen zu konzentrieren, die den Menschen helfen können, sich zu entspannen. Beispielsweise:

lange Funktionen : Mein Gehirn ist nicht groß genug, um all dies auf einmal zu halten. Wie können wir kleinere Stücke herstellen, mit denen ich umgehen kann?

schlechte Namen : Ich werde leicht genug verwirrt, wenn ich klaren Code lese; Wenn Namen irreführend sind, gibt es keine Hoffnung für mich.

Letztendlich ist es nicht Ihr Ziel, Ihrem Team beizubringen, wie man besser codiert. Es geht darum, eine Lernkultur in Ihrem Team zu etablieren. Wo jede Person die anderen um Hilfe bittet, um ein besserer Programmierer zu werden.

Stellen Sie die Idee eines Codestandards vor. Das Wichtigste an einem Codestandard ist, dass er die Idee der Konsistenz in der Codebasis vorschlägt (im Idealfall sollte der gesamte Code so aussehen, als ob er von einer Person in einer Sitzung geschrieben wurde), was zu einem verständlicheren und wartbareren Code führt.

Sie müssen erklären, warum Ihr Weg besser ist .

Erklären Sie, warum eine Funktion besser ist als Ausschneiden und Einfügen.

Erklären Sie, warum ein Array besser ist als $ foo1, $ foo2, $ foo3.

Erklären Sie, warum globale Variablen gefährlich sind und dass lokale Variablen das Leben erleichtern.

Es ist wertlos, einfach einen Codierungsstandard herauszuholen und "do this" zu sagen, da dies dem Programmierer nicht erklärt, warum dies eine gute Sache ist.

Erstens würde ich darauf achten, nicht zu schnell zu urteilen. Es ist einfach, Code als schlecht abzutun, wenn es gute Gründe dafür gibt (z. B. Arbeiten mit Legacy-Code mit seltsamen Konventionen). Aber nehmen wir für den Moment an, dass sie wirklich schlecht sind.

Sie können vorschlagen, einen Codierungsstandard festzulegen, der auf den Eingaben des Teams basiert. Aber Sie müssen dann wirklich ihre Meinungen berücksichtigen und nicht nur Ihre Vision davon durchsetzen, was guter Code sein sollte.

Eine andere Möglichkeit besteht darin, technische Bücher ins Büro zu bringen (Code Complete, Effective C ++, Pragmatic Programmer ...) und anzubieten, sie anderen zu leihen ("Hey, ich bin damit fertig, möchte jemand sie ausleihen?" )

Stellen Sie nach Möglichkeit sicher, dass sie verstehen, dass Sie ihren Code kritisieren , nicht sie persönlich.

Schlagen Sie eine bessere Alternative auf nicht konfrontative Weise vor.

"Hey, ich denke, dieser Weg wird auch funktionieren. Was denkst du?" [Geste zu offensichtlich besserem Code auf Ihrem Bildschirm]

Lassen Sie Code überprüfen und überprüfen Sie zunächst IHREN Code.

Dadurch werden die Benutzer mit dem gesamten Codeüberprüfungsprozess vertraut, da Sie den Prozess beginnen, indem Sie Ihren eigenen Code anstelle ihres eigenen überprüfen. Wenn Sie mit Ihrem Code beginnen, erhalten Sie auch gute Beispiele für die Vorgehensweise.

Sie denken vielleicht, dass Ihr Stil auch stinkt. Bringen Sie das Team zusammen, um einen einheitlichen Satz von Richtlinien für den Codierungsstil zu besprechen. Stimme etwas zu. Ob das zu Ihrem Stil passt, ist nicht das Problem. Es kommt darauf an, sich für einen Stil zu entscheiden, solange er konsistent ist.

Zum Beispiel. Zeigen Sie ihnen den richtigen Weg.

Gehe es langsam an. Verprügel sie nicht für jeden kleinen Fehler auf Anhieb, sondern beginne mit Dingen, die wirklich wichtig sind.

Die Code-Standard-Idee ist gut.

Aber bedenken Sie nicht etwas zu sagen, vor allem , da es zum Spaß, mit vermutlich Menschen Sie sind Freunde mit. Es ist nur Code ...

In Gerry Weinbergs Buch "Die Psychologie der Computerprogrammierung" gibt es einige wirklich gute Ratschläge - in seinem gesamten Begriff der "egolosen Programmierung" geht es darum, Menschen dabei zu helfen, Kritik an ihrem Code im Gegensatz zu Kritik an sich selbst zu akzeptieren.

Schlechte Benennungspraktiken: Immer unentschuldbar.

Und ja, nehmen Sie nicht immer an, dass Ihr Weg besser ist ... Es kann schwierig sein, aber die Objektivität muss erhalten bleiben.

Ich habe eine Erfahrung mit einem Codierer gemacht, der so schreckliche Funktionen benannt hat, dass der Code schlechter als unlesbar war. Die Funktionen haben gelogen, was sie getan haben, der Code war unsinnig. Und sie waren schützend / resistent dagegen, dass jemand anderes ihren Code änderte. Als sie sehr höflich konfrontiert wurden, gaben sie zu, dass er schlecht benannt war, wollten aber ihr Eigentum an dem Code behalten und würden zurückgehen und ihn "zu einem späteren Zeitpunkt" reparieren. Dies ist jetzt in der Vergangenheit, aber wie gehen Sie mit einer Situation um, in der der Fehler BESTÄTIGT, aber dann geschützt wird? Das dauerte lange und ich hatte keine Ahnung, wie ich diese Barriere durchbrechen sollte.

Globale Variablen: Ich selbst mag globale Variablen nicht so gern, aber ich kenne einige ansonsten ausgezeichnete Programmierer, die sie sehr mögen. So sehr, dass ich zu der Überzeugung gekommen bin, dass sie in vielen Situationen gar nicht so schlecht sind, da sie Klarheit und einfache Fehlerbehebung ermöglichen. (Bitte nicht flammen / abstimmen :)) Es kommt darauf an, dass ich eine Menge sehr guten, effektiven, fehlerfreien Code gesehen habe, der globale Variablen verwendet (nicht von mir eingegeben!) und viel fehlerhaft, Es ist unmöglich, Code zu lesen / zu warten / zu reparieren, der sorgfältig die richtigen Muster verwendet. Vielleicht gibt IS ein Ort (wenn auch schrumpf vielleicht) für globale Variablen? Ich denke darüber nach, meine Position anhand von Beweisen zu überdenken.

Starten Sie ein Wiki in Ihrem Netzwerk mit einer Wiki-Software.

Starten Sie auf Ihrer Website eine Kategorie mit dem Namen "Best Practices" oder "Codierungsstandards" oder ähnliches.

Zeigen Sie alle darauf. Feedback zulassen.

Wenn Sie Versionen der Software erstellen, lassen Sie die Person, deren Aufgabe es ist, Code in den Build einzufügen, die Entwickler zurückschieben und sie auf die darauf befindlichen Wiki-Seiten verweisen.

Ich habe dies in meiner Organisation getan und es hat mehrere Monate gedauert, bis die Leute wirklich mit dem Wiki fertig wurden, aber jetzt ist es diese unverzichtbare Ressource.

Wenn Sie sogar einen losen Codierungsstandard haben, kann es sich lohnen, darauf hinweisen zu können oder anzuzeigen, dass Sie dem Code nicht folgen können, weil er nicht das richtige Format hat.

Wenn Sie kein Codierungsformat haben, ist jetzt ein guter Zeitpunkt, um eines einzurichten. So etwas wie die Antworten auf diese Frage können hilfreich sein: /programming/4121/team-coding-styles

Ich gehe immer mit der Zeile "Das würde ich tun". Ich versuche nicht, sie zu belehren und ihnen zu sagen, dass ihr Code Müll ist, sondern gebe nur einen alternativen Standpunkt an, der ihnen hoffentlich etwas zeigen kann, das offensichtlich etwas ordentlicher ist.

Lassen Sie die betreffende (n) Person (en) dem Rest der Gruppe eine Präsentation über den Code für ein repräsentatives Modul vorbereiten, das sie geschrieben haben, und lassen Sie die Fragen und Antworten sich darum kümmern (vertrauen Sie mir, es wird und wenn es eine gute Gruppe ist, es sollte nicht einmal hässlich werden).

Ich liebe Code und hatte in meinem Leben noch nie einen Kurs über Informatik. Ich habe sehr schlecht angefangen und angefangen, aus Beispielen zu lernen, aber ich erinnere mich immer daran und habe mich daran erinnert, seit ich das Buch "Gang Of Four" gelesen habe ::

"Jeder kann Code schreiben, der von einer Maschine verstanden wird, aber nicht alle können Code schreiben, der von einem Menschen verstanden wird."

In diesem Sinne gibt es im Code viel zu tun;)

Ich kann Geduld nicht genug betonen. Ich habe genau diese Art von Dingen völlig nach hinten losgehen sehen, hauptsächlich weil jemand wollte, dass die Änderungen JETZT stattfinden. Nicht wenige Umgebungen benötigen die Vorteile der Evolution, nicht der Revolution.Und wenn man heute Veränderungen erzwingt, kann dies zu einem sehr unglücklichen Umfeld für alle führen.

Buy-In ist der Schlüssel. Und Ihr Ansatz muss die Umgebung berücksichtigen, in der Sie sich befinden.

Es hört sich so an, als ob Sie sich in einer Umgebung befinden, die viel "Individualität" aufweist. Also ... ich würde keine Reihe von Codierungsstandards vorschlagen. Es wird sich herausstellen, dass Sie dieses "lustige" Projekt in ein hoch strukturiertes Arbeitsprojekt verwandeln möchten (oh, großartig, was kommt als nächstes ... funktionale Dokumente?). Stattdessen müssen Sie sich, wie jemand anderes sagte, bis zu einem gewissen Grad damit befassen.

Bleiben Sie geduldig und arbeiten Sie daran, andere in Ihre Richtung zu erziehen. Beginnen Sie mit den Kanten (Punkte, an denen Ihr Code mit anderen interagiert) und versuchen Sie bei der Interaktion mit ihrem Code, die von ihnen erstellte Schnittstelle zu diskutieren und sie zu fragen, ob es für sie in Ordnung wäre, wenn sie geändert würden (von Sie oder sie). Und erklären Sie vollständig, warum Sie die Änderung wünschen ("es hilft, mit der Änderung von Subsystemattributen besser umzugehen" oder was auch immer). Wählen Sie nicht alles aus, was Sie als falsch ansehen. Sobald Sie mit anderen am Rande interagieren, sollten sie erkennen, wie sie im Kern ihres Codes davon profitieren würden (und wenn Sie genügend Schwung erhalten, gehen Sie tiefer und beginnen Sie wirklich, moderne Techniken und die Vorteile von Codierungsstandards zu diskutieren). Wenn sie es immer noch nicht sehen ... vielleicht du '

Die Geduld. Evolution, nicht Revolution.

Viel Glück.

Ich ziehe eine Toga an und öffne eine Dose mit einer sokratischen Methode.

Die nach dem klassischen griechischen Philosophen Sokrates benannte sokratische Methode ist eine Form der philosophischen Untersuchung, bei der der Fragesteller die Implikationen der Positionen anderer untersucht, um rationales Denken anzuregen und Ideen zu beleuchten. Diese dialektische Methode beinhaltet oft eine oppositionelle Diskussion, in der die Verteidigung eines Standpunkts gegen einen anderen gestellt wird; Ein Teilnehmer kann einen anderen dazu bringen, sich in irgendeiner Weise zu widersprechen, was den eigenen Standpunkt des Fragestellers stärkt.

Viele der Antworten hier beziehen sich auf die Code-Formatierung, die heutzutage nicht besonders relevant ist, da die meisten IDEs Ihren Code in dem von Ihnen gewählten Stil neu formatieren. Was wirklich wichtig ist, ist, wie der Code funktioniert, und das Poster ist richtig, um globale Variablen, Code zum Kopieren und Einfügen und Namenskonventionen für mein Haustier zu betrachten. Es gibt so etwas wie schlechten Code und er hat wenig mit Format zu tun.

Das Gute daran ist, dass das meiste aus einem sehr guten Grund schlecht ist, und diese Gründe sind im Allgemeinen quantifizierbar und erklärbar. Erklären Sie also auf nicht konfrontative Weise die Gründe. In vielen Fällen können Sie dem Verfasser sogar Szenarien geben, in denen die Probleme offensichtlich werden.

Ich bin nicht der Hauptentwickler in meinem Projekt und kann daher keine Codierungsstandards auferlegen, aber ich habe festgestellt, dass schlechter Code normalerweise eher früher als später ein Problem verursacht, und wenn dies der Fall ist, habe ich eine sauberere Idee oder Lösung.

Indem ich zu der Zeit nicht eingegriffen habe und einen natürlicheren Ansatz gewählt habe, habe ich mehr Vertrauen in den Lead gewonnen. Er wendet sich häufig an mich, um Ideen zu erhalten, und bezieht mich in die für das Projekt verwendete Architekturdesign- und Bereitstellungsstrategie ein.

Leute, die schlechten Code schreiben, sind nur ein Symptom für Unwissenheit (was sich davon unterscheidet, dumm zu sein). Hier sind einige Tipps für den Umgang mit diesen Menschen.

• Die Erfahrung der Menschen hinterlässt einen stärkeren Eindruck als etwas, das Sie sagen werden.
• Einige Leute sind nicht begeistert von dem Code, den sie produzieren, und hören nichts, was Sie sagen
• Paired Programming kann dabei helfen, Ideen auszutauschen, aber zu wechseln, wer fährt, oder sie überprüfen nur E-Mails auf ihrem Telefon
• Ertrinke sie nicht mit zu viel, ich habe festgestellt, dass sogar die kontinuierliche Integration einigen älteren Entwicklern einige Male erklärt werden musste
• Holen Sie sie wieder aufgeregt und sie werden lernen wollen. Es könnte so einfach sein, wie Roboter für einen Tag zu programmieren
• VERTRAUEN SIE IHREM TEAM, Codierungsstandards und Tools, die sie beim Erstellen überprüfen, werden oft nie gelesen oder sind ärgerlich.
• Code-Besitz entfernen, bei einigen Projekten sehen Sie Codesilos oder Ameisenhügel, in denen Leute sagen, dass dies mein Code ist und Sie ihn nicht ändern können. Dies ist sehr schlecht und Sie können die gepaarte Programmierung verwenden, um dies zu entfernen.

Anstatt sie Code schreiben zu lassen, lassen Sie sie ihren Code pflegen.

Bis sie ihren dampfenden Haufen Spaghetti behalten müssen, werden sie nie verstehen, wie schlecht sie im Codieren sind.

Niemand hört gerne jemandem zu, der sagt, dass seine Arbeit scheiße ist, aber jede vernünftige Person würde Mentoring und Möglichkeiten zur Vermeidung unnötiger Arbeit begrüßen.

Eine Schule sagt sogar, dass Sie nicht auf Fehler hinweisen sollten, sondern sich darauf konzentrieren sollten, was richtig gemacht wird. Anstatt beispielsweise auf unverständlichen Code als schlecht hinzuweisen, sollten Sie darauf hinweisen, wo der Code besonders leicht zu lesen ist. Im ersten Fall bereiten Sie andere darauf vor, wie beschissene Programmierer zu denken und zu handeln. Im späteren Fall bereiten Sie sich darauf vor, wie ein qualifizierter Fachmann zu denken.

Ich habe ein ähnliches Szenario mit den Leuten, mit denen ich zusammenarbeite. Sie sind nicht so sehr mit Codierung konfrontiert wie ich, aber sie sind immer noch nützlich beim Codieren.

Anstatt dass ich das tun lasse, was sie wollen, und zurück gehe und das Ganze bearbeite. Normalerweise setze ich sie einfach hin und zeige ihnen zwei Arten, Dinge zu tun. Auf diese und meine Weise diskutieren wir die Vor- und Nachteile jeder Methode und kommen daher zu einem besseren Verständnis und einer besseren Schlussfolgerung darüber, wie wir programmieren sollen.

Hier ist der wirklich überraschende Teil. Manchmal kommen sie auf Fragen, auf die selbst ich keine Antworten habe, und nach Recherchen erhalten wir alle ein besseres Konzept für Methodik und Struktur.

1. Diskutieren.
2. Zeigen Sie ihnen warum
3. Denken Sie nicht einmal, dass Sie immer Recht haben. Manchmal bringen sie Ihnen sogar etwas Neues bei.

Das würde ich tun, wenn ich du wäre: D.

Wahrscheinlich etwas spät nach dem Effekt, aber hier ist ein vereinbarter Codierungsstandard eine gute Sache.

Ich bin ehrlich gesagt der Meinung, dass jemandes Code besser ist, wenn es einfacher ist, ihn zu ändern, zu debuggen, zu navigieren, zu verstehen, zu konfigurieren, zu testen und zu veröffentlichen (Puh).

Das heißt, ich denke, es ist unmöglich, jemandem zu sagen, dass sein / ihr Code schlecht ist, ohne zuerst zu versuchen, ihn / sie zu erklären, was er tut oder wie jemand ihn danach verbessern soll (z. B. neue Funktionen erstellen oder ihn debuggen).

Nur dann schnappt ihr Verstand und jeder wird das sehen können:

• Wertänderungen globaler Variablen sind fast immer nicht nachvollziehbar
• Riesige Funktionen sind schwer zu lesen und zu verstehen
• Muster erleichtern die Verbesserung Ihres Codes (solange Sie deren Regeln einhalten).
• ( etc...)

Vielleicht sollte eine Sitzung der Paarprogrammierung den Trick tun. Die Durchsetzung von Codierungsstandards hilft - aber sie sind zu weit davon entfernt, wirklich zu definieren, was guter Code ist.

Sie möchten sich wahrscheinlich auf die Auswirkungen des schlechten Codes konzentrieren und nicht auf Ihre subjektive Meinung, ob es sich um einen guten oder einen schlechten Stil handelt.

Erkundigen Sie sich privat nach einigen der "schlechten" Codesegmente, um festzustellen, ob dies tatsächlich sinnvoll ist Code handelt (egal wie prädisponiert Sie auch sein mögen) oder dass möglicherweise mildernde Umstände vorliegen. Wenn Sie immer noch davon überzeugt sind, dass der Code einfach nur schlecht ist - und dass die Quelle tatsächlich diese Person ist -, gehen Sie einfach weg. Eines von mehreren Dingen kann passieren: 1) Die Person bemerkt und ergreift Korrekturmaßnahmen. 2) Die Person tut nichts (ist sich dessen nicht bewusst oder kümmert sich nicht so sehr wie Sie).

Wenn # 2 passiert oder # 1 aus Ihrer Sicht nicht zu einer ausreichenden Verbesserung führt UND das Projekt verletzt und / oder Sie genug belastet, ist es möglicherweise an der Zeit, eine Kampagne zu starten, um darin Standards zu etablieren / durchzusetzen Die Mannschaft. Dies erfordert ein Management-Buy-In, ist jedoch am effektivsten, wenn es von der Basis aus angestiftet wird.

Viel Glück damit. Ich fühle deinen Schmerz, Bruder.