Due mesi nel mio nuovo lavoro, avendo ancora problemi nell'apprendimento di una nuova base di codici. Come posso migliorare? [duplicare]

3

Sono un programmatore autodidatta. Fino ad ora non ho avuto troppi problemi nel costruire cose che volevo. Storicamente, dato un problema, specialmente quello che ho causato, non ho avuto molti problemi a capirlo. Tutto questo è cambiato circa due mesi fa, quando mi è stata offerta la mia prima posizione in una società con cui ho avuto conoscenza dopo una richiesta di pull a un framework che usano.

Mi sono trasferito per la posizione e mi piace molto l'ambiente, è una piccola squadra di una decina di persone e da quello che posso dire sembrano tutti incredibilmente talentuosi. Mi hanno dato un progetto pet in cui avevo per lo più piena autonomia. Hanno sottolineato che non si aspettano che gli sviluppatori diventino interamente produttivi e redditizi fino a circa i 3-6 mesi e che questo progetto li aiuterebbe a capire dove mi trovo come sviluppatore. E 'stato bello e dopo un mese sono stato inserito in uno dei loro progetti più grandi in uno dei loro contratti più lunghi.

Dopo il passaggio a questo progetto mi sono sentito un po 'sopraffatto, si tratta di una base di codice GRANDE in cui le modifiche sono molto visibili ai clienti dei nostri clienti, poiché alimenta un certo numero di siti. È anche una base di codice molto complessa, mentre attribuisco molte delle mie difficoltà alla mia mancanza di esperienza è stato originariamente un progetto di salvataggio, sincronizza tutto tra due quadri separati e ha un numero di modelli che fanno cose che non posso dare alla mia esperienza, non ha documentazione e una copertura di prova dell'85%. Inizialmente ero incaricato di apportare alcune piccole modifiche, ad esempio implementando notifiche honeybadger sugli errori di consegna della posta, o riscrivendo i test minitest con le specifiche rspec.

Poi sono stato incaricato di aggiornare uno dei framework da cui dipende il progetto. Questo mi ha richiesto un tempo anormalmente elevato, e sono stato ripreso a qualcos'altro fino a quando uno degli sviluppatori senior è tornato dalle vacanze per fungere da sistema di supporto durante il processo. Il compito che mi è stato assegnato è stato quello di darmi una quantità altrettanto grande di problemi.

Mi sono seduto con i miei datori di lavoro e ho parlato con loro di questo. Hanno affermato che è normale data la mia esperienza e che attualmente soddisfo le loro aspettative. Tuttavia, questa è la prima volta nella mia vita, non potrei davvero fare ciò che ho deciso in un tempo ragionevole. È una sensazione condivisa tra gli altri, è un evento normale?

Quale sarebbe il tempo atteso per familiarizzarsi con una grande base di codice di 50.000 righe? Ci sono altre pratiche che potrei non sapere che potrebbero aiutarmi a familiarizzare con un codebase più velocemente?

    
posta Senjai 05.01.2014 - 02:23
fonte

5 risposte

8

Ho avuto un buon successo per apprendere nuove basi di codice con il seguente approccio. Cerca di capire:

  1. Scopo: capire cosa fa il sistema o il framework, concettualmente parlando
  2. Architettura: crea una vista sull'architettura generale del sistema o del framework
  3. Componenti: scopri come le parti principali (componenti) lavorano insieme
  4. Codice: ora sei pronto per effettuare immersioni profonde eseguendo il debug dei principali flussi attraverso la base di codice, ad es. mentre corregge un bug

Ecco le motivazioni per ciascuno di questi passaggi e come potresti affrontarli. Nota che potrebbero essere necessarie diverse iterazioni dai passaggi da 1 a 4. Prenditi il tuo tempo.

Obiettivo

