Come dovrei andare a imparare un'applicazione molto grande e complessa? [duplicare]

25

Essendo uno sviluppatore giovane e abbastanza inesperto recentemente assunto da una società di software "reale" mi piacerebbe alcune opinioni e indicazioni su come fare quanto segue:

Approcci su come acquisire familiarità con i prodotti di un'azienda, soprattutto quando non hai idea di come funzioni tutto . La società in cui mi trovo adesso ha un prodotto ENORME, in continua evoluzione ed essendo qui da 2 settimane non ho ancora idea di come tutto si incastri, a parte un tipo speciale di colla fatta dalle lacrime e dalla frustrazione dei giovani sviluppatori, è incredibilmente frammentato e solo 4 persone in ufficio conoscono il funzionamento interno, tutti costantemente impegnati

Fornisci input utili sul prodotto: ora so che sono solo un bambino in azienda e non posso aspettarmi di fornire qualcosa di innovativo nei miei primi mesi, ma tu devi dare tanto quanto sei pagato. Sto andando in giro il doppio rispetto al mio precedente lavoro ma obiettivamente parlando non ho ancora fatto nulla per meritarlo. Rimasi seduto a fissare lo schermo del mio portatile cercando di decifrare il codice. Ora si potrebbe dire che questo è quello per cui sono qui, per iniziare almeno, ma al mio precedente lavoro ero una specie di "go-to-guy", prendendo decisioni e contribuendo a quasi ogni aspetto della gestione quotidiana della compagnia . Mentre quello era un sacco di lavoro mi è piaciuta la sensazione di essere "connesso" al funzionamento interno della società in cui ho un interesse (una relazione simbiotica, se lo vorrai). ti preghiamo di modificare questo punto in basso, lascerò spetta a voi ragazzi decidere cosa è importante

Pubblicherò altre cose mentre penso a loro, devo tornare a leggere e scrivere qualcosa che somiglia solo vagamente a C #

    
posta Dani 14.10.2011 - 09:13
fonte

9 risposte

23

2 settimane? Nel mio secondo lavoro era abbastanza comune per i nuovi assunti ottenere solo il 'oh! lo capisco adesso! momento 9 mesi in ....

Se è davvero un prodotto enorme, si aspetteranno molto tempo per "ottenerlo", continua a lavorare sodo e fai molte domande.

    
risposta data 14.10.2011 - 09:56
fonte
14

Anche se non è un nuovo sviluppatore, mi trovo spesso in situazioni in cui non ho idea di come funzioni o sia progettato il software ( se è stato progettato ). Spesso se c'è qualcuno da chiedere, non ne sa molto più di me, o è avvolto in qualcos'altro.

  • Primo passo: preparati. Installa un ambiente di sviluppo, prendi un notebook, cancella una lavagna. Se ci sono documenti di progettazione, trovali e disponili per riferimento. La risposta di @ mcottle è fantastica. Se vuoi capire un sistema, devi avvicinarti come farai [fare un test] / [insegnare a qualcun altro]. Scrivi molte domande, disegna relazioni tra i componenti e tieni traccia delle cose che ti hanno sorpreso. Se un nuovo sviluppatore dovesse mettere insieme un abbozzo del sistema in un formato (wiki, documento, qualunque cosa) che potrei trasmettere ad altri nuovi sviluppatori come punto di partenza - 1 milione di punti brownie nel mio libro.

  • Secondo passo - Avvicinalo come utente. A cosa serve questo software? Quale problema è progettato per risolvere? Leggi il manuale. Spero di darti un po 'di contesto mentre vai avanti.

  • Terzo passo: determina i bordi del sistema. Da dove viene l'input? Qual è il risultato finale?

  • Quarto passo: traccia un input tramite il codice di base. Non impazzire troppo nei dettagli del primo passaggio, scrivi semplicemente le domande man mano che procedi. Mentre esegui ulteriori pass puoi provare a rispondere a queste domande e crearne di nuove.

  • Quinto passo - Trova le cuciture nel sistema. L'idea qui è di trovare i principali strati architettonici (un I / O o un confine di rete è solitamente una buona cosa da documentare).

  • Sesto passo - Passa ora a rompere le cose in componenti. Il sistema è abbastanza modulare da poter pensare a X senza chiedersi cosa sta succedendo a Y e Z? Altrimenti, documenta quella relazione. Da qui puoi dividere e conquistare la tua strada attraverso il sistema, rompendo ogni componente fino a raggiungere una comprensione "abbastanza buona".

