Was ist das / Gibt es eine richtige Möglichkeit, dem Management mitzuteilen, dass unser Code nicht funktioniert?

Unser Code ist schlecht. Es wurde vielleicht nicht immer als schlecht angesehen, aber es ist schlecht und geht nur bergab. Ich habe vor weniger als einem Jahr frisch vom College angefangen, und viele der Dinge in unserem Code rätseln mich unglaublich. Zuerst dachte ich mir, dass ich als Neuling den Mund halten sollte, bis ich etwas mehr über unsere Codebasis gelernt hatte, aber ich habe viel gesehen, um zu wissen, dass es schlecht ist.

Einige der Highlights:

• Wir verwenden immer noch Frames (versuchen Sie etwas aus einem Querystring herauszuholen, fast unmöglich)
• VBScript
• Source Safe
• Wir verwenden .NET - ich meine, wir haben .net-Wrapper, die COM-DLLs aufrufen, was ein einfaches Debuggen fast unmöglich macht
• Alles ist im Grunde eine riesige Funktion
• Code ist nicht wartbar. Jede Seite enthält mehrere Dateien, die jedes Mal erstellt werden, wenn eine neue Seite erstellt wird. Die Hauptseite verwendet Response.Write () ein paar Mal, um den HTML-Code zu rendern (runat = "server"? No way). Danach kann es auf der Client-Seite (VBScript) eine Menge Logik geben, und schließlich übergibt sich die Seite selbst (häufig speichert sie viele Dinge in verborgenen Feldern), wo sie dann auf eine Verarbeitungsseite sendet, die Dinge wie das Speichern der Datei ausführen kann Daten in die Datenbank.
• Die Spezifikationen, die wir bekommen, sind lächerlich. Oft fordern sie Dinge wie "Feld X automatisch mit Feld Y oder Feld Z ausfüllen", ohne anzugeben, wann Feld Y oder Feld Z ausgewählt werden soll.

Ich bin mir sicher, dass ein Teil davon darauf zurückzuführen ist, dass ich nicht bei einem Softwareunternehmen angestellt bin, aber ich habe das Gefühl, dass die Leute, die Software schreiben, sich zumindest um die Qualität ihres Codes kümmern sollten. Ich kann mir nicht einmal vorstellen, dass, wenn ich etwas anspreche, bald etwas unternommen wird, da eine große Frist ansteht, aber wir weiterhin schlechten Code schreiben und schlechte Praktiken anwenden.

Was kann ich machen? Wie bringe ich diese Probleme überhaupt zur Sprache? 75% meines Teams sind mit mir einverstanden und haben diese Probleme in der Vergangenheit angesprochen, aber es ändert sich nichts.

Stellen Sie sicher, dass Sie nicht überreagieren. Sie sind frisch, haben wahrscheinlich noch nicht an vielen (irgendwelchen?) Anderen Orten gearbeitet und sind daher nicht auf die Welt des "echten Code" vorbereitet. Real Life Code ist eine schreckliche Sache. Es ist, als ob Ihr netter Schulcode und Ihr zwanghaft veränderter persönlicher Projektcode Sex im Keller eines Atomreaktors hatten und das Baby in einem Abwasserkanal mit Giftmüll aufwuchs. Es ist eine schreckliche Mutante.

Aber wenn Sie Recht haben und der Code so schlecht ist, wie Sie sagen (dh schlechter als der normalerweise schlechte Code), haben Sie Recht, besorgt zu sein. Sprechen Sie mit Ihrem Team und stellen Sie fest, ob alle anderen auf der Seite sind. Es wird Arbeit erfordern, um die Situation zu verbessern. Wenn der Rest des Teams das Problem erkennt, es aber nicht kümmert, verschwenden Sie Ihre Zeit.

