Penso che la ragione principale che vedrai giustificare questo genere di cose nel senso più ampio è il "fattore di bus" . Se la stessa persona scrive e mantiene un pezzo di codice perpetuo, nessuno oltre a quella persona avrà la minima idea di come funzioni, il che è un problema quando quella persona se ne va. Quindi avere nuovi sviluppatori che risolvono i bug per iniziare è spesso giustificato da tale logica.

Personalmente ritengo improbabile che la giustificazione corrisponda al ragionamento. Penso che la vera ragione per cui questo accade con i nuovi sviluppatori è che i dipartimenti onestamente non sanno veramente cosa fare con loro, non hanno un programma di formazione completo e sono nervosi per affidarli a funzioni importanti. Quindi qualunque cosa ti venga detto, probabilmente è una sorta di modo predefinito per dimostrarti che sei capace di maneggiare roba e, si spera, impari una o due cose lungo la strada.

Personalmente ritengo che ci siano modi migliori per raggiungere questo obiettivo, ma è un modo, e suppongo che a volte funzioni, dopo una moda (nonostante il rischio di annoiare i neofiti a lasciare i pascoli più verdi).

Altri commentatori hanno già coperto alcuni punti importanti - sto parlando della posizione di qualcuno che ha lavorato per un po 'in un team di sviluppo incaricato specificamente del mantenimento del codice spedito. Praticamente tutte le tue domande si sono ripetute più volte.

Ci sono molte cose che potrebbero andare avanti. Ne hai indicato uno - lo sviluppatore originale potrebbe aver lasciato la compagnia. Un'altra possibilità è che, mentre lo sviluppatore originale è ancora in azienda, da molto tempo si è trasferito ad altre cose, e non ha più quella roba nella memoria di lavoro (specialmente se il codice è cambiato parecchio da quando stavano lavorando su di esso).

Ciò che abbiamo dovuto affrontare, ad esempio, è che il team del prodotto aveva programmi molto aggressivi per fornire le prossime versioni del prodotto. Se anche dovessero lavorare su bug nelle versioni esistenti, almeno così è andato il ragionamento, non sarebbero stati in grado di soddisfare i loro programmi. Immagino che questo punto possa essere argomentato, ma la realtà del mondo del software aziendale è che portare le cose fuori dalla porta supera qualsiasi altra cosa, inclusa l'osservazione di tutte le migliori pratiche di ingegneria del software in ogni momento. "Tradeoffs" è il termine vago in base al quale cadono tutti gli spiacevoli compromessi che noi sviluppatori, prima o poi, dobbiamo fare in quegli ambienti.

D'altro canto, tuttavia, la risoluzione di bug non banali richiede di imparare molto sul codice base. È doloroso, a volte demoralizzante e spesso travolgente. Ma come pensi esattamente che diventerai un esperto in materia su un progetto software? Puoi passare giorni a leggere il codice per la tua edificazione, ma quel tipo di codice in esame non si attacca bene e ha dovuto "combattere" con il codice per risolvere un problema. Le ricerche continuano a battere il motto che impariamo facendo. Purtroppo, a meno che tu non sia in una startup o in una nuova squadra, questo significa che di solito ti stai unendo a un progetto software che è stato utilizzato per diverse versioni e che ha clienti reali con lamentele reali che devono essere affrontate. Ciò implica che dovrai correggere i bug prima di dare funzionalità per aggiungere / ridisegnare.

Ciò che è veramente importante è comunicare regolarmente con il tuo manager ed esprimere ciò che vuoi ottenere dal lavoro, e vedere se l'azienda può effettivamente accogliere i tuoi obiettivi al momento. Spero che la risposta sia sì. Rimanere in giro per un po 'e raccogliere tutta l'esperienza che puoi dal tuo team attuale. Se la risposta risulta essere no, e sei un buon sviluppatore, avrai molte opzioni. Ma non sottovalutare l'esperienza acquisita correggendo i bug: ora sono nel mio terzo lavoro software e devo scrivere tonnellate di codice. Fortunatamente, gran parte funziona sin dall'inizio perché ho passato tanto tempo a identificare, correggere e cercare di prevenire i bug.