Si noti che questo è un metodo abbastanza completo. In un progetto molto ampio è probabile che tu possa passare molto tempo senza aver bisogno di sapere esattamente come il modulo Foo interagisce con Bar. Mi piacerebbe imparare abbastanza sul sistema che so quali parti mi sento a mio agio nel cambiare e che sono avvolte nel mistero. Questo è normale in qualsiasi progetto; ci sono sempre delle librerie in cui usi il 5% delle funzionalità e rimani beatamente all'oscuro del resto.

    
risposta data 14.10.2011 - 14:08
fonte
7

Suppongo che tu abbia già installato l'ambiente di sviluppo e che tutti gli strumenti necessari funzionino - se no, inizia con questi. La configurazione del tuo ambiente di sviluppo richiede in genere molto tempo, con lunghi periodi di inattività che attendono il download / l'installazione del software, mentre puoi ancora fare altre cose.

Riguardo alla tua mancanza di informazioni, ti suggerisco di parlare con i tuoi colleghi sviluppatori e manager. Se gli sviluppatori senior sono impegnati, parla con gli altri - potrebbero essere in grado di spiegarti alcune cose o indirizzarti a fonti di documentazione e / o sono anche frustrati dal fatto di non avere il quadro completo. In quest'ultimo caso, puoi avvicinare il tuo manager insieme, per trovare una soluzione al tuo problema.

Anche se gli anziani sono completamente fidanzati, probabilmente capiscono che passare del tempo a insegnare / tutorare i giovani ora può ridurre il loro carico di lavoro a lungo termine. Ma è il management che decide in fin dei conti sull'assegnazione delle attività, quindi la decisione è da prendere.

    
risposta data 14.10.2011 - 09:19
fonte
7

Un consiglio, fai molte domande ma non come pensi a loro. Mantieni un elenco di domande e quando ottieni tempo con uno sviluppatore esperto, fai uscire la lista. È un uso molto più efficiente del loro tempo per rispondere a 10 pensieri ben pensati attraverso domande in sequenza di cinque domande nel corso della giornata che interrompono il loro focus.

Considera l'uso di e-mail se preferirei che.

Quando hai la risposta a una domanda, documentala. Se c'è un wiki, usalo. Se non ce n'è uno ne crea uno. Anche tiddlywiki sarebbe meglio di niente.

    
risposta data 14.10.2011 - 10:24
fonte
5

Se fossi in te non ti preoccuperei tanto di capire "come funziona tutto". Se sei assunto come junior / inesperto, concentrati sui tuoi compiti e fai domande quando è il momento. Ad esempio, quando ti viene assegnata una nuova attività, prova a utilizzare quella connessione con i tuoi anziani per porre domande più generali, ma non porre troppe domande contemporaneamente. Prova anche a dedicare un po 'del tuo tempo ogni giorno a sfogliare in altre parti il software, i documenti o qualsiasi altra cosa tu abbia accesso. Prima che te ne accorga, vedrai come si combina e finirai per diventare il senior.

Ricorda che se ritieni che sia frammentato potrebbe non essere effettivamente così, forse non ne sai abbastanza del prodotto ancora.

    
risposta data 14.10.2011 - 09:45
fonte
5

Mentre ammiro coloro che possono sedersi e leggere il codice come se leggessero un romanzo, a volte lo trovo un po 'noioso e che non funziona davvero con grandi prodotti software e librerie complesse.