Als Junior bist du wahrscheinlich nicht in der Lage zu führen. Wenn Sie als Neueinsteiger, der auch Junior ist, selbst zur Geschäftsführung gehen, wird Ihre Meinung wahrscheinlich außer Acht gelassen. Holen Sie sich Ihren Hauptentwickler oder einen der erfahrensten Beteiligten. Auch hier verschwenden Sie Ihre Zeit, wenn keiner der Senioren daran interessiert ist.

Unter der Annahme, dass Sie einige hochrangige technische Mitarbeiter interessieren, würde ich daran arbeiten, Problembereiche und mögliche Lösungen zu identifizieren. Wenn zum Beispiel "alles im Grunde eine Riesenfunktion ist", sollten Sie das nächste Mal, wenn Sie in dieser "Riesenfunktion" arbeiten, vielleicht ein wenig überarbeiten. Auch hier müssen Sie alle in den Griff bekommen. Wenn Sie kleine Teile Ihres Problems auflösen und Stück für Stück verbessern, werden sie letztendlich viel weniger zum Problem. Überlegen Sie bei jeder Berührung eines Codeteils, ob eine Verbesserung möglich ist.

Sie werden sich nicht mit dem Management zusammensetzen und sagen: "Alles ist schlecht und muss neu geschrieben werden." Das macht für sie keinen Sinn - kostet viel und ist potenziell sehr riskant. Stattdessen sollte ihnen bewusst gemacht werden, dass es Probleme gibt und dass ein Plan besteht, sich langsam zu verbessern, wenn Änderungen vorgenommen werden. Sie sollten über die Vorteile von wartbarem Code informiert werden. Dies sollte von einer älteren Person kommen, der sie technisch und professionell vertrauen - nicht von Ihnen.

Vollständiges Umschreiben? Fast immer eine schlechte Idee.

Letztendlich können Sie nicht viel tun, weil Sie neu sind. Wenn niemand etwas verbessern will, sammelst du deine Erfahrungen und gehst zum nächsten Ort.

Lesen Sie Joel On Software - Dinge, die Sie niemals tun sollten. Verstehe seine Argumentation und lies dann ein paar andere Artikel über schlechte Software und wie man sie behebt, die von Managern und nicht von Programmierern geschrieben wurden. Mit diesen Informationen können Sie einen Fall für dessen Behebung vorstellen, der von den Managern verstanden und beachtet wird. Tipp: Gute Manager geben nicht nur Zeit und Geld aus, die auf den Meinungen und Gefühlen der Programmierer darüber beruhen, was getan werden muss.

"Dieser Code ist Mist und muss umgeschrieben werden" wird sicherlich auf Sie zurückgeworfen, auch wenn Sie technisch korrekt sind.

"Wir können den aktuellen Projektzeitplan um Monate kürzen, weniger kosten und ihn zuverlässiger machen." werden ihre Aufmerksamkeit auf sich ziehen (bemerken Sie die fehlende Erwähnung dessen, wie Sie dies auf seiner Bühne tun wollen).

Was auch immer Sie sagen, seien Sie sicher, dass Sie richtig sind. Wenn du sagst, dass es schlecht ist, muss dein Umschreiben blutig gut sein. Wenn du sagst, dass es eine Woche dauern wird, solltest du dir sicher sein, dass es eine Woche und gut sein wird. Jeder Fehler im überarbeiteten Code kostet Sie persönlich sehr viel, unabhängig davon, was passiert wäre, wenn Sie die Überarbeitung nicht durchgeführt hätten. Wenn jemand vor Ihnen dort war und eine Umschreibung vermasselt oder überverkauft hat, geben Sie auf, Manager mögen es nicht, zum Narren gehalten zu werden, und lassen es nicht zweimal zu. Also, vermasseln Sie es nicht für die Jungs, die folgen, Sie bekommen nur einen Schuss auf diese ...

