Wie überzeuge ich mein Team, kleinere Klassen / Methoden anzuwenden?

Haftungsausschluss: Ich bin ein Neuling (dies ist mein dritter Arbeitstag) und die meisten meiner Teamkollegen sind erfahrener als ich.

Wenn ich mir unseren Code ansehe, sehe ich einige Codegerüche und schlechte Konstruktionspraktiken wie die folgenden:

• Etwas inkonsistente Namensrichtlinien
• Eigenschaften, die nach Möglichkeit nicht als schreibgeschützt gekennzeichnet sind
• Große Klassen - Mir ist eine Utility-Klasse aufgefallen, die aus Hunderten von Erweiterungsmethoden (für viele Typen) bestand. Es war mehr als 2500 Zeilen lang!
• Große Methoden - Ich versuche, eine 150 Zeilen lange Methode umzugestalten.

Die beiden letzteren scheinen ein echtes Problem zu sein. Ich möchte meine Teamkollegen davon überzeugen, kleinere Klassen und Methoden anzuwenden. Aber soll ich das machen? Wenn ja, wie?

Mein Team hat einen Mentor vom Hauptteam (wir sind ein Satellitenteam). Soll ich zuerst zu ihm gehen?

UPDATE : Da einige Antworten zu dem Projekt fragten, wissen Sie bitte, dass es ein funktionierendes Projekt ist. Und meiner Meinung nach sind riesige Klassen / Methoden dieser Größe immer schlecht.

Wie auch immer, ich möchte nie mein Team verärgern. Deshalb habe ich gefragt: Soll ich das tun, und wenn ja, wie mache ich das sanft?

UPDATE : Ich habe mich entschlossen, basierend auf der akzeptierten Antwort etwas zu tun: Da ich ein Neuling bin, sehe ich alles in "frischen Augen". Ich werde alle Codegerüche, die ich gefunden habe, zur Kenntnis nehmen (Position, warum es schlecht ist, wie können wir es tun) Besser, ...), aber im Moment versuche ich nur, Respekt von meinem Team zu erlangen: Schreiben Sie "besseren Code", kennen Sie die Leute, wissen Sie, warum wir das getan haben ... Wenn die Zeit reif ist, werde ich es versuchen Um mein Team nach neuen Coderichtlinien zu befragen (Benennungsrichtlinien, kleinere Klassen, kleinere Methoden, ...) und wenn möglich alten Code umzugestalten. Es sollte funktionieren, IMHO.

Vielen Dank.

Sie haben den Vorteil, den Code mit neuen Augen zu betrachten. Machen Sie sich Notizen, um zu dokumentieren, was Sie über schlechte Praktiken erfahren. Ziehen Sie dann, wenn Sie sich mit dem Team einig sind, Ihre Notizen zu einem geeigneten Zeitpunkt heraus, zum Beispiel wenn es Zeit für ein Refactoring ist.

Code Complete von Steve McConnell bietet unzählige gute Statistiken zu dem Thema, über das Sie sprechen. Ich erinnere mich nicht an alle Zahlen, aber er spricht darüber, wie die Zahl der Fehler mit längeren Methoden / Klassen zunimmt, wie lange das Debuggen dauert usw.

Sie könnten eine Kopie des Buches kaufen und Ihren Kollegen einige der Studien zeigen ... Statistiken (obwohl sie die ganze Zeit lügen) neigen dazu, die Leute zu überzeugen.

Haftungsausschluss: Ich bin ein Neuling (dies ist mein dritter Arbeitstag) und die meisten meiner Mitarbeiter sind erfahrener als ich.

Vielleicht möchten Sie etwas langsamer fahren, zuhören und von Ihrem Team lernen, bevor Sie zu viele Änderungen vorschlagen. Es mag gute Gründe geben oder auch nicht, warum der Code so strukturiert ist, aber es kann nur helfen, sich die Zeit zu nehmen, zuerst zuzuhören und zu lernen.

Danach werden alle Vorschläge, die Sie machen, mit Sicherheit positiver bewertet und stoßen auf weniger Widerstand.

Ihre Chancen auf eine erfolgreiche Einführung von Veränderungen verbessern sich erheblich, wenn Sie den Respekt Ihrer Kollegen zuerst verdienen oder zumindest nicht verlieren.

Wie geht es? "Zweimal messen, einmal schneiden ..." So ähnlich.

