Wie kann ich meinem Projektmanager oder leitenden Entwickler (taktvoll) mitteilen, dass die Codebasis des Projekts ernsthafte Arbeit erfordert?

Ich bin gerade einem (relativ) kleinen Entwicklungsteam beigetreten, das seit mehreren Monaten, wenn nicht sogar einem Jahr, an einem Projekt arbeitet. Wie bei den meisten Entwicklern, die sich einem Projekt anschließen, habe ich meine ersten Tage damit verbracht, die Codebasis des Projekts zu überprüfen.

Das Projekt (eine mittelgroße bis große interne Geschäftsanwendung von ASP.NET WebForms) ist mangels eines aussagekräftigeren Begriffs eine Katastrophe. Es gibt drei sofort erkennbare Probleme mit den Codierungsstandards:

1. Der Standard ist sehr locker. Es beschreibt mehr, was nicht zu tun ist (verwenden Sie keine ungarische Notation usw.) als was zu tun ist.
2. Der Standard wird nicht immer befolgt. Es gibt überall Inkonsistenzen mit der Code-Formatierung .
3. Der Standard entspricht nicht den Stilrichtlinien von Microsoft. Meiner Meinung nach ist es nicht sinnvoll, von den Richtlinien abzuweichen, die vom Entwickler des Frameworks und dem größten Beitrag zur Sprachspezifikation festgelegt wurden.

Punkt 3 stört mich vielleicht mehr, weil ich mir die Zeit genommen habe, meine MCPD mit einem Schwerpunkt auf Webanwendungen (insbesondere ASP.NET) zu erstellen. Ich bin auch der einzige Microsoft Certified Professional im Team. Aufgrund dessen, was ich während meiner gesamten Schulzeit, meines Autodidakts und meines Lernens am Arbeitsplatz gelernt habe (einschließlich meiner Vorbereitung auf die Zertifizierungsprüfungen), habe ich im Code des Projekts auch mehrere Fälle entdeckt, in denen Dinge einfach nicht erledigt werden bester Weg.

Ich bin erst seit einer Woche in diesem Team, aber ich sehe so viele Probleme mit ihrer Codebasis, dass ich mir vorstellen kann, dass ich mehr Zeit damit verbringen werde, mit dem zu kämpfen, was bereits geschrieben wurde, um Dinge auf "ihre Weise" zu tun, als wenn ich es wäre Arbeiten an einem Projekt, das beispielsweise allgemein anerkannten Codierungsstandards, Architekturmustern und Best Practices folgte. Dies bringt mich zu meiner Frage:

Sollte ich (und wenn ja, wie kann ich) meinem Projektmanager und Teamleiter vorschlagen, dass das Projekt grundlegend renoviert werden muss?

Ich möchte nicht in ihr Büro gehen, meine MCTS- und MCPD-Zertifikate herumwedeln und sagen, dass die Codebasis ihres Projekts Mist ist. Aber ich möchte auch nicht schweigen und kludgey-Code auf ihren kludgey-Code schreiben müssen , weil ich tatsächlich hochwertige Software schreiben möchte und das Endprodukt stabil und leicht zu warten sein soll.

Sie könnten Ihre Zeit damit verbringen, über Ihren Fall zu streiten. oder Sie könnten Ihre Zeit damit verbringen, aufzuräumen, während Sie weitergehen.

Pick - up Clean Code und Agile Software Development Principles, Patterns und Practices und anwenden , was Sie lernen dort , wie Sie auf dem System arbeiten. Irgendwann werden die Leute es bemerken (zum Guten oder Schlechten).

Bearbeiten Überprüfen Sie auch, wie Sie effektiv mit Legacy-Code arbeiten

Wie Sie beschreiben, geht es bei Problemen hauptsächlich darum, Codierungsstandards und Namensprobleme nicht zu befolgen. Das ist bei weitem keine Katastrophe . Zum Vergleich: Dies ist eine echte Katastrophe.

