L'interruzione di corrente dovrebbe essere considerata come uno scenario da implementare?

Direi che non dovresti mai avere nulla sull'interruzione laterale del software in modo permanente in qualsiasi scenario. Questo non è un comportamento accettabile in questo giorno ed età. Ovviamente non puoi controllare in che modo l'hardware gestirà la perdita di energia, ma non è questo il tuo problema.

30 anni fa, quando tutti usavano i mainframe, è stato scritto del codice che ottimizza l'utilizzo della RAM scrivendo tutto sullo storage non volatile, quindi una certa quantità di rottura era inevitabile. Ma ora? Hai troppe opzioni.

When time that scenario should be considerable?

Quando il tuo contratto dice che la tua applicazione funziona nonostante la perdita di energia elettrica.

If electric loss will cause some data loss so do you care about it ?

No. Solo quando il contratto dice che funziona con perdita elettrica.

Se sei preoccupato, dì semplicemente che il tuo programma non funziona quando la macchina non funziona correttamente.

What do you think If our application doesn't work anymore even electric loss scenario shouldn't be fault to consider if electric loss broke the application permanently ?

Se la perdita elettrica danneggia i file sui dischi, ciò non ha nulla a che fare con il tuo programma. Il sistema operativo non è riuscito a mantenere l'integrità del file su disco e il programma è stato danneggiato.

A meno che il tuo contratto non specifichi, in particolare, che garantirai di lavorare con la perdita elettrica, non dovresti fare nulla.

So we have to consider these situations always ?

No. Li consideri mai.

L'integrità del file system fa parte del sistema operativo. Non è la tua applicazione.

A meno che il tuo contratto non contenga - in particolare "Questa applicazione non danneggerà i file durante la perdita elettrica" - non preoccuparti.

Se vuoi preoccuparti, devi scrivere un sistema operativo che garantisca che non si verifichino danni ai file durante la perdita elettrica. Dopo averlo fatto, devi inventare un disco rigido che non garantisce danni durante la perdita elettrica. Quindi è necessario inventare un alimentatore, una ventola di raffreddamento e un rack che non garantiscano danni durante una perdita elettrica.

Dopo aver inventato tutte queste cose nuove e meravigliose, puoi scrivere la tua applicazione che gestisce lo scenario di perdita elettrica.

Una semplice regola: conferma qualsiasi modifica ad una memoria permanente il prima possibile.

Ad esempio, una cosa che non mi piace di Visual Studio è che salva l'area di lavoro solo dopo aver chiuso la soluzione o l'IDE. Ho avuto alcune situazioni in cui la mia macchina si è bloccata e quindi l'ultima situazione nello spazio di lavoro è stata persa. All'apertura della soluzione, mi è stata presentata la configurazione dall'ultima volta.

Pertanto: commuta il cambiamento non appena l'utente lo ha creato. Non tenerlo in memoria fino alla fine della sessione.

Inoltre, non tenere i file aperti per un periodo di tempo prolungato. Aprili quando ne hai bisogno, quindi chiudi non appena hai finito con loro. Un arresto non programmato può danneggiare i file aperti.

Se stai fornendo una soluzione, e non solo scrivendo del codice, devi considerare molte cose.

Stai scrivendo un software o stai consegnando un sistema? Questa domanda vuole essere retorica.

Se stai consegnando un sistema, Funziona in un ambiente.

Esistono requisiti di interoperabilità. Esistono requisiti di manutenibilità (aggiornamento, convalida della configurazione, messa in servizio e disattivazione).

Ci sono requisiti di prestazione (abbastanza veloci da valere la pena di usare)