Sofern Sie nicht speziell mit der Absicht beauftragt wurden, die Art und Weise, wie Ihr Team Code schreibt, zu überarbeiten, möchten Sie möglicherweise Ihre Begeisterung für drastische Überholungen abschwächen. Der meiste Arbeitscode funktioniert aus einem bestimmten Grund :) egal wie mies es ist, und manchmal machen drastische Überholungen diese nervigen Eckfälle noch hässlicher.

Ich denke, der einfachste Hebel, um kleineren Code zu schreiben, wäre, die Entwickler aufzufordern, sich auf Unit-Tests zu konzentrieren . Nichts zwingt zu präzisem Code, als wenn man ihn zum Testen auffordert . Es ist erstaunlich, wie Entwickler plötzlich eine Abneigung gegen globale Datenstrukturen haben und zu viele Objekte in zu vielen Ebenen übergeben, wenn sie wissen, dass sie Tests für alles schreiben müssen.

Ich bin kein großer Fan von TDD, aber ich mag die Tatsache, dass Entwickler gezwungen sind zu überlegen, wie sie Tests schreiben. Und das ist oft der Grund, warum der Code besser ist und nicht die Magie , die Tests tatsächlich durchzuführen. (Dies ist jedoch hilfreich, wenn Sie später Änderungen vornehmen.)

Viel Glück.

Sie sollten Ihr Team nicht überzeugen. Als Neuling werden Sie nicht ernst genommen - und verlieren Zeit.

Schreiben Sie stattdessen selbst kompakten und sauberen Code. Dann, hoffentlich nach einer Weile und einigen Codeüberprüfungen, könnten einige Teamkollegen anfangen, Ihren Stil zu imitieren.

Wenn nicht, werden Sie immer noch produktiver und Ihre harte Arbeit wird Sie irgendwann an eine höhere Position bringen, an der Sie beginnen können, einige dieser Regeln durchzusetzen.

Und ja, auf jeden Fall, zeige allen Sachen von Code Complete.

Hier sind ein paar Tricks:

• Informieren Sie sich über den aktuellen Stand und die Geschichte des Teams - es hört sich so an, als hätten sie einen Mentor, wie viel Einfluss hat der Mentor? Wie neu ist der Mentor und gab es eine lange Zeit ohne Mentor? Wann entsteht der Problemcode? Das Baby des aktuellen Teams zu kritisieren, kann sich stark davon unterscheiden, alten Code zu kritisieren, an den sich niemand mehr erinnert.

• Eine Sache zu einer Zeit - werfen Sie nicht die Bombe auf all Ihre Gedanken bei einem Team-Meeting. Beginnen Sie mit einigen vorläufigen Fragen, die aus Ihrer spezifischen Perspektive kommen. Zum Beispiel - "Hey, als der neue Typ habe ich bemerkt, dass einige der Versorgungsklassen wirklich groß sind, gibt es einen Grund dafür?"

• Vorschlagen von kleinen Schritten - Es ist fast nie möglich, eine sofortige Totalrevision durchzuführen. Überlegen Sie sich daher einige erste Schritte, falls alle zustimmen, dass dies ein guter Plan ist.

• Schlagen Sie zukünftige Präventionsmechanismen vor - zum Beispiel könnte das Team einem Ziel zustimmen, das es niemals zu den wenigen größten Klassen hinzufügt, aber umgestaltet, wenn es notwendig ist, sie weiter auszubauen.

• Hören Sie auf Bedenken bezüglich des Risikos. Wenn es sich wirklich um Legacy-Code handelt, gibt es möglicherweise genügend Unbekannte und Abhängigkeiten, die ein Refactoring äußerst riskant machen. Dies ist vielleicht kein Grund, Refactoring zu vermeiden, aber es kann bedeuten, dass Sie einige bessere Teststrategien oder eine andere Möglichkeit benötigen, um das Risiko zu verringern, bevor Sie die eigentliche Überarbeitung in Angriff nehmen.

• Achten Sie auf die Körpersprache und gehen Sie langsam. Sie sprechen ein Problem in einer Codebasis an, mit der Sie nicht viel Erfahrung haben. Sie haben jetzt ein neues Typenfenster, in dem Sie einige naive Fragen stellen und hilfreiche Antworten erhalten können, und Sie können diese Fragen verwenden, um das Team zu untersuchen, um ihre eigenen Entwurfsentscheidungen zu treffen. Aber es geht in beide Richtungen - als der neue Typ hast du auch noch keine Menge "Glaubwürdigkeit", also geh langsam und achte auf geschlossene Gesichter oder Haltungen. Wenn Leute abschalten, schlagen Sie eine Möglichkeit vor, Entscheidungen zu verzögern und nach Wegen zu suchen, um sie zu gewinnen.

