Come inserire efficacemente il codice dal vivo

Question

Come inserire efficacemente il codice dal vivo

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

5

Quali sono le strategie generali da impiegare quando si tenta di garantire che un modulo di codice funzioni correttamente sul sistema live? Un problema comune che abbiamo nella nostra software house è che normalmente distribuiamo soluzioni al server di un client remoto, su cui non è installato alcun software di sviluppo software. Quando sorgono problemi (inevitabilmente) nel software implementato, ci infastidiscono i clienti che ci dicono di risolvere il problema, ma dal momento che non possiamo eseguire il debug del codice in remoto, restiamo bloccati in un ciclo di tentativi effettivi di indovinare se il nostro codice funzionerà prima lo distribuiamo e quindi ripetiamo il ciclo quando il codice distribuito presenta problemi.

Inoltre, a causa della lontananza del cliente, in genere non è possibile ottenere una copia completa di prova del proprio sistema da parte nostra, quindi finiamo per sviluppare contro le approssimazioni del loro sistema da parte nostra. Ciò rende il nostro debug e la pianificazione del codice sul lato dello sviluppo significativamente meno efficace, perché quando installiamo non sappiamo con precisione quale variabile tra il nostro sistema di test e il sistema live sta causando problemi con il nostro codice.

Finora, ho implementato un logger di errori di base in tutto il codice distribuito che cattura traccia dello stack, dettagli delle eccezioni, metodo, classe, spazio dei nomi, parametri e messaggi aggiuntivi e codici di errore ad ogni eccezione, ma questo accelera davvero il processo di correggere quell'errore specifico. Ho anche provato a scrivere test individuali per sottosezioni specifiche di moduli come eseguibili e eseguirli sul sistema client, ma per i moduli che sono decine di migliaia di righe, questo di solito non è fattibile senza interrompere tutto lo sviluppo.

Sto cercando di mettere in atto una strategia che ci aiuterebbe a evitare le eccezioni in primo luogo, ma sono bloccato sul fatto che:

Non abbiamo (e di solito non possiamo ottenere) un sistema di test funzionante che modella accuratamente il sistema live, ad es. un'immagine del sistema live, se ce l'abbiamo, allora è mesi non aggiornati
Non possiamo installare il software di debug remoto sul server live
In genere il client non ha un server di test dedicato, quindi qualsiasi implementazione deve essere pubblicata direttamente
Non avendo accesso a una copia del sistema live significa che non possiamo scrivere test unitari efficaci che modellano effettivamente le condizioni in cui il codice verrà eseguito sul lato client

Se aiuta, il codice è in genere C # in esecuzione su .NET 3.5. Come affrontare meglio questo problema?

development-process programming-practices

posta Ben H 27.03.2013 - 11:55

fonte

2 risposte

2

Un possibile modo sarebbe quello di generare più file di log (che sono riciclati e raccolti con garbage collection, in alcune dimensioni e / o frequenza) e strumentare il codice per registrare cose che sono puramente informazionali, avvisi ed errori nel file di log ( s) (e, idealmente, hanno un sacco di registrazioni di debug che possono essere attivate da un'impostazione di flag o di configurazione, in modo da poter ottenere anche registri più dettagliati dall'esecuzione nell'ambiente del cliente).

Questi log possono quindi essere semplicemente compressi dal cliente e spediti a te (posta, ftp, masterizzati su CD, ...)

risposta data 27.03.2013 - 15:37

fonte

Leggi altre domande sui tag development-process programming-practices

Perché la licenza pubblica Microsoft non è compatibile con GPL? Da dove viene il termine "Front End"?

score 10 · Accepted Answer

We don't have (and typically can't get) a working test system that accurately models the live system, e.g. an image of the live system, if we do have it then it's months out of date

Questo è il problema. Sai che questo è il problema.

Più un sistema è complesso, più punti di integrazione potrebbero avere, più è probabile che tu abbia problemi.

Perché non riesci a ottenere un sistema di test funzionante? La tua azienda o il tuo cliente non pagheranno per i server? I dati sono tipicamente sensibili? Non può essere reso anonimo?

Hai dei tester? Perchè no? La tua azienda non pagherà per loro?

In genere questi tipi di cose dovrebbero essere addebitati alla build di un sistema, ma come spesso accade, il prezzo è sempre un problema per i clienti. Ottieni quello per cui paghi come si dice.

Hai abbastanza tempo per mettere in atto tutti i tuoi test unitari?

Come programmatore sul fronte del carbone, puoi solo attenuare queste cose finora.

Avere i test unitari e la copertura del codice più alti e aggiornati possibile, e avere il sistema che utilizza l'iniezione delle dipendenze per facilitare il test, efficacemente prendendo in giro i punti di integrazione, è un ottimo inizio.

Se un manager si lamenta per te perché qualcosa è fallito in diretta, questo elenco di motivi è un buon punto di partenza sul motivo per cui è così difficile da implementare in queste condizioni.