Qual è la norma per l'introduzione di nuovi assunti in un codice base? [duplicare]

Per la maggior parte, la tua esperienza è quella che conosco come "la norma".

Molto spesso una delle tue prime attività sarà "Vai a trovare e correggere questo bug" e non riuscirai a trovare la strada attraverso l'albero dei sorgenti (idealmente partendo dallo strumento di ricerca del codice sorgente) per cercare la base di codici per l'errore particolare testo o qualcosa di simile.

Se hai un vantaggio gentile o competente, otterrai un altro bug o funzionalità o un elemento di lavoro in qualche modo correlato all'ultimo. Il prossimo sarà anche in qualche modo collegato agli altri due, e così via col passare del tempo. Un giorno qualcuno ti rivelerà che non hanno la più pallida idea di cosa sia l'area di codice in cui hai lavorato e ti renderai conto che sei l'esperto per la particolare funzionalità imposta che hai corretto i bug negli ultimi n mesi.

Alla fine, ti verrà assegnato qualcosa di completamente diverso, e ricomincia tutto da capo.

Il codice base per il prodotto su cui lavoro è nel regno di milioni di righe di codice ... Non so cosa faccia di più - ma in genere non devo farlo.

Non è raro. Al mio attuale lavoro, mi è stato chiesto di guardare l'attuale codebase (~ 200 dlls, ~ 500 kloc) e alla fine della settimana 3, presente al capo, architetti e team guidano le prime 10 cose sbagliate.

La cosa fondamentale da ricordare è che sei nuovo. Le nuove persone hanno domande. Fai domande. che ti aiuterà a capire dove (in generale) le cose vivono. Una volta che sai in generale dove vivono le cose e (generalmente) come funzionano le cose, allora puoi scavare per imparare abbastanza da fare quello che ti serve. Quella investigazione è l'abilità chiave che determinerà la tua competenza.

Poche persone possono imparare in profondità basi di codici di grandi dimensioni, ma dovresti imparare le parti grandi e chi chiedere quando ti imbatti inevitabilmente in roadblock. E con l'esperienza, chiederai sempre meno perché il nuovo codice avrà un aspetto stranamente come le codebase con cui hai lavorato in passato.

Altre persone hanno già scritto alcune buone risposte, quindi le menzionerò solo in sintesi:

1. NON FARE PANICO! Questo succede a tutti. :)
2. Fai domande! Non ci si aspetta che tu capisca l'intero codice base. In genere non è umanamente possibile comunque.

Aggiungerò a quelli che codice di lettura è un'abilità critica che stai sviluppando in questo momento. Raramente viene affrontato in modo significativo in un ambiente di classe per motivi pratici, quindi siamo passati attraverso quello che sei. È frustrante per il front end, dato che l'apprendimento di solito lo è, ma imparerai a farlo con la pratica e l'esperienza.

Buona fortuna e non dimenticare di divertirti! :)

"Ho fatto questa domanda ai miei colleghi e hanno detto" un paio di settimane ". UNA SETTIMANA DI COPPIE PER IMPARARE A MILLE PIÙ FILES, CENERE O MIGLIAIA DI LINEE LUNGHE CIASCUNO ???"

Sei in preda al panico e il tuo panico ti sta rendendo irrazionale. Rallenta e fai alcuni respiri profondi.

Nessuno "impara" una larga base di codice nel giro di poche settimane. In un progetto molto grande nessuno "impara" mai l'intero codice base. Impari parti, ti specializzi, dimentichi e imparerai di nuovo. Usi documentazione, specifiche, commenti e strumenti software per orientarti. Conosci i tuoi strumenti: IDE, editor, debugger, build system, VCS e strumenti da riga di comando come grep.

Essere dati un bug da correggere è un tipico esercizio di apprendimento per una nuova assunzione. Se hanno un senso non sarà un bug complesso che tocca molto codice. Tratta tutto ciò che non è direttamente correlato a quell'insetto come una scatola nera finché non sei assolutamente costretto a scavare più a fondo in esso. Impara quel tanto che basta per risolvere quel problema, e poi vai a prendere un altro problema. Fatelo centinaia di volte e inizierete a capire come è organizzato il progetto.

Il modo migliore per affrontare questo codice è non affrontarlo. Cioè, dimentica di comprenderlo intero. Scegli invece un obiettivo ben definito di dimensioni ridotte e implementalo.

Potrebbe essere una piccola nuova funzionalità, una correzione di bug o un aumento della copertura di test di una classe o di un componente che ha già alcuni test ma che potrebbe richiedere una copertura maggiore.

Fondamentalmente, devi solo saltare e fare qualcosa di ben definito e utile.

L'incapsulamento è una cosa meravigliosa.

Significa che non guarderai l'intero grafico dell'oggetto quando apporti una modifica. Stai solo andando a guardare una manciata di classi, e quelle classi saranno avvolte in test unitari con un livello molto alto di copertura del codice, in modo che il refactoring di una classe non infrangerà le sue funzionalità di base. Hai requisiti chiari e verificabili, giusto?

Ora, mi scusi mentre torno a casa verso i miei campi ondeggianti, il cioccolato che scorre liberamente e ballando gli unicorni.