Come impiegare una conoscenza più amatoriale dell'architettura e del design del software in modo agile? [chiuso]

Question

Come impiegare una conoscenza più amatoriale dell'architettura e del design del software in modo agile? [chiuso]

#1 da (1 voti)

1

Ho un problema durante la progettazione di qualsiasi applicazione che sia greenfield o brownfield refactored a causa di spesso trovare un potenziale difetto o un'incertezza con il design o l'architettura che penso. Ho sprecato un sacco di tempo cercando di costruire un progetto di cui sono fiducioso senza un sacco di tempo investito sin dall'inizio. Sento che presto gli errori portano a grandi problemi in fase di sviluppo (specialmente quando si refactoring le app brownfield).

Voglio minimizzarlo, ma non sono sicuro di come farlo senza una soluzione ottimale o disturbando gli sviluppatori senior o l'architetto. Ad esempio, esiste un'applicazione legacy che deve essere sottoposta a refactoring. Posso riscriverlo in un nuovo progetto e ridurre le righe di codice da 12k a 2-3k. Lo scopo dell'applicazione è generare pagine HTML, ma è fatto in un'applicazione console in C #. Fino ad ora non ho fatto nessuno sviluppo web, ma non sono sicuro che ASP.NET MVC sarebbe una buona scelta, e anche in questo caso, se il mio design o architettura è una buona scelta.

Capisco che quando lavoro in un team posso ricevere buoni e solidi consigli, ma come posso diventare meno dipendente dal pensiero della mia squadra e più da solo senza sprecare il tempo della società a ricercare ogni possibilità tecnologica? Questo viene solo con il tempo e l'esperienza? Se la prova e l'errore sono il vero e provato modo, l'architettura e il design possono essere fatti in modo agile con il minimo spreco di tempo?

design c# agile architecture

posta Jim Stahl 16.05.2014 - 19:20

fonte

1 risposta

Leggi altre domande sui tag design c# agile architecture

Pulsante Indietro dopo aver fatto i post sulla stessa pagina Il programmatore precedente è morto in modo imprevisto; come faccio a riprendere da dove si era interrotto? [duplicare]

score 1 · Accepted Answer

I metodi Agile generalmente iniziano e finiscono con il cliente. Il cliente potrebbe essere interno alla tua azienda o a un consumatore esterno. In entrambi i casi è necessario comprendere le loro esigenze e conseguirlo attraverso la conversazione - parlare con loro, discusare le soluzioni con loro, ascoltare i loro feedback e suggerimenti. Tutto ciò indica che ottenere feedback dal tuo team e dagli utenti del tuo software è, piuttosto che essere uno spreco del loro tempo, un investimento indispensabile del loro tempo; non solo nella qualità del software stesso, ma anche nel tuo valore come membro del team. Se i tuoi manager e ingegneri senior sono per metà decenti e familiari con i paradigmi Agile, apprezzeranno questo, altrimenti avrai l'opportunità di migliorare la cultura aziendale.

L'architettura del sistema dipenderà spesso dall'infrastruttura IT in cui il software deve operare: ASP .NET non è la scelta migliore se il server web di destinazione esegue Linux. Se si tratta di Windows, ASP .NET è ottimo e MVVM (piuttosto che MVC) è un buon modo per strutturare l'applicazione e gli assiemi. Ciò significa che la scelta dell'architettura non dovrebbe richiedere più di qualche minuto per decidere!

Il design della tua soluzione è un po 'che richiede tempo ed esperienza, ed è qui che le metodologie Agile aiutano davvero, perché ti consentono di migliorare il tuo design in modo efficace. Fai un po 'alla volta, fallo funzionare, ottieni feedback dal cliente e passa al prossimo bit, rifattorizzando ciò che hai fatto prima, se necessario. Il "design" è ciò che si finisce con, piuttosto che ciò che si inizia con. Fornendoti un test accurato in ogni fase e incoraggiando il feedback dei tuoi clienti mentre vai avanti, funzionerà e, se funziona, è un buon progetto. "Solo è abbastanza buono abbastanza buono." Ovviamente, devi considerare "l'abitabilità" e la manutenibilità del codice sorgente.

Test Driven Development è un modo popolare di gestire sia la funzionalità che la qualità del codice che produci. È particolarmente adatto per abbinare la programmazione, ma è facile da usare quando devi lavorare da solo. Questa è sicuramente una tecnica che consiglio vivamente, anche se non si utilizza altro dal portfolio Agile. Se combinato con la copertura del test MCDC, puoi ottenere un livello di confidenza molto elevato nel tuo software.

Implementare l'architettura selezionata in modo efficace richiede tentativi ed errori (e ricerca, SO, caffè, imprecazioni, nottate, ecc.) ma anche gli sviluppatori esperti passano il loro tempo a sperimentare ciò. Buone pratiche di sviluppo ti aiutano a raggiungere il tuo obiettivo più rapidamente e l'intero punto di Agile è che si tratta di una raccolta di "modi migliori per sviluppare software".

Quindi, per rispondere alla tua domanda: smetti di preoccuparti e inizia a scrivere codice (e divertiti!): -)