Dobbiamo ammettere che gli sviluppatori di software dedicano molto più tempo a leggere / comprendere il codice che a crearlo. E dalla mia esperienza personale, migliore è la compagnia che lavori per il codice più che leggi. Quindi il fatto che tu abbia a che fare con il codice degli altri così tanto non dovrebbe sorprenderti o confonderti.

E questo sembra abbastanza naturale. Per imparare qualcosa devi vedere come è stato fatto. Non ci sono molte aziende in cui viene praticata la programmazione di coppia e vengono insegnati i novizi in questo modo. La maggior parte delle volte impari nuove tecniche, schemi, stile di codifica aziendale, ecc. Leggendo il codice degli altri.

E il modo più efficace per capire il codice in realtà sta funzionando con esso: debugging, refactoring, fixing bugs. Questa è una pratica comune se si deve prendere la proprietà del codice.

I possibili motivi per cui lo sviluppatore originale non aggiusta i suoi errori potrebbe essere quello

• il bug ha poca priorità e l'attività corrente dello sviluppatore è più importante o urgente.
• lo sviluppatore non ha lavorato con quel codice per molto tempo e in ogni caso ci vorrà del tempo per richiamare il vecchio codice.
• lo sviluppatore è molto occupato con qualcosa di complicato e non deve essere interrotto.

P.S. Penso che tu sia fortunato che lo sviluppatore originale sia lì per rispondere alle tue domande.

Ci sono ragioni pedagogiche e ragioni di fattori di rischio, ma soprattutto è solo matematica. La maggior parte del lavoro di programmazione è la manutenzione e quelli che sono stati in un'azienda da più tempo hanno generato il maggior numero di codice che deve essere mantenuto.

Considera un'azienda di software one man. Dopo 10 anni assume qualcuno che lo aiuti. Se il 90% del lavoro disponibile è un lavoro di manutenzione, su che cosa lavorerà il nuovo ragazzo se non può toccare il codice del vecchio? In una squadra più ampia l'effetto è più difficile da quantificare, ma ciò non significa che non sia lì.

Quindi cerca di non rimanere impigliato da chi è responsabile di quale codice. Le persone si attaccano al "loro" codice e non si arrendono leggermente. Tra qualche anno ci sarà il codice che desideri per preservare la tua responsabilità, ma semplicemente non avresti tempo.

Erik è perfetto.

Anche la direzione vuole proteggere le proprie scommesse facendo conoscere a tutti gli sviluppatori alcuni aspetti del codice. Solo perché una persona ha scritto del codice non le rende automaticamente responsabili mentre lavora lì. Al contrario, più sviluppatori lo mantengono, maggiore è la possibilità che vengano scoperti bug e vengano realizzati improvvisazioni. A tutti piace lasciare il segno;) se capisci cosa intendo. Un altro punto di vista è che il codice è di proprietà dell'azienda e non dello sviluppatore. Rende la vita di un project manager leggermente più semplice se ha più sviluppatori tra cui scegliere per un determinato compito. Probabilmente ti stanno solo facilitando l'accesso alle loro librerie di codici e allo stesso tempo testando le tue capacità. Sarebbero folli lasciando un nuovo dipendente vicino a tutto ciò che poteva costare ai soldi dell'azienda, sicuramente per i primi 6 mesi circa.

buone risposte, tutto; ecco un altro angolo -

potrebbe essere semplice economia

potrebbe essere necessario 5 volte più a lungo per trovare e risolvere un problema rispetto a quello che avrebbe fatto lo sviluppatore originale, ma il lavoro che lo sviluppatore originale sta facendo nel frattempo offre molte più entrate alla società