Può sembrare ovvio, tuttavia trovo che anche gli sviluppatori esperti a volte manchino di una comprensione di base su quale sia lo scopo principale del sistema. Sforzati di imparare i concetti di business *) prima liberi dalla tecnologia (ad esempio: "questo sistema elabora gli ordini dei clienti e emette fatture - che cos'è un cliente, come sono gli ordini e le fatture, cosa significa emettere una fattura? ? Chi sta usando il sistema? Che cosa hanno bisogno di fare con esso? "Ecc.)

*) "business" che significa: dal punto di vista del cliente o dell'utente

Conoscere il livello concettuale senza guardare specificamente alla tecnologia è un vantaggio importante nel comprendere il suo funzionamento più interiore - il codice è semplicemente un mezzo per un fine e senza conoscere la fine tutto il codice è essenzialmente privo di significato, e quindi apparirà . Se non hai ancora una comprensione concettuale, chiedi a qualcuno di spiegare. Se pensi di farlo, spiegalo a qualcuno più anziano del progetto. Imparerai molto in entrambi i modi.

Architettura

Quindi, cerca di capire l'architettura generale. Questo è a livello di tecnologia, ma senza guardare l'implementazione dei dettagli. Esempi del livello di architettura sono:

  • livelli - ad es. livello web, livello aziendale, livello database, front-end, backend, ...
  • livelli - ad es. interfaccia utente, modello di business, interfacce di servizio, ORM, ...
  • componenti principali - ad es. processore ordini, generatore di fatture, gestore clienti, ...
  • infrastruttura - ad es. configurazione di rete, server, code di messaggi,

Ancora una volta, se non conosci ancora nulla, chiedi a qualcuno di darti una panoramica (entro al massimo 1-2 ore per evitare di perdersi nei dettagli). Beneficerai di documentare i risultati di tale introduzione, di iniziare con semplici diagrammi (magari usando Visio o strumenti simili) e, nel tempo, sviluppare la capacità di utilizzare un approccio più formale come UML. Il processo di documentazione può sembrare noioso e inutile, tuttavia è uteramente utile in quanto non è il risultato che conta, ma il processo di pensiero che va nel disegnare i diagrammi.

Componenti

Guardando i componenti principali, capire come lavorano insieme per raggiungere lo scopo del sistema. Torna al livello concettuale e mappa i concetti e ciò che gli utenti fanno a ciascuno dei componenti. Disegna diagrammi di flusso o diagrammi di sequenza per vedere come i dati attraversano il sistema. Di nuovo lo scopo principale del disegno non sono i diagrammi in quanto tali, ma forzare il tuo cervello a pensarci.

Questo è anche un buon momento per mappare i componenti al codice. Solitamente tali componenti sono costituiti da più parti (ad esempio diversi programmi, classi, script di database o qualsiasi artefatto di codice utilizzato dal sistema). È sufficiente capire, per ciascun componente, dove si trova il codice corrispondente, in seguito è ancora possibile immergersi nei dettagli.

Una nota di cautela: potrebbe essere che i tuoi colleghi non abbiano una nozione di "componenti" diversi dagli effettivi artefatti del codice - questo non è atipico se qualcuno è profondamente immerso nella base di codice. Prova a fare domande come "guardando la base del codice in generale, ci sono aree come programmi / pacchetti / classi che appartengono insieme?" Qual è il loro scopo, come gruppo? Quale di questi ha bisogno di lavorare per raggiungere X? "

Codice

Prendi un particolare punto di ingresso nel sistema - ad es. un'interfaccia utente, un servizio Web, un'API ecc. e impostare una sessione di debug. Quindi scorrere il codice, prestando sempre attenzione a quale componente il codice attualmente eseguito appartiene. Nella tua mente, mappare questo flusso effettivo ai diagrammi di flusso precedenti e magari aggiornarli se trovi spazi mancanti.

Invece di passare attraverso il codice in una sessione di debug, potresti anche usare un profiler. Ovvero, un programma che registra il flusso per te e visualizza una gerarchia di tutte le chiamate di subroutine.