Vielleicht sind Sie an hohe Standards gewöhnt und verlangen diese? In diesem Fall kann jede Abweichung von der Perfektion als Fehler angesehen werden. Das ist eine Falle, in die man leicht fallen kann, wenn Ihre Anforderungen hoch sind, aber es ist wichtig, die Dinge im Blick zu behalten.

Ich schlage vor, Sie sprechen darüber als Verbesserung und helfen dem Team, ihre Richtlinien zu aktualisieren und sie zu coachen, damit sie sie wirklich anwenden können. Ich mag es wirklich, eine Definition von Done als Qualitätsmaßstab zu verwenden, und das Erstellen einer Definition ist eine großartige Team-Exorzisierung für sich. Aber ich denke nicht, dass Sie viel mehr daraus machen sollten, zumindest nicht als neues Teammitglied.

Winken Sie auf keinen Fall mit Ihrem MCSD herum, die Leute werden Sie nur offen auslachen, MS-Zertifikate sind nett, aber sie sind in keiner Weise eine berufliche Qualifikation!

Treten Sie einem neuen Team bei und suchen Sie nach Möglichkeiten, um Änderungen vorzuschlagen.

Warten Sie, bis Sie die Lage des Landes erreicht haben, bevor Sie einen Teamcode entfernen.

Sie könnten denken, dass das Problem Sie sind. Keines der drei Dinge, die Sie erwähnt haben, verdient eine vollständige Überarbeitung einer Anwendung. Sie sind nur pingelige Details.

Denken Sie daran, dass das Ziel der Anwendung nicht darin besteht, schönen Code zu haben, sondern ein Geschäftsproblem zu lösen. Sicher ist es schön, Code zu haben, der konsistent ist und einem guten Standard folgt, aber das Fehlen davon ist kein Grund, die gesamte Codebasis in den Papierkorb zu werfen. Nur weil der Motor ölig ist, muss er nicht umgebaut werden.

Schauen Sie, jeder hasst jede Codebasis, die er nicht geschrieben hat. Wenn Sie drei Jahre warten und sich Ihren eigenen Code ansehen, werden Sie ihn auch hassen und denken, dass er komplett neu geschrieben werden muss. Die Wahrheit ist, dass es nicht so ist. Wenn Sie nicht behaupten können, dass Sie Monate damit verbringen, den Code für Sie ästhetisch ansprechend zu gestalten, anstatt Funktionen zu erstellen, um den geschäftlichen Wert zu steigern, bellen Sie wahrscheinlich den falschen Baum an.

Nichts sagt, dass Sie klobigen Code schreiben müssen, nur weil möglicherweise einige in der Codebasis vorhanden sind. Und nichts sagt, dass der Code klobig ist, nur weil er nicht Ihrem Haustierstil entspricht. Refactor einfach, während Sie an Teilen arbeiten, an denen Sie arbeiten, und schreiben Sie guten Code, wenn Sie an neuen Sachen arbeiten.

Diese Dinge sind in Ordnung, aber wenn Sie neu im Team sind, rocken Sie das Boot noch nicht, bis Sie mit ihnen eine gewisse Glaubwürdigkeit aufgebaut haben.

Es scheint, dass Sie drei (relativ) kleinere Dinge ausgewählt haben, über die Sie sich Sorgen machen müssen. Es gibt andere Dinge, über die ich mir mehr Sorgen machen würde:

• Ist der Code gut dokumentiert?
• Entspricht der Code den Spezifikationen / Designdokumenten?
• Funktioniert der Code?
• Ist es leicht zu verstehen, was der Code tut?
• Denken Sie darüber nach, große Teile dieser Codebasis an TheDailyWTF zu senden?

Du bist seit einer Woche dort? Ich bin mir nicht sicher, ob Sie noch genug wissen, um dem Projektmanager Vorschläge zu unterbreiten. Selbst wenn Sie den Verdacht haben, dass der Code und die Praktiken dieses Teams "schlecht" sind, besteht der beste Weg, diese Dinge im Laufe der Zeit zu beeinflussen, darin, allmählich ihr Vertrauen und ihren Respekt zu gewinnen. Ein Projekt zu beginnen und dem Team nach einer Woche mitzuteilen, dass der Code neu geschrieben werden muss, ist kein guter Weg, um Vertrauen und Respekt zu gewinnen.