Ho scritto un lungo post sulla lettura e la comprensione del codice qui che potrebbe essere utile per questa discussione particolare - technikhil.wordpress.com/2010/07/06/how-to-read-code-a-primer Il post tratta del codice di lettura nel contesto del miglioramento di sé stesso, quindi parla di come trovare un buon codice da leggere; ma in questo caso dal momento che hai già identificato il codice che vuoi comprendere, questi punti potrebbero essere utili -

  1. Passare attraverso la documentazione di progettazione e cercare di ottenere un'idea per il modo in cui il codice è stato costruito. I buoni progetti software seguono certe schemi architettonici - questi dettano l'organizzazione del codice. Una volta si ottiene un controllo su questo, capendo che il codice diventa un bel po ' Più facile. Se riesci a creare un diagramma di classe del codice puoi ottenere un buona idea del layout.
  2. La prossima cosa da fare è compilarlo ed eseguirlo. Questo può essere semplice o duro a seconda del processo seguito nel progetto e la sua documentazione.
  3. Ora è il momento di accendere il tuo IDE preferito e andare ad esplorare. Un buon punto di partenza per l'esplorazione del codice sarebbe cercare di rintracciare una funzionalità del progetto che ti è familiare. Questo ti permetterebbe di passare attraverso i vari livelli e sottosistemi e di capire come si collegano. Ad esempio, quando stavo esplorando NUnit, ho iniziato scrivendo un test e guardando le classi di codice che dovevo fare.
  4. Prova e identifica gli schemi di progettazione usati nel codice. Se non sai quali sono gli schemi di progettazione, allora devi smettere di leggere questo post in questo momento e leggere questo libro. Familiarizza con i modelli di progettazione: costituiscono un ottimo modo per riconoscere e comprendere il design di un codice ben scritto. Questo rende più facile tenerlo in testa durante la lettura del codice. Ti aiuta anche a identificare le sfumature e le personalizzazioni fatte dai programmatori più facilmente.
  5. Prova a scrivere test per il codice per comprenderlo appieno - questo è davvero un modo utile per comprendere le dipendenze tra le diverse parti del codice. Quando provi a scrivere un test per il codice devi prima soddisfare (deridere) tutte le sue dipendenze. Quindi è necessario comprendere i possibili punti di ingresso e i valori di uscita per il codice. Ciò migliora la tua comprensione del codice e ti porta al livello successivo.
  6. Prova a rifattorizzare il codice. In questo passaggio ti sei spostato dalla semplice comprensione del codice per diventare abbastanza familiare da poterlo modificare. A mano a mano che aumenta la sofisticazione del tuo refactoring, la tua comprensione.
risposta data 03.03.2012 - 05:45
fonte
4

Inoltre, se si tratta di un progetto davvero enorme, non si può mai sapere come funziona. Puoi solo conoscere i dettagli di alcuni moduli e solo sapere come interagiscono con altri moduli. Pochissimi ingegneri sono esperti su un intero sistema.

    
risposta data 14.10.2011 - 16:48
fonte
3

Tutti diversi ma ho trovato il modo migliore in cui mi sono imbattuto in fretta è stato quello di fare i cantieri "duri" e scendere e imparare. Fondamentalmente ciò implicava leggere e leggere, investigare e investigare di più e non avere paura di fare domande (anche se nella giusta situazione e momento).

Se ci sono file di log, guarda in questi. Mi sono reso conto che in un certo senso essere coinvolto nell'osservare i bug era un ottimo modo per iniziare a fare i conti con il progetto. Sebbene noioso e non il più piacevole mi ha dato la possibilità di approfondire veramente una soluzione. Finché sei pronto a indagare su un problema nel modo più completo possibile. Anche se non puoi risolverlo da solo e devi indicarlo a un membro senior, se hai dimostrato la tua capacità di esaminare veramente il problema e può aiutare a sottolineare le aree da te indagate e persino a offrire le tue opinioni su ciò che potrebbe essere andare storto.

Ho scoperto che i membri più anziani erano più disposti a sedersi e poi a parlarne con te alla tua scrivania se sanno che hai già avuto il tempo di fare molto lavoro sull'asino.

Una nota importante che potrebbe aiutarti è quando fai delle domande, prova a scrivere la risposta in modo da non commettere lo stesso errore di chiedere nuovamente. Sebbene la maggior parte degli sviluppatori senior abbia una grande dose di pazienza per i junior, può rapidamente dimagrire quando i giovani non sembrano prestare attenzione a quello che stai dicendo.

Buona fortuna per il tuo nuovo ruolo.

    
risposta data 14.10.2011 - 10:25
fonte
3

Se il progetto è davvero enorme, non si aspetteranno che tu lo sappia tra due settimane o addirittura due mesi. Se lo fanno, allora sei nel posto sbagliato.

La mia ultima posizione è quella in cui non è previsto un alto grado di pertinenza sul prodotto effettivo spedito per un anno. Per migliorare la velocità ho passato molto tempo a leggere la documentazione, semplicemente giocando con il prodotto / hackerandolo e facendo molte domande. I primi compiti che si ottengono (correzioni di bug, modifiche minori) dovrebbero iniziare a farti diventare veloce con il progetto. Ciascuno dopo dovrebbe portare più comprensione.

Sono sicuro che c'è un processo che puoi avere tracciato e seguire ma, ho trovato il modo migliore di continuare a tapparlo. Più fai, più imparerai.

    
risposta data 14.10.2011 - 14:29
fonte

Leggi altre domande sui tag