Un'altra alternativa è usare un analizzatore di codice / strumento di reverse engineering in grado di declinare una gerarchia di dipendenze. Tuttavia nella mia esperienza questi strumenti generano troppi dati per essere utili per i principianti, ecco perché preferirei l'approccio di debug.

    
risposta data 05.01.2014 - 10:34
fonte
3

Hai detto di essere un programmatore autodidatta e da questa domanda presumo che tu non abbia una precedente esperienza con progetti così grandi.

Personalmente, ho meno esperienza di te quindi non prendere le mie parole come dono di dio. Onestamente, penso che sia perfettamente normale essere travolti da progetti così grandi quando non si ha una precedente esperienza. Se hanno già espresso che tu soddisfi le loro aspettative, non dovresti davvero preoccupartene così tanto.

Come hai detto non c'è documentazione, prova a migliorare la documentazione se ti permettono di farlo. Ciò farebbe sicuramente a tutti un favore.

TLDR; Dagli tempo. Ci si abitua. Non aver paura di fare domande e prenderlo in modo positivo - tra un anno o due ti verrà da ridere chiedendoti come diavolo non potresti sottovalutare un codice così semplice.

    
risposta data 05.01.2014 - 02:49
fonte
3

Lo dici tu stesso: I'm a self-taught programmer . Libri e corsi lineari ti hanno portato fino a questo punto, ma hanno raggiunto il loro limite. È tempo di fare a meno delle istruzioni passive. Sii serio: ottieni un insegnamento formale.

La maggior parte delle persone migliora significativamente quando coinvolge un insegnante : qualcuno che può guardarti soggettivamente e concentrarsi sui punti di forza e di debolezza personali. Questo potrebbe significare un corso a scuola, seduto accanto a un collega più esperto che è felice di aiutarti, o anche un corso online moderno che fornisce un feedback soggettivo.

    
risposta data 05.01.2014 - 02:57
fonte
3

Quanto tempo per ~ 50kloc? Forse 2-3 settimane. naturalmente ci vorrà più tempo se stai imparando anche la lingua, la struttura o gli strumenti. La cosa fondamentale da capire è che soddisfi le aspettative del tuo datore di lavoro. Non c'è bisogno di stressare troppo, perché ciò porterà ad errori.

Che cosa puoi fare? Sperimentare. Tinker. Fiddle.

Prendi la base di codice e cambia qualcosa per vedere come funziona - e vedi cosa si rompe. Hai detto che il codebase ha una buona copertura di test, quindi dovresti avere una buona visibilità su come le tue modifiche influiscono sul codice.

Se incontri qualcosa che non conosci, fai qualche ricerca per scoprirlo, ma poi fai un prototipo . Prendi questo nuovo concetto e gioca con esso in un ambiente sicuro in cui non senti la pressione del lavoro o delle richieste del cliente.

Il modo migliore per imparare qualcosa è di lavorarci.

    
risposta data 05.01.2014 - 03:52
fonte
-2

Gli studi hanno dimostrato che le persone che vanno a dormire subito dopo lo studio hanno il doppio dei tassi di richiamo di coloro che hanno distrazioni tra lo studio e il sonno.

È davvero incredibile.

Leggi le cose prima di andare a letto e assicurati di non permettere altre distrazioni tra la lettura e l'ora del letto. Riempi il tuo cervello di fatti fino a quando non puoi più trattenerteli e poi colpisci i fogli.

Usando questa tecnica sono diventato certificato in 4 lingue un inverno in un arco di pochi mesi, (cioè sono stato in grado di superare un test di certificazione in queste lingue). In una delle lingue che sono riuscito a raggiungere il massimo della mia classe a causa di risultati quasi perfetti del test. Non penso che avrei mai potuto farlo senza questa tecnica di apprendimento.

Ho letto questo molti anni fa in un libro sulla cognizione, e mi è servito bene nel corso degli anni.

Triste che a più persone non venga insegnato questo in tenera età.

    
risposta data 06.01.2014 - 03:34
fonte

Leggi altre domande sui tag