Finden Sie Möglichkeiten, die Kosten über einen bestimmten Zeitraum oder eine bestimmte Anzahl von Projekten zu verteilen. Manager hassen Risiko, spekulative Investitionen und negativen Cashflow - arbeiten Sie innerhalb der Toleranzen Ihrer Manager. Beginnen Sie mit einem kleinen, risikoarmen und kostengünstigen Vorschlag. Sobald Sie Recht haben, können Sie sich für den größeren Fisch entscheiden.

Zuallererst finden Sie an jedem Ort, an dem Sie als Programmierer arbeiten, doofes Legacy-Zeug, es sei denn, Sie arbeiten bei einem Start-up und Sie sind derjenige, der den ursprünglichen doofen Legacy-Code erstellt. Sie müssen in der Lage sein, mit diesen Schlägen zu rollen, wenn Sie eine Karriere in der Programmierung planen.

Zweitens gibt es häufig Kostenaspekte bei der Verbesserung alter Systeme. Zum Beispiel habe ich mehr als eine Firma gesehen, die 10 Jahre alte VB6- und klassische ASP-Anwendungen noch in Betrieb hatte. In einigen Fällen war dies darauf zurückzuführen, dass ein großes Projekt zum Verschieben von .NET nicht erfolgreich war. In anderen Fällen lautete der Grund: "Wenn es nicht kaputt ist, beheben Sie es nicht." In anderen Fällen sind die Umzugskosten gerechtfertigt, da Probleme, die durch das Altsystem verursacht werden, zu groß sind, um ignoriert zu werden.

In Situationen, in denen in der Vergangenheit ein großer Fehler aufgetreten ist, ist es fast unmöglich, eine Änderung herbeizuführen. In diesem Fall sollten Sie Ihren Lebenslauf aufpolieren und nach einem neuen Job suchen. Wenn es nicht kaputt ist, haben Sie wahrscheinlich keinen Grund, sich über den Code selbst zu beschweren, aber Sie befanden sich nicht auf einem erfüllenden und wachsenden Karriereweg. Wenn es kaputt ist und es sich so anhört, als wäre es in Ihrem Fall, dann haben Sie die Chance, etwas zu verändern.

Der beste Ansatz, den ich gesehen habe, ist, nicht zu viel abzubeißen, sondern mit inkrementellen Änderungen zu beginnen, die die positivsten Auswirkungen haben. Basierend auf Ihrer Beschreibung wäre eine bessere Verwaltung von Änderungsanforderungen ein Ausgangspunkt. Sobald dies unter Kontrolle ist, können Sie mit der Erstellung eines Service-Frameworks oder anderer inkrementeller Design- / Code-Verbesserungen beginnen.

Der schlimmste Ansatz, den ich je gesehen habe, ist der Versuch, einen großen Sprung direkt von einem Legacy-System zum neuesten und besten zu machen, z.

"Hey Boss, nach Big Project möchten ich und das Team einige Zeit, im Idealfall X Monate, um unseren Code zu organisieren. Dinge, die in Minuten erledigt werden können, dauern Stunden, weil alles sehr unorganisiert ist. Wenn es nicht möglich ist Wir möchten gleich nach dem Big Project einen realistischen Zeitplan erstellen. "

(teilweise umschrieben von Azkars Kommentar zu der Frage)

Beginnen Sie mit dem Lesen von Joel on Software (Joel Spolsky / Gründer von Stack Exchange) ...

Das ERSTE, was ich tun würde, ist einen Joel-Test durchzuführen .

Auf diese Weise können Sie es als "Während ich nach Verbesserungsmöglichkeiten als Entwickler gesucht habe ... bin ich auf diesen 12-Fragen-Test zu Entwicklungsumgebungen gestoßen, und zum Spaß habe ich ihnen geantwortet, wo ich arbeite." ... Dies wiederum macht es zu einer dritten Partei, die umreißt, was mit Ihrem Code falsch ist und nicht mit Ihnen persönlich.