Ich kann als Manager und Teammitglied sagen, dass ich mich für New Guy Insights gefreut habe. Ich habe nicht jeden einzelnen konstruktiven Kommentar eines neuen Teammitglieds akzeptiert, war aber generell bereit zuzuhören, wenn die Kritik als ehrliche Besorgnis und Neugier geäußert und nicht als Vortrag gehalten wurde. Das Zeichen des Respekts vor dem neuen Mann setzt ein, wenn er die Einsicht liefern und dann zurücktreten und alles erledigen kann - es ist einfach, sich gut zu fühlen, wenn Ihre Entscheidungen gehört und aufgegriffen werden, und es ist schwieriger, wenn das Team Ihnen "Nein" sagt. Möglicherweise haben Sie immer noch Recht. Der Trick besteht darin, herauszufinden, was als Nächstes zu tun ist. In diesen Fällen ist es ein guter nächster Schritt, ein wenig zu warten und nach weiteren Informationen zu suchen.

Wie überzeuge ich mein Team, kleinere Klassen / Methoden anzuwenden?

Nicht.

Kaufen Sie sich eine Resharper-Lizenz und gehen Sie mit gutem Beispiel voran. [Verlassen Sie sich stark auf das Refactoring mit der Extraktionsmethode .]

Im Laufe der Zeit, andere sollen kommen , um Ihren lesbaren Code zu erkennen , und dies ebenfalls zu tun überzeugt werden. *

• Ja, es besteht die Möglichkeit, dass sie nicht überzeugt werden. aber es ist immer noch die beste Wahl.

IMO - Es lohnt sich nicht, Ihre Teamkollegen zu überzeugen, bessere Programmierer zu werden. Lesen Sie ' Code Complete ' und folgen Sie @ Onkel Bob. SOLID Prinzipien und werden bessere Programmierer, wenn sie nicht bereits überzeugt sind.

Denken Sie daran: Sie können keine Logik verwenden, um zu argumentieren, dass jemand von einer Position abweicht, auf die er überhaupt nicht mit Logik gekommen ist.

Dies scheint eher eine Managementfrage als eine technische Frage zu sein. Alles, was Sie gesagt haben, ist gültig. Was Ihr Team wirklich braucht, ist ein guter Architekt, der sicherstellen kann, dass sich jeder an ein einziges Entwurfsmuster anpasst und es durchsetzt. Das Team muss den Code ständig und regelmäßig überarbeiten.

Es gibt jedoch ein anderes Prinzip: "Du wirst es nicht brauchen", wenn das, was jemals existiert hat, längere Zeit funktioniert, egal wie hässlich es ist. Es ist immer keine gute Idee, es zu ändern. Sammeln Sie stattdessen ein Dokument mit schlechten Praktiken und Problemen, bevor Sie die Codierung ausführen, wenn Ihr Team das Ganze oder einen Teil davon neu erstellen muss.

Einige Teams führen keine Qualitätskontrollen für Code durch, da sie nicht die richtigen Tools dafür kennen. Es gibt viele Tools, die einem Team dabei helfen können, den Code zu verbessern.

Visual Studio verfügt über eine "Codeanalyse", die bei der Verwendung von Namenskonventionen hilfreich sein kann.

Es könnten auch Codemetriken wie die zyklomatische Komplexität verwendet werden. Auf diese Weise können Sie auf zu komplexe Klassen und Methoden hinweisen.

Aufzeichnungen zu führen ist auch eine gute Idee. Wenn Teammitglieder nur verbal ausdrücken, was zu tun ist, müssen die Leute es vergessen. Menschen haben sehr schwache Erinnerungen! =)

Ich würde nicht viel Lärm machen ... Das Entwicklerteam eines Programmierers ist wie seine eigene Familie ... Wenn Sie auf Fehler hinweisen, können die Leute wütend auf Sie werden. Diese Art von Kulturwandel erfordert nicht nur viel Kodierung, sondern auch einen empfindlichen Umgang mit Menschen.

Als Manager möchte ich nur hinzufügen, dass mein Team beim ersten Mal guten Code schreibt. Code Reviews, TDD und so weiter. Aber sobald es in Produktion ist und funktioniert, müssten Sie ein starkes Argument abgeben, damit wir zurückkehren.

