Fornire il codice sorgente - refactor per la pulizia? [chiuso]

Question

Fornire il codice sorgente - refactor per la pulizia? [chiuso]

#1 da (1 voti)
#2 da (1 voti)

2

Sono nel mezzo dello sviluppo di un'applicazione webforms asp.net a un cliente, ho utilizzato i livelli DataAccess e BusinessLogic in una struttura di cartelle all'interno della mia applicazione, in cui le mie classi DataAccess utilizzano query SQL ordinarie per accedere al dati. Quindi, per determinati motivi, per la parte restante del progetto, ho deciso di utilizzare il framework di entità e creare progetti di livello DataAccess e Business Logic separati per recuperare i dati.

Avevo intenzione di spostare l'intera struttura di cartelle del vecchio livello DataAccess e Business Logic nei progetti di livello appena creati e utilizzare invece il framework di entità.

Ma in questo momento, il mio cliente ha deciso di chiudere il progetto e vorrebbe ottenere il codice sorgente. Sono confuso su cosa consegnargli, dal momento che non ho ancora modificato il mio codice per usare solo il framework di entità, quindi descriverò il mio codice in questo momento come "disordinato".

Dovrei dargli il codice in questo modo? O dovrei spostare tutta la vecchia struttura di cartelle sui progetti appena creati e usare invece il framework di entità, sapendo che ci vorrebbero quasi 3 o 4 giorni di lavoro, che dubito che il mio capo accetterebbe. C'è una soluzione intermedia?

refactoring source-code client-relations

posta user1927272 26.08.2015 - 12:26

fonte

2 risposte

Leggi altre domande sui tag refactoring source-code client-relations

Posso avere due aggregazioni tra due classi? Generazione di intervalli di tempo basata su tecnici disponibili

score 1 · Answer 1

Spiega, in dettaglio, in termini comprensibili al tuo capo, perché, a tuo parere, ciò dovrebbe essere fatto. Spiega anche i test che dovrebbero essere fatti per assicurarti che veramente funzioni. Spiega perché spendere i soldi / prendersi il tempo avrebbe senso per il tuo capo. Ricorda che le modifiche al software dovrebbero essere giustificabili all'azienda in termini comprensibili e quindi possono decidere se spendere soldi in quel modo. Una "buona cosa, una buona idea, un 'dovrebbe essere fatto'" bisogno di venire dal business, NON solo dal tuo senso di "la cosa giusta da fare". La cosa giusta da fare è persuadere gli affari che dovrebbero prendere questa volta e spendere quei soldi. Dovresti spiegare le conseguenze positive e negative del fare / non farlo. Più imparzialmente sarai in grado di farlo, più credibile sarai.

Metto in dubbio la tua stima di 3-4 giorni. Questo include il test? qa? documentazione? La maggior parte dei progetti in cui ho sentito che ci sono 3-4 giorni di lavoro alla fine sono 3-4 settimane. Si presume sempre che si tratti di un'anomalia dovuta al business, alle persone, al progetto, al software, all'infrastruttura, a qualsiasi cosa. Dopo 30 anni di questo ho dovuto sapere che ci sono SEMPRE motivi per cui ci vuole molto più tempo del previsto.

score 1 · Answer 2

Il progetto è come il pappagallo - morto. Quindi non sarai pagato per lavorare su di esso, quindi comprimi tutto e consegnalo così com'è, nasties, bug e tutto il resto.

Potresti aggiungere un rapido readme se vuoi recuperare un po 'di orgoglio professionale che spiega il percorso di migrazione previsto, ma non proverei nemmeno a sistemare altro codice. Il caso peggiore è che tu offri qualcosa che non funziona come le gocce esistenti del cliente e questo renderà solo molto preoccupante il fatto che non abbiano ottenuto il rilascio completo del codice sorgente (presumo che potrebbero aver eseguito pre-release fino ad ora, e forse lo svilupperanno ulteriormente internamente)