Vergangenheit: Beginnen Sie einen neuen Job als Software-Ingenieur nach dem College. Zugewiesen an ein unkommentiertes, undokumentiertes Durcheinander eines Projekts ohne Training oder Mentoren. Ich bin die einzige Person, die an diesem Projekt arbeitet, niemand sonst kennt oder hat den Code jemals gesehen .
Ich sage meinem Manager, dass der Code sehr durcheinander ist und Fehler enthält, aber er sagt mir, ich solle an Funktionen arbeiten, anstatt den Code zu reparieren. Jetzt sind Monate vergangen und es ist bald an der Zeit, dem Kunden das Programm zu zeigen, und ich mache mir Sorgen, dass ich bestraft werde, weil ich ein teilweise „kaputtes“ Programm gegeben habe.
Da Refactoring aufgrund von Zeitdruck und Managerwünschen keine Option ist und nie war, was kann ich tun, um meinem drohenden Untergang zu entgehen? Ich habe das Gefühl, dass ich von Anfang an ungewollt zum Scheitern verurteilt war. Ich denke sogar, dass ich die Sache noch verschlimmert habe, indem ich dem fehlerhaften Code Funktionen hinzugefügt habe, da ich einige seltsame Dinge tun musste, um die Fehler zu umgehen.
Wie kann ich es vermeiden, für ein von mir geerbtes Projekt bestraft zu werden, das bereits fehlerhaft war, während mir gesagt wurde, ich solle an mehr Funktionen arbeiten, anstatt Fehler zu beheben?
BEARBEITEN: Ich habe das Gefühl, dass dies anders ist als die mit Duplikat markierte Frage, da ich ein brandneuer Entwickler mit 0 Jahren Erfahrung bin. Ich habe das Gefühl, dass dies ein wichtiger Aspekt meiner Situation ist.
Sie kennen diese Software jetzt besser als jeder andere.
Konzentrieren Sie sich also bei der Demonstration auf die Teile, die gut funktionieren (oder zumindest so funktionieren, wie sie sollten). Alle anderen Funktionen, die derzeit nicht so gut funktionieren, können als „in Arbeit“ oder „Prototyp“ gekennzeichnet werden. Verwenden Sie diese, um zu besprechen, wie diese Funktionen verbessert werden können (oder, noch besser, lassen Sie sich sagen, dass diese nicht wichtig sind).
Es wäre auch eine gute Idee, Schritte für die Demonstration zu notieren und die zu demonstrierende Version des Programms vorher durchzuspielen, damit Sie alles notieren können, was schief gehen könnte. Sie können dann sagen "das sollte ..." und bevor Sie es in der Demo tun, sagen, was schief gehen könnte und dass es in Ihrer "to-do"-Warteschlange behoben werden muss. Auf diese Weise müssen Sie nicht "ähm ... ähm ... das sollte nicht passieren."
Schauen Sie sich natürlich an, was Sie demonstrieren, und wissen Sie, was funktioniert und was nicht. Sehen Sie sich auch alle Dokumentationen an / sprechen Sie mit Leuten und verstehen Sie, was funktionieren sollte und wie. Das Demonstrieren von Wissen und das Zeigen von Vertrauen in das System wird Vertrauen in Sie und das, was Sie sagen, erzeugen. Dies wird Ihnen helfen, die Dinge wieder auf die Schienen zu bringen.
Es bleibt Ihnen und Ihrem Vorgesetzten überlassen, wie Sie Ihre Rolle darin darstellen – dh wenn Sie ihnen mitteilen, dass der ursprüngliche Entwickler das Projekt verlassen hat und Sie die Zügel übernehmen mussten. Die Leute neigen dazu, Ehrlichkeit mehr zu respektieren als Unehrlichkeit, und Versuche, einen früheren Entwickler zu vertuschen, werden ausnahmslos als Vertuschung angesehen (und die Leute mögen das nicht).
Vorausschauend zu sein, kann Vorteile bringen, da das Projekt neu ausgerichtet werden kann (vorherige Entwickler haben das Projekt möglicherweise ohnehin auf einen unerwünschten Weg geführt).
In einer solchen Situation müssen Sie Ihren Rücken bedecken. Lassen Sie sich immer schriftlich sagen, was die Probleme sind und insbesondere die Reaktion der Manager, sie zu ignorieren und Funktionen hinzuzufügen. Es ist so einfach wie das Versenden einer E-Mail.
„Hallo Chef, nach unserem Gespräch können Sie bitte klarstellen, was ich priorisieren soll. Es gibt eine Menge Bugs in X, oder sollte ich einfach mit den neuen Sachen weitermachen. Außerdem musste ich etwas digitales Kung Fu machen, um einen Fehler in W zu umgehen, ist das in Ordnung?'
Wenn Sie den Rücken frei haben, ist das egal, der Manager ist drin, nicht Sie, Sie machen nur Ihren Job.
Diese Art von Situation ist nicht so ungewöhnlich, wie Sie vielleicht denken. Es kann sich sicher wie ein drohender Untergang anfühlen.
Es ist sehr wahrscheinlich, dass sie versuchen, etwas von ihrer Investition in etwas für die geringstmögliche zusätzliche Investition zu retten. Aus diesem Grund haben sie ihm nur einen Junior-Entwickler zugewiesen.
Bis die Software ein Problem für jemanden so löst, dass er bereit ist, dafür zu bezahlen, ist die Software wertlos. Wenn Funktionen benötigt werden, um dieses Stadium zu erreichen, ist dies der beste Ort, um in die Software zu investieren. Zeit damit zu verbringen, etwas zu reparieren, wofür niemand bezahlt, ist keine gute Ressourcenallokation.
Stellen Sie sich vor, Sie hätten nicht getan, was Sie gebeten wurden, und Zeit damit verbracht, Fehler zu beheben, dann wäre bei der Demo ein wichtiges Feature für den Kunden nicht vorhanden. Dies könnte zu einem entgangenen Verkauf führen und wäre ausschließlich Ihre Schuld. Du kennst die Gründe für all diese Entscheidungen nicht, also bleib bei ihnen.
Ich weiß, idealerweise sollten die Dinge von Anfang an gut geschrieben sein, aber Sie haben das Projekt nicht gestartet und können daher nicht für das gesamte System verantwortlich gemacht werden.
Es ist unwahrscheinlich (wenn auch nicht unmöglich), dass Sie zum Scheitern verurteilt sind. Es ist wahrscheinlicher, dass das Unternehmen versucht, etwas aus dem zu machen, was derzeit ein toter Verlust ist.
Tun Sie also, was Sie können, damit die Demo gut läuft. Sie haben sich von Anfang an über den Stand des Codes im Klaren gewesen und Prioritäten vom Management übernommen. Wenn die Demo nicht gut läuft, liegt das nicht daran, dass Sie Ihre Arbeit nicht gut gemacht haben.
Wenn Ihr Unternehmen eine vernünftige Kultur hat, sollte dies in Ordnung sein.
Wenn das Unternehmen eine Schuldzuweisungskultur hat und Sie für die Demo oder den Stand des Codes verantwortlich gemacht werden, können Sie trotz all Ihrer Ratschläge an das Management beim nächsten Mal defensiver sein. Holen Sie sich alles schriftlich, seien Sie sturer bei der Behebung von Fehlern. Wenn Sie darauf angesprochen werden, weisen Sie darauf hin, dass Sie sich in der Vergangenheit die Hitze genommen haben, weil Sie dies nicht getan haben. In einer solchen Kultur zu arbeiten ist nicht schön und Sie müssen auf Ihren Rücken aufpassen (wenn es eine Option ist, einen anderen Job zu bekommen, dann suchen Sie sich einen)
Aber ich würde vorschlagen, Ihrem Unternehmen eine Chance zu geben. Tun Sie, was Sie aufgefordert wurden, so gut Sie können, und akzeptieren Sie, dass das Unternehmen ein gemeinsames Unterfangen ist.
Diese Art von Codebasis existiert überraschend oft, und viele von uns haben an ähnlichen gearbeitet. (Es wurde angemerkt, dass eine Codebasis ein Spiegelbild der Organisationsstruktur ist, die sie hervorbringt – oder tatsächlich eine bewegende Chronik der Organisation). Hier ist ein pragmatischer Ansatz, den ich gelernt habe:
Zugewiesen an ein unkommentiertes, undokumentiertes Durcheinander eines Projekts ohne Training oder Mentoren. Ich bin die einzige Person, die an diesem Projekt arbeitet, niemand sonst kennt oder hat den Code jemals gesehen.
Schritt 1: Für alles, was Sie berühren, schreiben Sie zunächst Unit-Tests, sowohl um zu überprüfen, ob es bereits tut, was es sollte (oder zu zeigen, dass es nicht funktioniert), als auch um zu zeigen, dass Sie es nicht noch schlimmer gemacht haben. Sie berücksichtigen dies in jeder Schätzung. Dies bildet auch eine Dokumentation für den Code, da die Leute ihn aus den Tests verstehen können.
Jetzt sind Monate vergangen und es ist bald Zeit, Programm zu zeigen
Schritt 2: Stellen Sie sicher, dass Sie regelmäßig Demos/Vorschauen mit dem Kunden haben, sowohl um die Erwartungen festzulegen als auch um sicherzustellen, dass Sie das Richtige/Prioritäten tun.
Denn Refactoring ist und war aus Zeitgründen und Wünschen des Managers nie eine Option
Schritt 3: Wenn Sie eine solche Diskussion führen, dokumentieren Sie sie zur Bestätigung in einer E-Mail. Auf diese Weise stellen Sie sicher, dass der schmutzige Stock in die richtige Richtung zeigt, wenn sie anfangen, die Schuld zu verteilen.
da ich einige seltsame Dinge tun musste, um die Fehler zu umgehen
Verbergen Sie niemals Fehler, melden Sie sie, fügen Sie sie einem Fehlertracker hinzu und erhalten Sie einen Urteilsaufruf zur Behebung (siehe oben).
Wie kann ich es vermeiden, für ein von mir geerbtes Projekt bestraft zu werden, das bereits fehlerhaft war, während mir gesagt wurde, ich solle an mehr Funktionen arbeiten, anstatt Fehler zu beheben?
Führen Sie Ihre Due-Diligence-Prüfung durch, wenn Sie das Projekt aufnehmen, nicht wenn jeder herausfinden wird, dass es den Bach runtergegangen ist.
Jeder Entwickler denkt, dass jedes Projekt, das er erbt, ein fehlerhaftes Durcheinander ist, das ist eine natürliche Reaktion, und ich verstehe den Instinkt, alles so umgestalten zu wollen, wie Sie es sich vorstellen.
Wenn der bereits vorhandene Code jedoch funktioniert und seinen Zweck erfüllt und das Unternehmen neue Funktionen hinzufügen muss, sollten Sie sich darauf konzentrieren, die neuen Funktionen hinzuzufügen.
Das bedeutet nicht, dass Sie während des Vorgangs nicht umgestalten können.
Wenn Sie die neuen Funktionen hinzufügen, werden Sie wahrscheinlich mit dem bereits vorhandenen Code arbeiten, und wenn Sie dies tun, ihn aufräumen und Tests hinzufügen und sicherstellen, dass der neue Code auch von Tests abgedeckt wird.
Brownfield-Entwicklung (dh das Arbeiten mit und Verbessern bestehender beschissener Codebasen) ist eine Fähigkeit für sich, und Sie können nicht einfach jede Codebasis in dieser Kategorie, die Ihnen begegnet, neu schreiben.
Sie sind als Entwickler viel wertvoller, wenn Sie sich nicht nur einen neuen Job suchen , sondern sich tatsächlich die Mühe machen, mit der vorhandenen Codebasis zu arbeiten und sie zu verbessern.
Auf die Gefahr hin, leichtfertig zu sein, die Welt ist hungrig nach Programmierern. Einige Organisationen sind kaputt, wenn das vielleicht der Fall ist, dann suchen Sie sich einen neuen Job .
Andere Poster haben ganz zu Recht darauf hingewiesen, dass das vererbte Durcheinander bei großen, lang laufenden Projekten üblich, ja sogar unvermeidlich ist. Es ist Sache des Unternehmens, den Aufwand zur Behebung oder Verbesserung zu finanzieren, nicht Sie (es sei denn, Sie haben eine Kapitalbeteiligung). Wenn es Zeit für eine Neufassung ist, dann liegt es an ihnen zu entscheiden (Sie können nur vorschlagen).
Passen Sie in dieser Situation auf sich auf.
Ich programmiere seit über 30 Jahren und nach einer Weile merkt man wirklich, wie wichtig die umgebende Infrastruktur für einen guten Job ist. Und Sie haben das Recht, zu versuchen, es gut zu machen.
Wenn es nicht gut ist, gehen Sie weiter, beginnen Sie nach Möglichkeit mit der Suche, während Sie im aktuellen Job sind. Seien Sie nur vorsichtig, wie Sie das gegenüber potenziellen neuen Arbeitgebern formulieren. Wenn Sie sich darüber beschweren, wie schlimm es in Ihrem letzten Job war, gewinnen Sie nur sehr wenige Pluspunkte.
Ich fürchte, Sie sind zu spät, um wirklich viel gegen das bevorstehende Problem zu unternehmen. Sie können Ihrem Vorgänger jetzt keinen Vorwurf machen, da er schon lange weg ist - Sie hätten es (mit einer E-Mail-Spur) im ersten Monat oder so tun können, aber nicht jetzt.
Wenn dies in Zukunft passiert, tun Sie Folgendes:
Ihre Situation wird sich dann mit jedem neuen Feature verbessern.
Sie befinden sich in einer Situation, in der Sie 0 Berufserfahrung haben und gebeten wurden, an einem fehlerhaften Durcheinander einer Codebasis zu arbeiten, und Ihnen wurde gesagt, dass Sie die Fehler nicht beheben oder umgestalten können.
Allerdings- 1. Sie haben keine Ahnung, ob die Codebasis gut/schlecht/typisch ist. Sie haben keinen Stand der Technik, mit dem Sie es vergleichen könnten. 2. Niemand überprüft Ihre Arbeit, was bedeutet, dass es für Sie unmöglich wäre zu wissen, ob Sie die Codebasis verbessern, selbst wenn Sie Refactoring durchführen würden ... noch einmal, Sie haben keine Erfahrung. 3. Niemand sonst sieht sich die Codebasis an, also könnten Sie tatsächlich so viel Fehler beheben und umgestalten, wie Sie wollten, da Ihr Manager den Unterschied nicht erkennen konnte.
Ich verstehe, dass jeder unterschiedliche Situationen hat, aber ein Umfeld mit ein paar Leuten zu finden, die wissen, was sie tun, und ein gesunder Code-Review-Prozess werden für Ihre Karriere mehr wert sein als das, was Sie in 10 Jahren in diesem Unternehmen verdienen werden. Also- ich würde mir keine Gedanken über die bevorstehende Demo machen (die ohne Ihr Verschulden schlecht laufen wird, sondern Ihr Manager ist hier völlig schuld) ... ich würde mich stattdessen darauf konzentrieren, sich selbst in eine bessere Situation zu bringen, ob das bedeutet einen anderen Job zu finden oder einen Weg zu finden, Unterstützung von erfahreneren Entwicklern bei Ihrem aktuellen zu erhalten.
(Jemand mit solider Erfahrung könnte sich an diese Situationen anpassen, wie die anderen Antworten beschreiben. Gleich nach dem College muss Ihre erste Priorität jedoch darin bestehen, zu lernen, Ihren Job zu machen, was Sie derzeit nicht tun.)
Es wurde viel gesagt, dem ich zustimme, aber ich denke, es gibt noch eine Sache, die erwähnt werden sollte: Dies ist eine enorme Chance für Sie.
Denk darüber nach. Sie, ein Junior-Programmierer, frisch aus dem College und ohne jegliche Erfahrung, sind die einzige Person, die damit beauftragt ist, an einer Softwareanwendung zu arbeiten. Das sagt mir, dass die Software auf der Prioritätsskala des Managements sehr niedrig ist. Sie haben es effektiv abgeschrieben; Ihrer Meinung nach ist die Software bereits gescheitert (und aus dem, was Sie gesagt haben, ist es nicht schwer zu erkennen, warum sie zu diesem Schluss gekommen sind).
Das bedeutet, dass Sie nicht scheitern können; du kannst nur Erfolg haben.
Mein Rat ist, Ihrem Management zu vertrauen, die Funktionen hinzuzufügen und sie so zu demonstrieren, wie es Pete in seiner Antwort dargelegt hat. Wenn Ihr Management klug ist, versucht es, dem Kunden die Fähigkeiten zu verkaufen, die die Anwendung bietet, was nicht dasselbe ist, wie die Anwendung selbst zu verkaufen. Ich vermute, dass, wenn der Kunde beißt, er einen Preis aushandelt, der das Korrigieren (oder sogar das Neuschreiben) der fehlerhaften Teile des Codes beinhaltet. In diesem Fall stehen Sie bei diesem Teil der Bemühungen im Mittelpunkt. Wenn dies nicht der Fall ist, hat Ihr Management nichts verloren, außer ein paar Monaten Arbeit eines extrem jungen (dh billigen) Programmierers.
Es gibt ein paar Implikationen für diese Denkweise. Der wichtigste ist, dass Sie zusätzlich zu dem, was Sie bereits tun, darüber nachdenken sollten, wie viel Zeit und Mühe es kosten würde, den Code zu reparieren. Denken Sie über einen Plan und einen Zeitplan nach, damit Sie Ihrem Management einige Optionen anbieten können. Wenn sie keinen Käufer haben, werden sie nicht interessiert sein. Wenn es jedoch potenzielle Käufer gibt, sind diese Informationen für sie von entscheidender Bedeutung, wenn sie mit den Preisverhandlungen beginnen.
Hoffentlich haben Sie es ihm nicht nur gesagt, sondern ihn schriftlich über das Durcheinander informiert. Auf diese Weise kennt er die Situation von Anfang an und kann Sie nicht dafür verantwortlich machen.
Ich habe die Erfahrung gemacht, dass in solchen Situationen der Manager oft genauso glücklich ist wie der Entwickler, demjenigen die Schuld zu geben, der das Unternehmen verlassen hat!
Es wäre wahrscheinlich hilfreich für Sie, jeden Fehler, den Sie entdecken, zu verfolgen und ihn an einem Ort aufzubewahren, an dem Ihr Manager leicht sehen kann (nicht auf passiv-aggressive Weise, wohlgemerkt - sagen Sie ihm einfach, was Sie tun). Auch wenn es sich irgendwo in einer gemeinsam genutzten Tabelle „Bekannte Probleme“ befindet, wenn Ihr Unternehmen keine Software zur Fehlerverfolgung hat. Ermutigen Sie die Benutzer möglicherweise, dasselbe zu tun (im selben Dokument), wenn Politik und Logistik dies zulassen. Möglicherweise können Sie sogar Ihren Manager dazu bringen, den Schweregrad zu bewerten und jedem eine Priorität zuzuweisen (in Bezug auf die neuen Funktionen, die Sie hinzufügen sollen).
Ich vermute, Sie haben keine voll funktionsfähige QA-Abteilung, sonst wäre sie nicht so weit gekommen, aber wenn Sie eine haben, wäre ihr Beitrag hier wirklich von Vorteil.
Dies zeigt nicht nur, dass Sie proaktiv versuchen, das Chaos zu beseitigen, sondern sich auch abzusichern, wenn ein Problem auftritt, bei dem er Sie möglicherweise beschuldigen könnte.
Lassen Sie sich von Ihrem Chef unterstützen. Stellen Sie sicher, dass Ihr Chef davon überzeugt ist, dass es ernsthafte Probleme gibt, damit er Zeit und Zustimmung von der Geschäftsleitung bekommen kann. Holen Sie sich dann den besten Architekten im Unternehmen, der Ihnen hilft, das Projekt neu zu entwerfen, umzugestalten oder neu zu schreiben. Arbeiten Sie mit Ihrem Manager und dem Architekten zusammen, um ein nachweislich besseres Programm zu erstellen. Das ist mir in den letzten 6 Monaten passiert.
Mücke
Monika Cellio
Erdbeere
Mitarbeiter-X
Mitarbeiter-X