Wenn Sie mehr über Pragmatic Practices lesen , verbessern Sie sich selbst und implementieren Dinge wie Rot / Grün / Refaktor. Auf diese Weise können Sie die Codebasis bereinigen, damit sie gewartet werden kann. (im Laufe der Zeit)

Ich hoffe, das hilft! Willkommen beim Programmieren (Code von gestern ist normalerweise beschissen) ;-)

Kurztipp: Wenn Sie die Verwaltung mit einer Liste von Gründen vorschlagen, warum Sie anders codieren sollten, geben Sie als Argument "Verbesserte Arbeitsmoral / Arbeitsbedingungen für die Programmierer" an.

Machen Sie deutlich, dass das Tech-Team mehr Inhalte schreibt und sauberen Code verwaltet als dieses aktuelle Chaos, und dies kann Ihre Einstellung zur Arbeit sicherlich verbessern. Könnte ein nützliches Argument sein.

• Gibt das Management tatsächlich das Design vor? Wenn Sie den größten Teil des Teams hinter sich haben, was hindert Sie daran? Sei proaktiv und entscheide als Gruppe. Überlegen Sie sich einen Plan, um ihn schrittweise umzusetzen . Dann tu es.
• Gibt das Management die von Ihnen verwendeten Entwicklungstools vor? Es sei denn, es gibt einen Zeitaufwand für das Auswechseln einer Werkzeugverwaltung, ist das normalerweise egal. Seien Sie proaktiv und entscheiden Sie als Gruppe, welche Entwicklungstools Sie verwenden möchten. Wenn Sie ein Buy-off vom Management benötigen, zeigen Sie ihnen einen Migrationsplan und eine Kosten-Nutzen-Analyse. Dann tu es.
• Gibt das Management die von Ihnen verwendeten Sprachen vor? Seien Sie proaktiv und entscheiden Sie als Gruppe, was anstelle von VBScript verwendet werden soll. Überlegen Sie sich einen Plan, wie Sie ihn schrittweise umsetzen und umsetzen können. Wenn Sie ein Management-Buy-off benötigen, zeigen Sie ihnen den Plan. Dann tu es.
• Ich habe nichts für Spezifikationen. Das hängt in der Regel stark von den Menschen und Prozessen bei Ihrer Arbeit ab. Das Erkennen von Fehlern und minimalen Änderungen, die zur Behebung des Prozesses erforderlich sind, erfordert Zeit, Analyse und Verständnis dafür, wie die Dinge derzeit funktionieren und wie sie funktionieren sollten. Wenn Sie wissen, dass Sie einen Plan erstellen und versuchen können, das Management zu überzeugen.

Sie erhalten mehr Veränderung und Respekt, wenn Sie Änderungsvorschläge unterbreiten, die nicht viel Zeit in Anspruch nehmen und für die kein (oder ein geringer) geschäftlicher Wert erkennbar ist.

Aus Erfahrung sprechen: Es ist nicht einfach. Es ist fast unmöglich. Das Management kümmert sich nicht darum, dass der Code scheiße ist und höchstwahrscheinlich völlig ahnungslos und / oder ahnungslos in Bezug auf die Probleme ist, mit denen es konfrontiert ist, oder sie hätten ihn schon vor langer Zeit behoben, und Sie wären heute nicht mehr dran. Das Beste , was Sie tun können , ist eine Liste der Gründe , warum machen Sie den Code saugt, und dann die Argumentation hinter warum es saugt tatsächlichen Geschäftswert in Refactoring zu demonstrieren / Umschreiben es.

Ein Beispiel könnte für "Code ist nicht wartbar" sein:

Der aktuelle Code kann aufgrund von X , Y und Z nicht gewartet werden (Liste der Gründe, warum er nicht gewartet werden kann). Dies erschwert das Ausführen von Änderungsanforderungen und neuen Funktionen, da X , Y , Z (Gründe, warum das Vornehmen von Änderungen schwierig ist). Da Änderungen schwierig sind, kann das Entwicklungsteam nicht einfach auf Fehlerbehebungen und Verbesserungen reagieren.