Konzentrieren Sie sich in den ersten Monaten darauf, ein besseres Beispiel zu geben und Fragen zu stellen, warum sie bestimmte Dinge getan haben. Seien Sie vorsichtig mit Ihrem Ton, wenn Sie diese Fragen stellen. Wenn Sie als "Besserwisser" rüberkommen, wird später niemand mehr auf Ihre Meinung hören, wenn Sie wirklich in der Lage sind, die Art und Weise zu beeinflussen, wie Dinge getan werden.

Wenn Ihr Code im Laufe der Zeit wirklich "besser" ist, werden die anderen Entwickler dies feststellen. Sie werden als Ressource zu Ihnen kommen, um ihnen zu helfen, ihre Probleme zu beheben, und dann um Ihren Rat bitten, wie sie die Dinge tun sollten. An diesem Punkt sind Sie in einer hervorragenden Position, um dem Team (und dem Management) Ihre Meinung zu Codierungsstandards und dergleichen mitzuteilen. Wie lange dieser Prozess dauert, hängt von der Organisation ab. Es kann nur ein paar Wochen in einer sehr anpassungsfähigen Umgebung sein oder Monate bis Jahre in einer stoischeren Kultur. Bauen Sie Ihren Einfluss einzeln auf.

Sie werden nie einen neuen Job annehmen, bei dem Sie denken, dass die Codebasis perfekt ist und alles auf die "richtige" Weise erledigt wurde. Lerne dies zu akzeptieren. Alles, was Sie mit Legacy-Code tun können, ist Refactor und Schritt für Schritt vorwärts. Einige Dinge möchten Sie erst umgestalten, wenn Sie besser verstehen, warum sie das getan haben, was sie getan haben. Außerdem wird Sie niemand im Geschäft dafür bezahlen, dass Sie den Arbeitscode reparieren. Sie müssten also ein Geschäftsmodell erstellen, um herauszufinden, warum er Arbeit benötigt, bevor Sie sich anstrengen und die Zeit verbringen. Sie sollten besser darauf warten, den Code umzugestalten, wenn Sie trotzdem eine Änderung vornehmen müssen. Sie haben möglicherweise nicht die Methode gewählt, die sie für einige Dinge angewendet haben, aber wenn sie funktioniert, sollten Sie sehr vorsichtig sein, wenn Sie sie ändern und neue Fehler einführen. Besonders wenn Sie nicht aufgefordert wurden, es zu ändern.

Nach einer Woche haben Sie keine Glaubwürdigkeit mehr, wichtige Vorschläge zu machen, wie sie Geschäfte machen. Wenn Sie jetzt etwas ansprechen, werden die Leute über Sie lachen und Sie niemals ernst nehmen. Beweisen Sie sich zuerst mit einem guten Code, und dann neigen die Leute eher dazu, zuzuhören.

Und ehrlich gesagt kümmert es niemanden, dass Sie ein Microsoft Certified Professional sind. Jeder mit viel Erfahrung hat so viele schlechte Programmierer gesehen, die diese Zertifizierung hatten, wie gute Leute. Ich sage nicht, dass es Sie schlecht aussehen lässt, eine Zertifizierung zu haben. Ich sage, dass wir ihnen nicht viel Glauben schenken, weil wir nicht gesehen haben, wo sie effektiv sind, um uns zu zeigen, wer ein guter Programmierer ist.

Ich würde wahrscheinlich versuchen, herauszufinden, wie der Vorschlag präsentiert werden soll, mit der Absicht, dass Sie Ihre Position möglicherweise nicht angemessen rechtfertigen können. Einige Fragen, über die Sie bei der Erstellung dieses Vorschlags nachdenken sollten:

• Wie viel geschäftlichen Wert wird durch die hier beschriebenen Änderungen erzielt?
• Haben Sie Optionen in Betracht gezogen, z. B. das Neuschreiben der Anwendung von Grund auf neu, das Ändern des vorhandenen Codes, um ihn auf den neuesten Stand zu bringen, oder nur kleine Änderungen im Laufe der Zeit?
• Wissen Sie, welche Funktionen und Fehler jetzt gewünscht werden, die Sie daran hindern würden, die gewünschten Änderungen vorzunehmen?

