Funzionalità per catturare i bug che arrivano alla produzione

2

Scusa se questo non è il posto giusto per questa domanda, per favore indirizzami altrove se questo è il caso:)

Stavo discutendo con il mio capo che ha esperienza (ma non istruzione ufficiale) in ingegneria del software su un campo membro in un oggetto che indica se l'oggetto è attivo.

Gli oggetti in questione sono creati dai dipendenti (immagina qualcosa come le regole antivirus) che specificano i parametri dell'oggetto, gli attributi e l'obiettivo dell'oggetto.

Questo oggetto viene quindi compilato in un formato binario e distribuito alle installazioni software dei nostri clienti tramite mirror e il programma di aggiornamento del software.

Questo oggetto contiene un campo che indica se è attivo o inattivo, in fase iniziale di progettazione e sviluppo questo è stato aggiunto perché è stato teorizzato che potremmo aver bisogno di spegnere l'oggetto al punto finale della distribuzione.

Gli oggetti sono archiviati in file separati su installazioni software del cliente e spegnere l'oggetto significherebbe scrivere attivamente il file oggetto binario per regolare il campo all'interno. Non c'era un caso d'uso reale previsto per questo campo "attivo" interno, e ai clienti non ci si aspetta che sappiano nulla di questi oggetti. Quindi ci si aspettava che nessuno e niente avrebbero mai spento questi oggetti, specialmente perché si poteva semplicemente cancellare il file per spegnerlo, e gli aggiornamenti del file lo riattivavano indipendentemente dal fatto che lo avessi cancellato o spostato.

L'idea che avremmo avuto bisogno di commutare l'oggetto sull'endpoint è stata rapidamente ignorata perché l'interfaccia ha raggiunto il completamento ed è connessa a un database che ospita gli oggetti e se ogni oggetto è attivo o inattivo.

L'interfaccia semplicemente non sposterà l'oggetto per la distribuzione se è elencato come inattivo nel database, è un meccanismo molto semplice.

Ora procediamo velocemente alla nostra conversazione discutendo lo scopo di questo campo nel file oggetto compilato.

Ho affermato che potremmo semplicemente rimuovere il campo dall'oggetto compilato perché se l'oggetto viene eliminato, deve comunque essere abilitato nell'interfaccia.

Il mio capo ha detto che sto assumendo che i programmatori UI non commettano errori e che avere la seconda linea di difesa possa impedire l'uso di un oggetto che non è stato progettato per essere espulso ma è stato spinto in qualche modo per errore.

Ho detto che non ho considerato gli 'errori degli sviluppatori' come una ragione per implementare una funzione (principalmente in questo caso) e che gli errori dovrebbero generalmente essere scoperti test / debug / QA e non hanno funzionato con funzionalità secondarie.

