Sopraffatto dal complesso progetto C # / ASP.NET in Visual Studio 2008 [chiuso]

Passare attraverso il codice può essere utile per determinare la funzionalità. Ma ho trovato che più un'applicazione è complessa, più è probabile che tu debba essere rimbalzato nel debugger e perdermi completamente.

Mi concentrerei sulla comprensione delle regole di business di una particolare funzionalità dell'applicazione. Idealmente, concentrati sulla parte più semplice. Ad esempio, se il tuo sito web ha utenti, concentrati su come gli utenti sono registrati. Cosa è richiesto per loro di registrarsi? E-mail? Cap? Gruppo sanguigno? Se il codice non è chiaro, non c'è nulla di male nel chiedere ad altri sviluppatori domande specifiche sulle regole di business (bene, a meno che non siano jerk).

Una volta stabilito un insieme di regole aziendali, guarda il codice e determina come vengono applicate. L'input è stato convalidato sul server? Cliente? Dove viene archiviata la convalida? Quindi guarda come i dati vengono inseriti / aggiornati / eliminati / selezionati dal database / repository? Quali librerie di classi vengono invocate? I test unitari sono anche un posto eccellente per aiutare a capire le regole di business.

A meno che gli altri sviluppatori non siano pazzi, la maggior parte degli altri aspetti delle applicazioni seguirà un processo simile.

Come per i test unitari, un libro che mi ha davvero aiutato a capire bene i test unitari è The Art of Unit Testing . Mette una buona base e darà un buon inizio su come farlo correttamente. Il modo migliore per imparare i test unitari è iniziare a farlo. Mentre leggi il libro, crea un'applicazione di prova per provare alcune delle tecniche.

La maggior parte dei sistemi travolgenti, nella mia esperienza, ha almeno alcune parti chiave che sembrano più spaventose. Ne scelgo uno e cerco di capire solo quello. Sapendo che la parte chiave rende più facile capire le sue parti correlate.

Il mio approccio preferito per fare questo è usare un diagramma di sequenza. Per me, un diagramma di sequenza mi fornisce l'immagine che ho bisogno di capire come funziona una parte chiave.

Tieni a mente anche che la tua ansia e la tua ansia; sottolinea può che il sistema non è architettato e / o documentato molto bene, quindi non abbatterti per essere confuso.

How can I follow the code to low level functionality in order to get a better grasp of what is going on at a high level?

Risposta breve: non puoi.

Risposta più lunga:

Qualsiasi applicazione non banale sarà troppo grande molto presto perché tu possa provare a capirlo in modo bottom up. Ciò peggiora non appena sono coinvolti un quadro e / o modelli come osservatori. Perderai molto semplicemente leggendo il codice (Come diavolo hanno fatto questo? Dove diavolo viene?), O rimbalzeranno nel debugger attraverso un mucchio di codice framework e perderai rapidamente traccia di quale parte del tuo codice funzionale hai inserito quel pezzo di codice quadro.

Per avere un'idea dell'applicazione e orientarti nel codice: concentrati e non cercare di capire il tutto. Almeno non tutto in una volta.

• Inizia dall'interfaccia utente.
• Identifica i principali blocchi di funzionalità.
• Rompere ancora di più. Preferibilmente in quelle che potrebbero essere considerate storie di utenti o casi d'uso. Ad esempio elencare e filtrare, inserire a, registrare un utente, elencare utenti, autorizzare gli utenti, accedere, ecc.
• Adotta un approccio top-down per vedere come sono stati implementati.
• Prova a mappare le informazioni dell'interfaccia utente sui file nella soluzione. Ad esempio una pagina di applicazione al suo equivalente (i) html.
• Scopri quali classi sono coinvolte nell'implementazione di quella parte dell'applicazione.
• Ignora eventuali problemi trasversali (registrazione, gestione delle eccezioni, stampa, persino operazioni del database). Di solito sono implementati in qualche tipo di framework o libreria e possono essere tranquillamente ignorati se si sta monitorando la reale funzionalità di un'applicazione. Se devi usarli, puoi renderli un argomento separato per la tua indagine.

Come te, passo sempre attraverso le linee nella base di codice per ottenere una sensazione di base.

So come ti senti, una volta sono stato assunto nella decima iterazione di un progetto web su larga scala. La sua architettura era uno dei prototipi del link . Quindi era totalmente nuovo e anche noi stiamo usando il server di commercio 2007, nessuno nel paese aveva esperienza con esso! Sono stato buttato nel profondo, scrivendo Rhino Mocking Tests che anch'io non avevo idea di come fare in quel momento.

Se sei un nuovo arrivato ti daranno tre mesi per dimostrare te stesso e tu sei un junior quindi non ci si aspetta che sappia tutto.

Il trucco è fare la ricerca iniziale su qualsiasi cosa ti sia stata assegnata ed essere pronto a rispondere: link . Quando altri sviluppatori ti vedono impegnarsi e come funziona il tuo pensiero, saranno più propensi a darti una mano.

La ricerca iniziale richiede anche l'esame del sistema di controllo del codice sorgente, dal momento che tutte le informazioni sono probabili nella cronologia, check-in commenti & articoli di lavoro.

ASP.Net è uno stack complicato da comprendere in quanto hai C # e OOP (che conosci già) ma dovrai anche cogliere le tecnologie web specifiche come Page Lifecycle, HTML, CSS, HTTP e Javascript / jQuery . Quindi è naturale essere sopraffatti e sembra che l'applicazione non sia adeguatamente progettata. Ma questa è la realtà nella maggior parte dei sistemi software.
Ci avvicinerei in due direzioni per prima cosa apprendo le aree tecniche che sono deboli (come jQuery, unit test) da sola all'esterno dell'applicazione e secondo tentativo di tracciare / eseguire il debug di una transazione da fine a fine da UI a DB. Prova anche a capire i test unitari, possono essere molto utili se scritti correttamente. La navigazione del codice con Visual Studio è abbastanza buona, ma se riesci a ottenere uno strumento come Resharper è meglio. ASP.Net ha incorporato la traccia per sputare anche la diagnostica.