Miglior setup / flusso di lavoro per il team distribuito per integrare il DSVC con un enorme sito .NET frammentato?

0

Quindi abbiamo un team con 2 sviluppatori un manager. Il server di sviluppo si trova in un ufficio a casa e il server live si trova in un rack gestito dalla maggior parte della mia azienda. Abbiamo la libertà di fare ciò che ci piace ma voglio incorporare il forno DSVC e FogBugz per noi con alcune procedure standard per dare un senso alle nostre decisioni / progetti / obiettivi.

Il nostro prodotto principale è la formazione basata sul Web attraverso il nostro sito .NET con molti video ecc. e facciamo anche app mobili per più piattaforme. La nostra base di codice è un casino frammentato di 15 anni. L'approccio è stato un po 'rogue delle pagine .asp / .aspx con qualche gestione di classe implementata negli ultimi 6 anni. Ancora mescoliamo i nostri html / vb / j tutti sullo stesso file quando aggiungiamo una funzione / pagina al nostro sito. Non separiamo la logica aziendale dal resto del codice.

Cablare qualsiasi cosa in VS per intelli-sense o test o qualsiasi altro vantaggio è più frustrante di quanto valga, perché devi rejigger manualmente tutto in un solo file.

In che modo gli altri team si avvicinano a questo?

Ho notato che quando ho collegato tutto per VS, vuole fare una lezione per tutte le funzioni. Le persone normalmente compilano DLL per funzioni specifiche della pagina che non saranno riutilizzabili?

Quali approcci ha senso per tenere sotto controllo le nostre pratiche mentre siamo ancora in grado di correggere vecchi anti-pattern e codice obsoleto e ancora di spostarci verso una struttura logica per gli sviluppatori futuri da sviluppare?

    
posta gooddadmike 26.11.2012 - 18:41
fonte

1 risposta

0

Sembra che il dvcs sia la parte più piccola del problema. Non sono sicuro che tu stia dicendo che non hai il controllo del codice sorgente. Altrimenti, questo è il primo passo e Kiln / Mercurial è una scelta eccellente.

Per sapere come spostare il codice su un approccio gestito è necessario fare un passo indietro dal codice base e analizzare, refactoring e raggruppare sezioni di codice comuni in sezioni logiche. Determina quale modello di disegno si adatta meglio a ciò che stai cercando di ottenere. Tieni a mente alcune idee quando progetti la tua nuova soluzione. In particolare DRY e loose accoppiamento . Prova a sfiorare SOLID . I test unitari sarebbero stati molto utili qui, ma suppongo che tu non ne abbia. Vorrei suggerire di scrivere la logica su come ci si aspetta che il sito funzioni in scenari specifici, in particolare le sezioni chiave del sito. In questo modo, mentre passi al passaggio successivo, non stai infrangendo la logica.

In secondo luogo, attuare queste modifiche. Molti team strutturano la propria base di codice in una soluzione con più progetti. In generale, utilizziamo un approccio classico in cui una soluzione consisterà in 3 progetti (UI, Business Logic, Accesso ai dati). Lavorare per creare un'astrazione tra ogni livello, in particolare tra la business logic e l'accesso ai dati. Ogni livello dovrebbe conoscere molto poco l'altro.

In terzo luogo, aggiungi test unitari al tuo progetto. In particolare, elementi chiave di test unitario della logica aziendale per confermare che tutto funzioni come previsto. Generalmente, questo è fatto prima. Tuttavia, poiché questo è un progetto Brownfield, questo è l'unico approccio che abbiamo.

Una volta terminato, scoprirai che l'aggiunta di modifiche al sito è gestibile e prevedibile.

    
risposta data 26.11.2012 - 21:32
fonte

Leggi altre domande sui tag