Standard di organizzazione per programmi di grandi dimensioni [chiuso]

Question

Standard di organizzazione per programmi di grandi dimensioni [chiuso]

#1 da (2 voti)

1

Sono l'unico sviluppatore di software presso l'azienda in cui lavoro. Sono stato assunto direttamente dal college, e ho lavorato qui per diversi anni. Quando ho iniziato, eveeryone gestiva i propri dati come meglio credevano (un sacco di schedari).

Fino a poco tempo fa, sono stato incaricato solo di piccoli progetti standalone per aiutare con flussi di lavoro semplici. All'inizio dell'anno mi è stato chiesto di sostituire il loro software HR. Ho usato SQL Server, Entity Framework, WPF, insieme a MVVM e Repository / Unit di modelli di lavoro.

È stato un grande successo. Sono stato molto contento di come è andata, ed è stato un programma molto solido. Come tale, il mio datore di lavoro mi ha chiesto di espandere questo programma in un cruscotto aziendale che tiene traccia di tutti i vari domini di dati aziendali (persone, stipendio, veicoli / beni, statistiche, ecc.) Uso l'autenticazione integrata e grazie alla creazione iniziale delle risorse umane , Posso mappare gli utenti a persone in posizioni, quindi so chi è chi quando aprono il programma e posso mostrare a ciascuna persona un dashboard personalizzato, date le loro funzioni di lavoro.

La mia preoccupazione è che non ho mai lavorato a un progetto così grande. Sto pianificando, incontrando gli utenti finali, sviluppando, documentando, testando e implementando da solo. Faccio parte della seconda aggiunta e vedo che il mio codice si sta disorganizzando. È ancora programmato bene, sto solo lottando con l'organizzazione di namespace, classi e il modello di database.

Ci sono delle buone linee guida da seguire che mi aiutino a mantenere tutto in ordine? Come ho ora, ho cartelle per Dati, Archivi / Unità di lavoro, Viste, Visualizza modelli, Risorse XAML e Utilità varie. Devo creare cartelle padre per ogni dominio dati? Devo creare modelli EF separati per dominio anziché quello che ho per l'intero database? Esistono standard per l'organizzazione di programmi di grandi dimensioni che si estendono su più domini di dati?

Apprezzerei qualsiasi suggerimento.

c# wpf namespace

posta Chronicide 26.10.2013 - 19:03

fonte

1 risposta

Leggi altre domande sui tag c# wpf namespace

RequestContextHolder.currentRequestAttributes () e accesso alla sessione HTTP In Android, c'è qualche motivo per impostare un fornitore di contenuti per un database locale?

score 2 · Answer 1

Ciò che stai descrivendo è ciò che accade in molti casi: in qualche modo sei vittima del tuo stesso successo. Hai un prodotto di successo e stai cercando di estenderlo, possibilmente in modi che inizialmente non avevi previsto e progettato. E forse il tutto sta diventando troppo grande per adattarlo alla tua testa.

Con il vantaggio di 20-20 senno di poi, potresti aver ridisegnato il sistema (secondario) originale come parte di quello più grande. Quindi cosa fare ora?

Non si indica se si sta utilizzando un sistema di controllo del codice sorgente. Altrimenti prendine uno ora . Le scelte principali sono Git, Subversion e Mercurial. Fallo ora, in modo che quando apporti le modifiche puoi vedere cosa hai cambiato e puoi annullarlo. Lo chiamo una macchina del tempo.
Esiste un progetto generale? Hai delle foto sul muro? Se il disegno è nella tua testa, o non hai immagini, produci quelle immagini ora . E etichettali "versione x", per rendere chiaro a te stesso che possono cambiare.
Aggiungi ad ogni cartella un file README che spiega a cosa serve, deve essere lì, e cosa significa non essere lì. Più tardi, queste semplici regole ti aiuteranno a decidere dove le cose appartengono.
Anche se si utilizzano strumenti e framework potenti, è facile scomporre la logica di business nella logica di visualizzazione e controllo e viceversa, soprattutto perché il prodotto è iniziato così piccolo. Probabilmente senti che non puoi fermarti e districarlo ora, ma smetti di aggiungere alla confusione. Ad un certo punto, esegui una revisione per individuare le cose che si trovano nel posto sbagliato o al livello sbagliato e aggiungi commenti al codice che descrivono cosa dovrebbe accadere quando ne hai la possibilità.
Ricorda che l'astrazione è tua amica: se crei interfacce astratte per i tuoi componenti, puoi sostituire implementazioni migliori o diverse in seguito. Come ora hai imparato, i sistemi di successo si evolvono. Le domande che chiedi sono valide. Ma la risposta alla maggior parte di loro è "dipende". Il mio consiglio guida è di usare l'astrazione per aiutare a mantenere le cose separate, e usare quell'idea per guidare le scelte che fai. Mi dispiace di non poter essere più specifico qui.
Non aspettare fino a quando non hai completamente nevicato prima di ricevere aiuto. Discutere con i dirigenti aziendali che cosa faranno in quanto il carico di lavoro supera la capacità dell'utente. Può essere una conversazione spaventosa: avvicinala come manager (dal momento che sembra che tu gestisca il reparto IT Development) e mostra che stai pensando a come l'azienda gestirà la crescita.

Congratulazioni. È un bel problema!