Ihre einzige Hoffnung ist, dass Ihr Chef und die Geschäftsleitung nicht zu dumm sind, um zu verstehen, welche Konsequenzen dies für den Code hat, und bereit sind, keine neuen Feature-Anfragen mehr zu veröffentlichen, um die Probleme zu beheben. Andernfalls werden Ihre Bemühungen vergeblich sein . Aus früheren Erfahrungen ist es sehr wahrscheinlich, dass sie keine Fehler im Code sehen und / oder Ihre Mitarbeiter zu rückgratlos sind, um ihre Bedenken an das Management weiterzuleiten.

Viel Glück. Du wirst es brauchen.

"Ich habe frisch vom College angefangen" - sollte deine Frage beantworten.

Das Management weiß wahrscheinlich, dass der Code nicht optimal ist. Der meiste Code ist, es sei denn, Sie haben Ray Gosling, Guido Van Rossum oder jemand anderen engagiert, der wirklich gut und teuer ist, um ihn zu schreiben.

Das Management weiß auch, dass es mit der für Ihr Unternehmen geltenden Definition von "funktioniert" funktioniert (stürzt nicht ab, verkauft, liefert die Berichte oder was auch immer).

Sie möchten, dass Sie den Code zu minimalen Kosten "arbeiten" lassen. Sie wollen nicht, dass ein Vorschlag für ein teures Projekt alles neu schreibt.

Es ist fast unmöglich, einen Business Case zu erstellen, da es sich bei Ihrer Lieferung um funktionierende Software handelt (die bereits über einen eleganten Code verfügt).

Hinzu kommt die Tatsache, dass bei Software große Opportunitätskosten anfallen, wenn Funktionen zuerst auf den Markt gebracht werden. Wenn Sie wirklich darüber nachdenken, ist die langfristige Amortisation der Zeitinvestition nicht garantiert.

Das heißt, es ist immer noch ein guter Plan, die kleinen Dinge (wie das Erhalten eines guten VSS) auf dem Weg in handlichen Bissen umzugestalten und zu reparieren. Letztendlich handelt es sich um ein technisches Problem, nicht um ein Managementproblem. Tun Sie einfach, was getan werden muss, während Sie das halten, was Sie versprechen, und es wird Ihnen gut gehen. Das Management wird wahrscheinlich nicht an den wirklich wichtigen Details der Codequalität interessiert sein, selbst wenn Sie eine starke Argumentation vertreten.

Gehen Sie einfach, sobald Sie können (vielleicht nicht zu schnell, wenn Sie nicht wie ein Job Hopper aussehen wollen). Die Tatsache, dass sie Code ist ein Chaos und die Leute bleiben, bedeutet, dass Sie wahrscheinlich mit armen Entwicklern arbeiten. Jeder anständige Entwickler, der sich um seine Arbeit kümmert, würde nicht lange daran arbeiten.

Die Wahrscheinlichkeit, dass ein Umschreiben auftritt, ist ziemlich gering, es sei denn, Sie können ganz klar nachweisen, dass es sich lohnt, wenn Sie Geld investieren.

Das Management kümmert sich nicht um den Code. Ihnen ist es wichtig, ein Produkt zu verkaufen.

Wenn das Altsystem wirklich sehr, sehr schlecht ist und es für die Mehrheit des Teams einen lächerlichen Overhead bedeutet (ich sage die Mehrheit, weil es immer jemanden gibt, der entweder große Teile oder alles codiert und es wie die Rückseite kennt) Dann nähern Sie sich ihnen und sagen, dass dies das Geschäftsgeld in der Entwicklungszeit kostet und sich negativ auf die Kundenzufriedenheit auswirkt.