Ich kann es zwar begrüßen, die schlechte Codebasis reparieren zu wollen, aber dies muss abgewogen werden, damit es aus geschäftlicher Sicht sinnvoll ist, dies zu tun.

Sie sind derzeit nicht in der Lage, den fehlerhaften Code zu verhindern. Sie müssen also herausfinden, wie Sie ihn enthalten können.

Die PMs und Teamleiter werden sich nur darum kümmern, dass es nicht funktioniert. Ihre nächste Sorge wird sein, wenn sie Sie bitten, Änderungen vorzunehmen und sich zu fragen, warum "einfache" Dinge so lange dauern. Hier kommen Sie ins Spiel.

Beginnen Sie jetzt mit dem Konsistenzproblem. Was auch immer die potenziell standardmäßige Methode derzeit ist, versuchen Sie, sie zu identifizieren und festzustellen, ob Sie sie nicht durchsetzen können. Wenn Sie mit Methoden beginnen, mit denen niemand sonst vertraut ist, werden Sie eine Menge Zurückschub bekommen.

Andere Teammitglieder möchten sich möglicherweise zertifizieren lassen, und Sie sind eine großartige Ressource. Hoffentlich wollen sie sich zumindest verbessern und auf dich schauen, um ihnen den Weg zu zeigen.

Wenn Sie sich über die ungarische Notation beschweren, werden Sie kein Mitgefühl bekommen und es ist wahrscheinlich eine der letzten Schlachten auf der Prioritätenliste.

Ich bin damit einverstanden, dass Sie diesbezüglich vorsichtig sein müssen. Sie müssen innerhalb des Teams einen guten Ruf aufbauen, bevor Sie Kritik äußern und tiefgreifende Änderungen im Code oder in den Prozessen vorschlagen können. Ich machte mir vorerst nur Notizen zu meinen Erkenntnissen und Vorschlägen und nutzte die Gelegenheit, um die Teammitglieder und das Management kennenzulernen, kostenlose Diskussionen zu führen, aber nicht abzulehnen, wenn sich das Gespräch auf Qualitätsprobleme, Kodierungsfragen usw. bezieht, manchmal sogar zu werfen Einige meiner eigenen Fragen zum Teich (aber in allgemeiner Form nicht zu sehr auf konkrete Probleme hingewiesen, die ich in dieser Codebasis gesehen habe). Auf diese Weise kann ich die Meinung der Teammitglieder kennenlernen und potenzielle Verbündete finden.

Im besten Fall stellen Sie möglicherweise fest, dass ein erheblicher Teil des Teams (und / oder des Managements) dieselben Probleme wie Sie sieht. Es gab lediglich keine Initiative, etwas dagegen zu unternehmen, oder keine Ressourcen, die ihm vom Management gewährt wurden. Gemeinsam haben Sie mehr Mitspracherecht, um das Management bei Bedarf zu überzeugen.

Wie @Mike vorgeschlagen hat, ist es sicherlich notwendig, einen Teil der Bereinigung selbst durchzuführen, aber auch hier sollten Sie etwas Geduld damit haben. Wenn Sie zu schnell anfangen, können Sie andere Teammitglieder entfremden, die dies als persönliche Kritik ansehen. Auch die Eingabe einer umfassenden Codebereinigung / -umgestaltung kann von Ihrem Manager als Zeichen dafür gewertet werden, dass Sie sich nicht genug auf die eigentliche Aufgabe konzentrieren. Sie sollten also ein Mandat für die Umgestaltung erhalten, bevor Sie sich auf eine ernstere Ebene begeben. Kleine lokale Änderungen sind wahrscheinlich in Ordnung.

