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?