Ich folge Onkel Bobs Rat, Code immer besser zu hinterlassen, als Sie ihn gefunden haben. Wenn wir also Fehler beheben oder kleine Verbesserungen vornehmen müssen, würde ich hoffen, dass wir damals einen Teil der Aufräumarbeiten durchgeführt haben.

Aber so wie es aussieht, sieht das Geschäft wirklich zu, wie es ums Geld geht. Ich müsste ihnen klar machen, dass sie genug Nutzen aus dem Refactoring ziehen, um meinem Team die Zeit und die Ressourcen zu geben. Nur nicht zu mögen, wie der Code aussieht, ist nicht genug.

Also, wenn es funktioniert, so sehr Sie es auch hassen mögen, müssen Sie es vielleicht in Ruhe lassen.

Jetzt neuer Code, das ist anders. Das sollte guter Code sein.

Methoden mit 150 Zeilen ... Ich habe Methoden mit 10.000 Zeilen Code gesehen.

Zwei Ihrer Probleme können mit externen Tools gelöst werden :

• Etwas inkonsistente Namensrichtlinien
• Eigenschaften werden nach Möglichkeit nicht als schreibgeschützt markiert

In C # Resharper können beide Probleme überprüft werden. Namen, die nicht Ihren Richtlinien entsprechen, werden als Fehler gekennzeichnet. Eigenschaften, die nicht als schreibgeschützt markiert sind, werden ebenfalls als Fehler angezeigt. FxCop könnte auch eine Hilfe sein.

Dank des Refactorings können diese Tools auch dazu beitragen, große Methoden in mehrere kleinere aufzuteilen.

Ich weiß nicht, dass große Klassen immer so schlecht sind, wenn sie mit gut benannten Methoden gut strukturiert sind. Ich verwende Eclipse als meine IDE, so dass es eine sogenannte "Gliederungs" -Ansicht hat, die wahrscheinlich alle IDEs nur mit einem anderen Namen haben, der den Namen und die Verknüpfung zu jeder Methode in der Klasse enthält. Sie können sie alphabetisch sortieren usw. Wenn Sie dies verwenden, ist es einfach, in einer großen Klasse zu navigieren, und es ist mehr als schlecht, wirklich lange Methoden zu haben. Ich denke, es ist schwieriger, intelligent in dieser Methode zu navigieren, wenn Sie nicht wirklich damit vertraut sind. Ich befürworte keine langen Klassen, aber ich denke, dass sie in einigen Fällen handhabbar sind und nicht unbedingt in mehrere Klassen unterteilt werden müssen.

Besprechen Sie das Thema mit einigen Ihrer Teammitglieder und lassen Sie sich über die Größe der Methoden ein Bild machen. Sie werden überrascht sein, dass sie Ihnen zustimmen. Was Sie sehen, könnte das Ergebnis schlechter vorheriger Praktiken sein, ehemaliger Entwickler, die nicht mehr im Unternehmen tätig waren, oder dieser Teil war ein eiliger Job, und jetzt haben sie jemanden mit der Zeit eingestellt, ihn umzugestalten;)

Du bist immer noch der Neue. Bauen Sie sich einen guten Ruf auf, indem Sie herausfordernde Aufgaben annehmen und diese schnell und fehlerfrei erledigen. Wenn Sie versuchen, Dinge zu ändern, bevor Sie den Respekt Ihrer Kollegen verdienen, fällt es Ihnen möglicherweise viel schwerer, sich einzukaufen (und möglicherweise Ihre Kollegen zu entfremden).

Wenn Sie Wege finden, um die besseren Codierungsgewohnheiten in Ihre eigene Arbeit einzuführen, die effektiv zeigen, wie sie die Entwicklungszeit verkürzen und zu stabileren Lösungen führen, werden Sie möglicherweise sogar gefragt, wie Sie dies erreicht haben.

Neben all den anderen tollen Antworten können Sie vielleicht zwei Fliegen mit einer Klappe schlagen und eine Codebereinigung durchführen, um die Codebasis besser zu verstehen. Sie können es an Ihr Team / Ihren Manager verkaufen, um sich mit Ihnen vertraut zu machen, und Sie erhalten Feedback von Ihren Kollegen, wenn diese sich Ihre Änderungen ansehen. Dies wird Sie bei Ihrem besten Ansatz zur Lösung des Problems des schlechten Designs unterstützen.