Infrastruttura necessaria per progetti di grandi dimensioni con molti componenti che comunicano tramite IPC

0

Ho una domanda abbastanza approfondita che probabilmente non ha una risposta esatta.

Come programmatore di software, di solito sono incaricato di lavorare su un programma o un progetto con una comprensione minima di come gli altri componenti o programmi del progetto interagiscono tra loro. Quando un programma fallisce in un mare di più componenti e processi, quali elementi dell'infrastruttura sono necessari per garantire che il problema possa essere tracciato con precisione all'applicazione in violazione?

Più in particolare, quali elementi dell'infrastruttura dovrebbero essere necessari per questo grande progetto e che sono facoltativi ma molto utili. Un esempio del genere a cui posso pensare è una forma di infrastruttura di logging comune che consente a uno sviluppatore o tester di sfogliare facilmente un log che contiene numerosi componenti per i messaggi che potrebbero alludere al programma colpevole insieme a una "traccia" di ciò che è accaduto prima che si verificasse il problema. Sto pensando a qualcosa di simile allo strumento alogatto di Androidi.

Questi elementi infrastrutturali necessari dovrebbero essere indipendenti dalla lingua.

Mentre questi elementi dovrebbero essere compresi da tutti gli ingegneri del team in questione, quali elementi dovrebbero essere compresi con grande dettaglio dagli ingegneri del sistema tecnico e cosa dovrebbero essere i singoli ingegneri del software ad aggiungere ai loro strumenti per consentire tali infrastrutture prendere piede?

Non esitate a chiedere chiarimenti se qualcosa non ha senso, perché ho capito che questa domanda è molto ampia e ha bisogno di un po 'di raffinatezza. Raffinerò se necessario dalle risposte e dai commenti che ricevo.

Grazie per l'aiuto!

Aggiornamento:

Sto entrando in una squadra che ha forse il 5% del codice con Test unitari e sta appena iniziando a Instrument and Monitor. Ogni programmatore di software (dico programmatore e non ingegnere perché non tutti i componenti del team sono ingegneri) non capisce le basi del fail immediato e del controllo di sanità mentale. Gran parte della nostra linea di base del software è il codice legacy e sta per essere trasferito. Sfortunatamente non abbiamo il potere dell'uomo di refactoring di molti dei componenti più vecchi. Questo è ciò che mi ha portato a cercare di capire se ci sono strumenti infrastrutturali necessari che possono essere utilizzati per rilevare e trovare i bachi all'origine in modo molto più rapido. Mentre non mi aspetto uno strumento per magicamente, penso che potrebbero esserci strumenti o configurazioni che consentono di trovare più facilmente bug in un mare di componenti.

    
posta jluzwick 04.12.2012 - 20:50
fonte

2 risposte

3

When one program fails in a sea of multiple components and processes, what infrastructure elements are necessary to ensure that the problem can be accurately tracked to the violating application?

Direi che stai facendo la domanda sbagliata. È bene prepararsi all'eventualità che le cose vadano storte, ma dipendere dagli umani per farlo in un grande sistema distribuito, molti dei vantaggi del grande sistema distribuito ...

Cose su cui concentrarsi:

  • Test delle unità : l'80% + del tuo codice non verrà interfacciato con l'IPC. Assicurati che it funzioni (con vari input, comportamenti errati) e che elimini molti dei problemi che possono avere un impatto su una particolare applicazione.
  • Monitoraggio : il tentativo di "rintracciare" i problemi si concluderà con frustrazione, anche se l'infrastruttura di registrazione funziona correttamente. Avere una buona configurazione del sistema di monitoraggio per identificare i problemi in anticipo e in modo specifico per il processo consente di vedere immediatamente quali erano i problemi.
  • Progetta in modo univoco : o fallisci o lavori. Non passare lungo i cattivi dati; non 'kinda work'. Se un'app identifica che la sua coppia IPC è stata disconnessa o ha fatto qualcosa di strano, fallo lì. È quindi immediatamente evidente chi è il responsabile.
risposta data 04.12.2012 - 21:15
fonte
1

Dai un'occhiata alla Enterprise Library di Microsoft, una serie di librerie, di Application Block, pensate per essere esattamente questo - strumenti comunemente condivisi utilizzati in un'ampia applicazione. Includono componenti per la memorizzazione nella cache, la gestione delle eccezioni, la registrazione, l'accesso ai dati e altri elementi che sono ortogonali alla tua attuale logica di business: dovrebbero rimanere più o meno gli stessi per tutti i moduli.

Naturalmente, i componenti della Enterprise Library non sono un elenco completo, ma sono un buon punto di partenza per vedere cosa è comune a molte applicazioni, e quindi dovrebbero essere estratti dal codice principale in librerie di utilità condivise.

    
risposta data 04.12.2012 - 21:04
fonte