Dopo tutto, sarebbe l'interfaccia che popola comunque il campo "attivo" dell'oggetto compilato, quindi se l'interfaccia spinge erroneamente fuori un oggetto che non dovrebbe essere attivo c'è una grande possibilità che l'oggetto compilato sarebbe indica anche che era attivo nel campo interno perché l'interfaccia popolava quel campo. (A meno che il bug non sia altrove come il confronto dell'interfaccia del campo attivo)

Il mio capo ha detto "non pensarlo come una" caratteristica "ma come una sicurezza", mentre suggerisco anche che la mia posizione in merito era ingenua e che la frase "gli errori dovrebbero essere presi dal test / debug / QA" non è certamente è vero nel mondo reale.

In fin dei conti questo è un problema così piccolo che non sto cercando di discutere se il campo è conservato o meno, sono solo curioso del principio della posizione presa nella discussione dal mio capo e sono curioso di sapere quale altro professionisti del settore hanno da dire su questo.

Il mio ragionamento per questo approccio errato è:

Se si presume che testing / debug / QA non riesca a catturare anche i bachi più semplici e che si debbano codificare in funzionalità extra per proteggersi da questi semplici bug - non è indicativo che ci sia un problema più profondo nello sviluppo processo?

Inoltre, se devi codificare funzionalità extra per proteggerti dai bug, cosa succede se queste caratteristiche extra hanno dei bug? Programmate ancora più funzionalità extra per proteggervi da possibili bug nelle funzionalità che proteggono dagli errori?

    
posta user6567423 20.12.2018 - 23:28
fonte

3 risposte

5

Chiedi:

If you assume that testing/debugging/QA cannot catch even the simplest of bugs, and that you must code in extra features to protect against these simple bugs -- isn't that indicative that there is a deeper issue in the development process?

Chi sta suggerendo che questi processi o persone "non riescano a cogliere nemmeno il più semplice dei bug?" Sembra un uomo di paglia che non è stato allevato dal tuo capo. Ho visto bug estremamente semplici superare molti livelli di test di alta qualità e spedizione. Succede sicuramente, e non è perché le persone sono incompetenti o i processi sono inutili. È perché il software è estremamente complesso e letteralmente non c'è abbastanza tempo nella vita dell'universo per coprire anche solo una minima parte dei possibili input che un programma può avere.

Furthermore, if you have to code in extra features to protect against bugs, what if those extra features have bugs? Do you program in even more extra features to protect against possible bugs in the features that protect against bugs?

Sembra un argomento di pendenza scivolosa. Possiamo anche portarlo nella direzione opposta. Se la codifica di funzionalità aggiuntive per proteggere o trovare bug non funziona, può funzionare anche la funzionalità di codifica normale? Il software può funzionare a tutti?

Ovviamente la risposta è che sì, il software può funzionare, i test possono funzionare e le pratiche di programmazione difensive possono funzionare. Ma non sono perfetti e non lo saranno mai. Devi trovare il giusto equilibrio tra queste cose in modo da poter rimanere in attività e svolgere un compito che gli utenti hanno bisogno di realizzare. A volte ciò significa scrivere codice subottimale o utilizzare una soluzione grossolana per ottenere qualcosa fuori dalla porta.

Ci sono diversi modi per automatizzare parti di queste attività per migliorare le possibilità di trovare bug e per impedire che il codice regredisca e che vengano visualizzati nuovamente bug corretti in precedenza. Se non li stai già utilizzando, dovresti esaminare gli avvisi del compilatore, l'analisi statica del codice, lo sviluppo basato su test e altre tecniche automatizzate. Sono un grande complimento per i test manuali e sono spesso poco costosi da implementare.

    
risposta data 21.12.2018 - 05:31
fonte
4

Mi sono perso un po 'nel dettaglio dei tuoi dettagli particolari, ma ho trovato alcune domande interessanti lì dentro:

If you assume that testing/debugging/QA cannot catch even the simplest of bugs, and that you must code in extra features to protect against these simple bugs -- isn't that indicative that there is a deeper issue in the development process?

Non so di semplici bachi ma sicuramente alcuni bug vengono spediti nel mio campo che riescono a volare sotto il radar di unità e test di integrazione e QA, sfortunatamente ea volte anche test interni (spero che questo non capita così spesso alla NASA.

Nel mio caso la protezione più preziosa contro di essa è la registrazione. In realtà non è necessario il logging come caratteristica, tranne che per il solo scopo di aiutarci a restringere i bug che purtroppo sono riusciti a spedire perché non è pratico aspettarsi di poter eseguire i debugger sulla macchina dell'utente. La nostra procedura di test è ragionevolmente stretta, ma il logger è stato un vero toccasana per aiutarci a limitare i problemi di incompatibilità hardware che a volte si verificano in modi che nessuno in tutto il nostro team può riprodurre dal momento che realizziamo qualche cosa di avanguardia con SIMD e gli shader della GPU (che tende anche ad essere dove troviamo la maggior parte dei bug che sono riusciti a spedire, anche se a volte è stato perché gli utenti non hanno letto i nostri requisiti minimi di hardware ma abbiamo almeno scoperto che non li abbiamo rilevati correttamente nel software).

Furthermore, if you have to code in extra features to protect against bugs, what if those extra features have bugs? Do you program in even more extra features to protect against possible bugs in the features that protect against bugs?

Se torno alla registrazione come esempio, è una difesa di ultima istanza. Se, in qualche modo, il nostro logging è anche fubar (anche se lo testiamo fino ad un certo punto), allora siamo tipo di SOL in questi casi se gli utenti incontrano un bug che è riuscito a spedire (potremmo doverli mandare una build con fixed registrando solo per restringerlo). Ma come ultimo baluardo di difesa, è riuscito a resistere piuttosto bene. Detto questo, in realtà lo usiamo e lo testiamo fino ad un certo punto, oltre a guardarlo di tanto in tanto solo per vedere cosa ha fatto tutto il programma in modi diversi dal debugging.

Ora la difesa di ultima istanza è diversa dai bug nascosti. Ho visto un codice orribile come questo:

// Pre-condition foo should never be null:
void do_something(Foo* foo)
{
     if (!foo)
          return;
     ...
}

Che è assolutamente orribile dato che non sta nemmeno generando un errore. Sfortunatamente ho lavorato in una squadra anni prima quando ero più giovane, dove gli sviluppatori senior pensavano che fosse una buona pratica, e hanno fatto questa idea mitica che un programmatore che aggiusta bug crea due nuovi bug in qualcosa di una realtà con il modo in cui "riparavano" bug. Ma è molto diverso da qualcosa come la registrazione. Quello che stavano facendo era deliberatamente nascondere (al contrario di correggere) bug. A volte ho un lato odioso e polemico che darei la colpa all'esperienza di essere in quella squadra. :-D

Nel tuo caso non conosco la sfumatura ei dettagli per giudicare quanto sia stupido (o meno) l'argomento del tuo capo per avere alcune funzioni di sicurezza per disattivare / disabilitare questi oggetti. Ma cerco solo di ricordare che si tratta di fare soldi e gestire un'impresa e se questa cosa sta causando problemi di produttività per te, di parlarne in questo modo piuttosto che affrontarla in termini di "correttezza" o "pratica ottimale" ", perché penso che i capi si relazioneranno a questo di più. Ma sai, ci sono un sacco di cose da fare come ragazze carine che sono ragazzi fantastici o di bell'aspetto (come me per le donne), e ho trovato utile nel corso degli anni affogarci un po 'per le cose che potrebbero essere contestate a meno che non sia davvero, davvero come farti finire il tuo lavoro.

    
risposta data 21.12.2018 - 02:54
fonte
0

Non sono sicuro di aver capito esattamente il tuo problema specifico, ma il tema generale in sé è molto comune - con una serie di aspetti.

Requisiti

Senza obiettivi chiari, documentati e concordati, la funzione di qualsiasi sistema è in palio. In assenza di requisiti, è probabile che ci sia un lotto di divergenze di opinioni su come un sistema dovrebbe funzionare con i membri più anziani del personale che sono in grado di far valere la loro opinione se è per il buono della base di codice o no.

La spirale del processo

Quando una procedura manuale va storta, la reazione del jerk è di aggiungere ancora un altro processo per controllare il primo. Questa è una commissione ingannevole perché ora hai due cose che possono andare storte così come l'intero processo che richiede più tempo a causa di maggiori controlli e misure.

Questo non vuol dire che dovrebbe succedere mai per le funzioni critiche, ma certamente non dovrebbe essere considerato un proiettile d'argento che può essere distribuito ovunque.

Il processo di business

Esiste il concetto (soprattutto nella gestione) che il software dovrebbe semplicemente scorrere, non mostrare errori, aiutare l'utente ed essere intuitivo. A volte queste richieste irrealistiche sono ortogonali ai requisiti stessi. Un sacco di tempo di sviluppo può essere speso qui se queste aspirazioni nobili non vanno deselezionate.

Dato dove sei, ho il sospetto che i requisiti documentati manchino, ma questo non dovrebbe impedirti di iniziare subito con questo. Sareste stupiti di quante nuove funzionalità critiche cadano nel dimenticatoio quando chiedete ai poteri di essere pienamente documentati e giustificare le modifiche al software. Molti manager (per quanto riguarda il software) lo utilizzano spesso perché non capiscono il codice base e gli sviluppatori.

    
risposta data 21.12.2018 - 11:34
fonte

Leggi altre domande sui tag