Ci sono requisiti di affidabilità. [Nello spazio integrato, l'interruzione di corrente è un evento comune.]

Ero solito porre una domanda di interruzione di corrente quando stavo intervistando perché gli ingegneri del software lavorassero su sistemi critici.

Un file system di journaling e due copie di documenti critici, che vengono scritti per coprire una moltitudine di peccati.

Se la corrente si spegne, il sistema dovrebbe agire in modo appropriato. Se il sistema operativo è in grado di supportare tutti i requisiti di affidabilità, è grandioso. Se l'hardware è in grado di supportare tutti i tuoi requisiti di affidabilità, (Una buona risposta alla mia domanda di interruzione di corrente è stata "Prendi un UPS") che è grandioso.

A volte l'ingegneria deve accadere per rendere l'affidabilità.

Spesso i clienti non specificano le cose nei requisiti, quindi potrebbero non pagare finché il prodotto non soddisfa i requisiti inizialmente non dichiarati. L'elicitazione dei requisiti e la convalida dei requisiti possono semplificare la vita degli ingegneri del software. Guarda lo standard CMMI (GRATUITO!) Per un'idea di ciò che queste attività potrebbero comprendere.

Se sei un programmatore TL; DR Qualcun altro lo fa.

La perdita di potenza implica che, per impostazione predefinita, il software smetterà di funzionare. Hai un paio di scelte, o accetti che la perdita di dati sia probabile, o codifica il tuo software in modo che la perdita di dati non possa verificarsi.

Se si presuppone che sia necessario conservare i dati in qualsiasi momento, è comunque probabile che si verifichi la possibilità che si verifichi ancora una perdita di dati. Ad esempio, il codice inizia un'operazione di scrittura (ad es .: database, file, ecc.) E prima che l'operazione venga completata, la potenza viene persa. Nulla di ciò che puoi fare senza garantire che l'hardware abbia qualche mezzo per segnalare il tuo software per indicare che l'alimentazione non funzionerà, e quindi fornire abbastanza tempo affinché il tuo software possa commettere qualsiasi cambiamento in qualche tipo di storage. L'altra opzione sarebbe quella di memorizzare tutte le modifiche volatili in un archivio dati ogni volta che qualcosa cambia. Questo potrebbe avere un impatto sulle prestazioni del tuo programma, che probabilmente deve anche essere preso in considerazione. Comunque, questo è un po 'uno scenario eccessivo, ma fattibile se assolutamente necessario.

In definitiva, devi guardare alle tue esigenze e alla progettazione del tuo prodotto. Dovresti davvero ricevere feedback dal cliente anche su tali requisiti. Se la ritenzione dei dati è quasi del 100%, è essenziale progettare il prodotto in modo adeguato e, in caso contrario, non mi preoccuperei molto.

Una volta ho scritto un programma che creava un disco di output. All'utente è stato permesso di creare solo un certo numero di dischi di output. Abbiamo contato il disco quando abbiamo iniziato a scriverci.

L'unica cosa che il QA potrebbe trovare sbagliato era "Se spegni la corrente mentre il programma è in esecuzione, fa la cosa sbagliata."

Ho risposto che avevamo effettivamente considerato tale scenario e abbiamo deciso di contare il disco quando iniziamo a scrivere. In caso contrario, l'utente potrebbe deliberatamente spegnere l'alimentazione durante la scrittura del disco e ottenere un disco gratuito (non assegnato).

Quindi sì, in ogni caso si dovrebbe prendere in considerazione l'interruzione di corrente durante lo sviluppo di un'applicazione. Potresti obiettare che, ehi, si tratta di un'interruzione di corrente, quindi abbiamo fallito, ok? Ma ricorda che l'utente può causare un'interruzione di energia deliberata.

Dipende interamente da ciò che stai scrivendo e da chi lo stai scrivendo

Ho lavorato su cose in cui questo non è solo richiesto, ma fa parte dell'elenco dei requisiti predefiniti per TUTTI i progetti, ho lavorato in posti in cui a loro non interessa affatto, e ho lavorato in posti che considerano puramente un problema di infrastruttura e non un problema per gli sviluppatori, come implicano molte delle altre risposte.

Se stai lavorando su qualcosa che deve avere assoluta integrità transazionale in qualsiasi circostanza, generalmente coinvolge gli sviluppatori in una certa misura, perché ci saranno alcune scelte che sono obbligate a fare in modo che le cose vengano trasferite sul disco piuttosto che scritte in buffer per esempio.

Andy sottolinea il caso più interessante in cui errori insoliti possono essere utilizzati per eludere una politica di sicurezza o di revisione. Ho lavorato su alcuni sistemi che in realtà sono preoccupati anche per questo genere di cose.

Di solito ottieni una delle seguenti risposte a queste domande:

• non importa, prova semplicemente a riavviare il clean (pensa a paint)
• importa poco, non corrompere nulla di storico, ma se perdi dei dati dall'ultimo salvataggio del disco o del backup del log delle transazioni probabilmente stai bene (pensa a Visual Studio)
• importa un bel po ', assicurati di impegnare ogni record su disco e probabilmente in un log prima di passare al passaggio successivo, ottieni anche alcuni UPS decenti e forse un generatore (pensa a transazioni finanziarie)
• è l'unica cosa che conta più della funzionalità, aggiungere funzionalità che bloccano il sistema in modalità fail-safe o fail-safe al primo segnale di interruzione, acquistare ancora più / più grandi UPS e amp; generatore, ottenere un sito di collocazione, utilizzare BGP, ottenere un sito D / R ecc. ecc. (pensare sistemi di sicurezza, backend bancari, ecc.)

Il passaggio dal 3 ° al 4 ° livello è un passo ENORME in molti sistemi, ma l'esempio più semplice che riesco a pensare è in un sistema di sicurezza di accesso fisico: se l'alimentazione è esaurita, e il tuo UPS è in esaurimento. Il 30% del tuo codice deve decidere quali porte bloccare completamente, quali porte sbloccare completamente e dove scaricare gli ascensori prima che la corrente non si guasti completamente.