Ich bin gerade von der Universität gekommen und arbeite seit ungefähr 8 Monaten in dieser Firma. Während mir der Titel eines Entwicklers verliehen wurde, habe ich die meiste Zeit damit verbracht, die Codes anderer Leute zu reparieren und zu debuggen.

Ich frage mich immer, warum der ursprüngliche Entwickler nicht dafür verantwortlich ist, seinen Code zu reparieren. Ich verstehe, dass wenn der ursprüngliche Entwickler nicht mehr anwesend ist, die anderen Entwickler die Arbeit übernehmen müssen, aber was ist, wenn der Entwickler immer noch als Mitarbeiter im Unternehmen arbeitet?

Man kann argumentieren, dass es für die neuen Entwickler von Vorteil ist, da sie es als Gelegenheit zum Lernen sehen, und ich stimme dem zu, aber was ist, wenn die Komplexität des Problems / der Ausgabe des Codes sehr hoch ist? In meinem Fall sind die meisten Codes, die ich reparieren soll, keine trivialen Probleme, und es führt immer dazu, dass ich den ursprünglichen Entwicklern Fragen zum Code stelle. Warum können die Entwickler, die es erstellt haben, das vorhandene Problem nicht beheben, wenn sie es so viel besser verstehen, seit sie es codiert haben? Und das Problem, auf das ich mich beziehe, ist kein triviales Problem, bei dem Sie es in ein oder zwei Tagen beheben können, sondern ein Problem, das ein tiefes Verständnis des Codes erfordert, um eine Lösung zu finden.

Was ist der Grund dafür und ist es in der Softwareindustrie üblich?

Ich denke, der Hauptgrund, warum Sie so etwas im weitesten Sinne rechtfertigen sehen, ist der "Busfaktor" . Wenn dieselbe Person einen Code auf Dauer schreibt und verwaltet, hat niemand außer dieser Person eine Ahnung, wie er funktioniert, was problematisch ist, wenn diese Person geht. Daher ist es oft gerechtfertigt, wenn neue Entwickler Fehler beheben, um loszulegen.

Persönlich denke ich, dass die Rechtfertigung wahrscheinlich nicht mit der Begründung übereinstimmt. Ich denke, der eigentliche Grund, warum dies bei neueren Entwicklern der Fall ist, ist, dass die Abteilungen ehrlich gesagt nicht wirklich wissen, was sie mit ihnen anfangen sollen, kein umfassendes Schulungsprogramm haben und nervös sind, sie mit wichtigen Funktionen zu beauftragen. Was auch immer Ihnen gesagt wird, es ist wahrscheinlich eine Art Standardmethode, um zu beweisen, dass Sie in der Lage sind, mit Dingen umzugehen, und hoffentlich ein oder zwei Dinge auf dem Weg zu lernen.

Ich persönlich denke, es gibt viel bessere Möglichkeiten, dies zu erreichen, aber es ist ein Weg, und ich nehme an, dass er manchmal auf eine Art und Weise funktioniert (ungeachtet des Risikos, Neulinge dazu zu bringen, auf grünere Weiden zu gehen).

Andere Kommentatoren haben bereits einige wichtige Punkte behandelt - ich spreche von der Position eines Mitarbeiters, der eine Weile in einem Entwicklungsteam gearbeitet hat, das speziell mit der Wartung des ausgelieferten Codes beauftragt ist. So ziemlich alle Ihre Fragen tauchten immer wieder auf.

Es gibt viele Dinge, die passieren könnten. Sie haben darauf hingewiesen - der ursprüngliche Entwickler hat möglicherweise das Unternehmen verlassen. Eine andere Möglichkeit besteht darin, dass der ursprüngliche Entwickler, während er noch im Unternehmen ist, längst zu anderen Dingen übergegangen ist und diese Dinge nicht mehr im Arbeitsspeicher hat (insbesondere, wenn sich der Code seit seiner Arbeit erheblich geändert hat darauf).

Wir mussten uns zum Beispiel damit befassen, dass das Produktteam sehr aggressive Zeitpläne für die Lieferung der nächsten Versionen des Produkts hatte. Wenn sie auch an Fehlern in den vorhandenen Versionen arbeiten müssten, wären sie zumindest nicht in der Lage gewesen, ihre Zeitpläne einzuhalten. Ich denke, dieser Punkt könnte argumentiert werden, aber die Realität in der Welt der Unternehmenssoftware ist, dass das Herausholen von Dingen alles andere übertrumpft, einschließlich der jederzeitigen Einhaltung aller Best Practices des Software-Engineerings. "Kompromisse" ist der vage Begriff, unter den all die unangenehmen Kompromisse fallen, die wir Entwickler früher oder später in diesen Umgebungen eingehen müssen.

Auf der anderen Seite müssen Sie jedoch viel über die Codebasis lernen, um nicht triviale Fehler zu beheben. Es ist schmerzhaft, manchmal demoralisierend und oft überwältigend. Aber wie genau denken Sie, werden Sie Fachexperte für ein Softwareprojekt? Sie können Tage damit verbringen, den Code für Ihre Erbauung zu lesen, aber diese Art der Code-Durchsicht bleibt nicht so gut, als dass Sie mit dem Code "kämpfen" mussten, um ein Problem zu beheben. Forschungen übertreffen immer wieder das Motto, das wir dabei lernen. Wenn Sie nicht in einem Startup oder einem neuen Team sind, bedeutet dies leider, dass Sie normalerweise einem Softwareprojekt beitreten, das es schon seit mehreren Releases gibt, und echte Kunden mit echten Beschwerden haben, die angegangen werden müssen. Dies bedeutet, dass Sie zuerst Fehler beheben, bevor Sie