Aber noch einmal, sie interessieren sich immer noch nicht für Code, sie interessieren sich für ein Produkt, und obwohl diese Antwort sie dazu bringt, "Ja, lass es uns tun", können Sie den Code auch aufräumen, ohne die Erlaubnis eines Managers einzuholen. Gehen Sie nicht über Bord, stellen Sie sicher, dass Sie zuerst mit dem Team sprechen. Niemand kommt gerne und versucht, diese Funktion zu verwenden, für deren Schreiben Sie 3 Monate gebraucht haben. Sie scheint jetzt nicht zu funktionieren, da sie gehackt wurde.

Approach Management auf eine Weise, dass Sie zeigen, dass Sie die Auswirkungen von großen Änderungen am Code auf das Budget und die Auswirkungen von NICHT durchgeführten Änderungen auf das Budget verstehen. Ich mochte Emilios Formulierung.

Es ist wichtig zu beachten, dass "alter" Code immer schrecklich sein wird. Damit meine ich, dass wir alle als Entwickler ständig wachsen. Wir schreiben guten Code und lernen später, besseren Code zu schreiben, und der vorherige "gute" Code scheint schrecklich. Zu viele Entwickler sind ständig damit beschäftigt, Verbesserungen vorzunehmen und auf lange Sicht mehr Geld zu verschwenden. Es ist ein Balanceakt. Trotzdem ist es immer großartig, wenn Sie es auf Ihrem Weg verbessern können. Wenn Sie diese Riesenfunktion ändern möchten, teilen Sie sie auf! Irgendwann kommst du irgendwohin.

Tu es nicht.

Es ist sowieso meistens ein großer Fehler, ein großes Projekt von Grund auf neu zu schreiben.

Ich hätte nie gedacht, dass es einfach ist, Managern, insbesondere Projektmanagern, über schlechten Code und Refactoring zu informieren. Erstens müssen sie dir vertrauen, auch wenn du ein älterer Typ bist, brauchst du noch Zeit, um vertraut zu werden. Zweitens verstehen sie einfach nicht, wie schlimm das Problem ist. Wenn heute der letzte Tag ist, an dem ein neuer Build veröffentlicht wird, und der Build fehlschlägt. Sie wissen, wie ernst es ist, aber sie wissen nie, dass der Build einfach fehlgeschlagen ist, weil viele Probleme wie schlechter Code, unzureichende Tests usw. aufgetreten sind.

Ich habe Konfigurations- und Bereitstellungsaufgaben in einem Webprojekt ausgeführt. Die Behebung unerwarteter Probleme bei jeder Bereitstellung eines neuen Builds nimmt häufig viel Zeit in Anspruch. Die meisten Probleme betrafen Sicherheit und Integration (zwischen mehreren Web- / Windows-Anwendungen). Unser Code ist zum Kotzen, der Code anderer ist zum Kotzen, sie sind komplett Spaghetti-Code.

Wir planten eine neue Version und ich bat dringend um ein Refactoring. Fügen Sie einfach ein Detailprotokoll zum Login- / Authentifizierungscode hinzu, in dem häufig Fehler aufgetreten sind. Die Manager waren einverstanden, aber dann wurde es in eine nette Liste aufgenommen, und ich weiß nicht, ob dies geschehen wird, da wir bereits eine große Liste an Funktionen und einen engen Zeitrahmen hatten.

Es gibt zwei Arten von Managern: diejenigen, die vorgeben zu verstehen, was Sie tun, und diejenigen, die es nicht tun. Diejenigen, die vortäuschen, Software zu verstehen, werden Ihnen feindlich gesinnt sein. Diejenigen, die sich nicht nur über dich ärgern.

In jedem Fall sind Manager allesamt Lügner, so dass sie stark davon ausgehen können, dass es alle anderen tun.

Mein Punkt ist, wenn Sie sagen, dass die Software veraltet ist, werden sie es nur als Entschuldigung nehmen. Es ist ihnen egal.