Um das Management zu überzeugen, benötigen Sie außerdem geschäftliche Gründe. Das Management wird selten durch Beschreibungen des inkonsistenten Codierungsstils bewegt. Sie müssen ihnen zeigen, welchen Wert die vorgeschlagenen Änderungen für das Unternehmen haben können - das Endergebnis ist das Geld. Wenn Sie eine überzeugend aussehende Berechnung über die Kosten und den langfristigen Nutzen verschiedener vorgeschlagener Änderungen erstellen und zeigen können, dass das Gesamtgleichgewicht eindeutig positiv ist, haben Sie Ihre Chancen spürbar verbessert.

Mach es selbst. Wenn Sie bestimmte Codierungsstile schätzen, arbeiten Sie an Code, der gegen die Codierungsstile verstößt . Checken Sie einen fehlerhaften Code aus der Quellcodeverwaltung aus, formatieren Sie den Code gemäß den Whitespaces-Anforderungen des Stils neu (als Beispiel) und übergeben Sie den aktualisierten Code mit der Meldung "Konform mit der Whitespace-Regel des Style Guides".

Nach einer Woche ist das Schlimmste, was Sie wahrscheinlich tun können, damit direkt zum Management zu gehen. Höchstwahrscheinlich haben sie viel Zeit in den Code gesteckt und sind ein wenig stolz darauf. Sie würden wahrscheinlich als strenges "alles wissen" abschneiden.

Was ich tun würde, wenn ich Sie wäre, ist es zu verbessern, während Sie fortfahren. Wenn Sie sich damit vertraut machen und daran arbeiten, haben Sie die Möglichkeit, es zu verbessern. An diesem Punkt würde ich anfangen, anderen Mitarbeitern die Vorteile Ihrer Arbeit zu zeigen. Wenn die Designmeetings für neue Module anstehen, legen Sie anschließend ein Argument für das vor, was Sie als den besten Weg betrachten.

Und ehrlich gesagt gibt es Standards aus einem bestimmten Grund, aber wenn es funktioniert und gut funktioniert, ist es in meinem Buch 100-mal mehr wert (besonders nach einer Woche in). Ich wäre besorgter, wenn Sie den Code öffnen und Tonnen von Logikfehlern oder Ähnlichem sehen würden.

Gehen Sie mit diesem „Problem“ nicht direkt zum Management.

Sprechen Sie zuerst mit Ihren Mitarbeitern und finden Sie von ihnen heraus, warum die Dinge so sind, wie sie sind. Dann können Sie besser beurteilen, ob ein Problem vorliegt oder nicht. Sie werden überrascht sein, was Sie lernen. Sie können auch Verbündete finden, die wollen, dass es gereinigt wird.

Wenn Sie keine Ahnung haben, wie Sie überhaupt dorthin gekommen sind, wo Sie sich gerade befinden, ist es viel schwieriger, herauszukommen.

Hier gibt es bereits viele gute Vorschläge, und ich bin der Meinung, dass Sie Ihre Brücken nicht verbrennen müssen, bis Sie sich wie die anderen als erste Meinung erwiesen haben. Was ich hinzufügen möchte, ist, die Dinge mit Ihren Teamkollegen zu besprechen, bevor Sie sie entfremden, indem Sie zuerst zum Projektmanager oder Teamleiter gehen. Und zeigen Sie ihnen sicherlich vorher, dass Sie ernst genommen werden sollten.

Es klingt auch so, als wäre es eher ein Stilproblem, das Sie mit dem Code haben. Den Code eines anderen zu übernehmen und die Nase zu halten, während man sich an die Art und Weise gewöhnt, wie er geschrieben wurde, ist nur ein Teil des Jobs, auch wenn es eine triviale Sache ist, wie sie ihn formatiert. Noch schlimmer ist es, wenn Sie eines Ihrer "Babys" an jemand anderen übergeben, damit dieser es mit seinen schmutzigen Händen zerfleischen kann ...

Wenn es letztendlich mehr als das ist - und das Problem mehr funktional als nur stilistisch ist -, wenn Sie zum Teamleiter / pm gehen, ist es am besten, die Notwendigkeit einer Nacharbeit dahingehend anzugeben, wo dies in Zukunft Geld und Mühe sparen würde Entwicklungsprojekt. Gutes altes Refactoring.