Was wirklich wichtig ist, ist, regelmäßig mit Ihrem Manager zu kommunizieren und auszudrücken, was Sie aus dem Job herausholen möchten, und zu prüfen, ob das Unternehmen im Moment tatsächlich Ihren Zielen gerecht werden kann. Hoffentlich lautet die Antwort ja. Bleiben Sie eine Weile und sammeln Sie alle Erfahrungen, die Sie von Ihrem aktuellen Team machen können. Wenn sich herausstellt, dass die Antwort Nein lautet und Sie ein guter Entwickler sind, haben Sie viele Möglichkeiten. Aber lassen Sie die Erfahrung, die Sie durch das Beheben von Fehlern sammeln, nicht außer Acht - ich bin jetzt in meinem dritten Software-Job und muss Tonnen von Code schreiben. Glücklicherweise funktioniert vieles von Anfang an, weil ich so viel Zeit damit verbracht habe, Fehler zu identifizieren, zu beheben und zu versuchen, sie zu verhindern.

Wir müssen zugeben, dass Softwareentwickler viel mehr Zeit damit verbringen, Code zu lesen / zu verstehen, als ihn zu erstellen. Und meiner persönlichen Erfahrung nach ist die Gesellschaft, für die Sie arbeiten, umso besser, je mehr Code Sie lesen. Die Tatsache, dass Sie sich so sehr mit dem Code anderer auseinandersetzen müssen, sollte Sie also überhaupt nicht überraschen oder verwirren.

Und das scheint ganz natürlich. Um etwas zu lernen, muss man sehen, wie es gemacht wird. Es gibt nicht viele Unternehmen, in denen Paarprogrammierung praktiziert wird und Anfänger auf diese Weise unterrichtet werden. Meistens lernen Sie neue Techniken, Muster, den Codierungsstil des Unternehmens usw., indem Sie den Code anderer lesen.

Und die effizienteste Art, Code zu verstehen, besteht darin, damit zu arbeiten: Debuggen, Refactoring, Beheben von Fehlern. Dies ist eine gängige Praxis, wenn Sie das Eigentum an dem Code übernehmen möchten.

Die möglichen Gründe, warum der ursprüngliche Entwickler seine Fehler nicht behebt, könnten folgende sein

• Der Fehler hat wenig Priorität und die aktuelle Aufgabe des Entwicklers ist wichtiger oder dringender.
• Der Entwickler hat lange nicht mehr mit diesem Code gearbeitet und es würde sowieso einige Zeit dauern, bis sie ihren alten Code zurückgerufen haben.
• Der Entwickler ist sehr beschäftigt mit etwas Kompliziertem und muss nicht unterbrochen werden.

PS Ich denke, Sie haben Glück, dass der ursprüngliche Entwickler da ist, um Ihre Fragen zu beantworten.

Es gibt pädagogische Gründe und Risikofaktorgründe, aber meistens ist es nur Mathematik. Die meisten Programmierarbeiten sind Wartungsarbeiten, und diejenigen, die am längsten in einem Unternehmen waren, haben den meisten Code generiert, der gewartet werden muss.

Stellen Sie sich ein Ein-Mann-Softwareunternehmen vor. Nach 10 Jahren stellt er jemanden ein, der ihm hilft. Wenn 90% der verfügbaren Arbeiten Wartungsarbeiten sind, woran wird der neue Mann arbeiten, wenn er den Code des alten Mannes nicht berühren kann? In einem größeren Team ist der Effekt schwerer zu quantifizieren, aber das bedeutet nicht, dass er nicht vorhanden ist.

Versuchen Sie also, sich nicht darauf einzulassen, wer für welchen Code verantwortlich ist. Die Leute hängen an "ihrem" Code und geben ihn nicht leichtfertig auf. In ein paar Jahren wird es Code geben, für den Sie Ihre Verantwortung behalten möchten , aber Sie werden einfach keine Zeit haben.

Erik ist genau richtig.

Auch das Management möchte seine Wetten absichern, indem es alle Entwickler mit bestimmten Aspekten des Codes vertraut macht. Nur weil eine Person Code geschrieben hat, sind sie nicht automatisch dafür verantwortlich, während sie dort arbeiten. Im Gegenteil, je mehr Entwickler es warten, desto größer ist die Wahrscheinlichkeit, dass Fehler entdeckt und Improvisationen durchgeführt werden. Jeder hinterlässt gerne seine Spuren;) wenn du weißt was ich meine. Eine andere Ansicht ist, dass der Code dem Unternehmen und nicht dem Entwickler gehört. Dies erleichtert einem Projektmanager das Leben etwas, wenn er mehr Entwickler für eine bestimmte Aufgabe zur Auswahl hat. Sie erleichtern Ihnen wahrscheinlich nur den Zugriff auf ihre Codebibliotheken und testen gleichzeitig Ihre Fähigkeiten. Sie wären verrückt, wenn sie einen neuen Mitarbeiter in die Nähe von allem lassen würden, was das Unternehmen Geld kosten könnte, sicherlich in den ersten sechs Monaten oder so.

gute Antworten, alle; Hier ist ein anderer Winkel -

es kann einfache Wirtschaft sein

Es kann fünfmal länger dauern, bis Sie ein Problem gefunden und behoben haben als der ursprüngliche Entwickler, aber die Arbeit, die der ursprüngliche Entwickler in der Zwischenzeit leistet, bringt dem Unternehmen weitaus mehr Umsatz