Ho visto molte API che elencano i dettagli sui problemi noti? Se ci sono problemi noti perché renderli pubblici prima di risolverli?Se ci sono "problemi noti" perché rilasciare?
Qual è il motivo? Linee morte? O riparando che può rompere qualcos'altro?
Nota: non sono sicuro che questa domanda appartenga qui. Quindi sentiti libero di chiudere se questa non è una domanda valida.
Il software non è perfetto e in attesa che ogni problema venga risolto per rilasciare qualcosa si tradurrà in un mondo senza software.
Esattamente a destra. –
Beh, non andrei così lontano. Ci sono molti buoni motivi per rilasciare software che hanno problemi noti, ma essere generalmente pigri e dire che tutto il software ha dei bug non è uno di questi. Anche se è vero che quasi tutti i software hanno dei bug, questo dovrebbe essere visto come un PROBLEMA con lo stato dell'ingegneria del software in questo giorno ed età, e non una conclusione scontata. –
Lo vedi come un problema che ogni edificio mai costruito presenta difetti e imperfezioni, crepe e strutture disallineate? La verità è che è praticamente impossibile scrivere software di qualsiasi dimensione significativa che non ha difetti. C'è una grande differenza tra "tecnicamente fattibile" e "commercialmente fattibile". –
Il motivo principale è il time to market
Problemi noti spesso colpiscono un numero limitato di utenti, e tutti gli altri potrebbe davvero utilizzare i miglioramenti nella nuova versione. Inoltre, gli stessi problemi possono esistere con la versione esistente, nel qual caso, non vengono forniti nuovi (noti) bug agli utenti. Quindi, è davvero una vittoria.
Alcuni problemi potrebbero richiedere molto tempo per essere risolti.
Perché il software è utilizzabile e utile, anche con i problemi, e perché gli utenti preferirebbero averlo prima di attendere il rilascio. Perché i suoi sviluppatori vogliono il feedback che lo rilascerà presto.
Ci sono sempre problemi noti. Se non si rilascia fino a quando non ci sono più problemi noti, non si rilascerà mai. A volte è meglio avere una versione per lo più funzionante fuori porta con avvertimenti su alcuni problemi non critici.
Spesso il software più recente è ancora migliore delle versioni precedenti, anche con i problemi noti. Soprattutto quando si ha a che fare con le librerie, i clienti preferirebbero avere il codice consegnato prima che abbia problemi piuttosto che attendere i problemi che non si preoccupano di correggere.
A volte il vantaggio di rilasciare qualcosa che funziona è più importante dei problemi che solo alcuni utenti saranno colpiti.
bug possono essere minori o critico: S
A volte non si può risolvere questi problemi.
Immagina di avere uno script JS e qualche bug in un browser che non puoi evitare. Quindi non rilasceresti la tua libreria fino a quando il browser non verrà risolto, vero? O potresti semplicemente aggiungere una nota sui "problemi noti" su un problema del browser e rilasciarlo.
Utile.
Il software del mondo reale di qualsiasi complessità non sarà mai perfetto. C'è un certo punto in cui è "abbastanza buono", tuttavia, ed è quando è il momento di spedire.
I veri dibattiti si verificano quando si decide quale livello di qualità incontra la barra "abbastanza buono".
Se l'impatto è basso (interessa solo pochi utenti o forse è interno), probabilmente questo è un motivo. Altri potrebbero essere big-wigs che vogliono uscire e sul mercato al più presto, quindi a volte le cose devono essere lasciate incomplete sulla base di una serie di fattori.
Soprattutto con progetti open-source, questo consente alla maggior parte degli utenti di ottenere il prodotto senza problemi e aumenta anche la consapevolezza dei bug in modo che gli utenti possano contribuire al codice.
Altrimenti non avresti mai rilasciato.
I problemi noti vanno bene. Sono i problemi sconosciuti che causano il problema.
Se un problema noto interessa solo una piccola percentuale di potenziali utenti, allora probabilmente vale la pena di essere rilasciato.
Un'API è un contratto tra l'implementatore dell'API e il programmatore che utilizza l'API. Anche se l'implementazione ha problemi noti, è opportuno rilasciare la documentazione dell'API, in modo che i programmatori possano iniziare a sviluppare codice in grado di sfruttare l'API. Resta inteso che il fornitore dell'implementazione (alla fine) adempierà alla fine del contratto, portando l'implementazione in piena conformità con l'API. Se l'API fosse stata rilasciata solo quando l'implementazione era perfetta, gli sviluppatori di applicazioni sarebbero stati costretti a sprecare un'enorme quantità di tempo di sviluppo in cui potrebbero essere produttivi, anche se era basato esclusivamente sui documenti API e non potevano effettivamente testare il codice ancora.
Perché il software è stabile. Se ci sono alcuni problemi noti che non influiscono direttamente sull'uso quotidiano del software e che possono essere corretti nelle patch, perché non rilasciarlo?
Inoltre ci sono scadenze e costi da considerare, ma ovviamente quest'ultimo non si applica realmente all'Open Source.
"impegno".
Questo è più importante.
Una volta finalizzata la data di consegna (commit), il prodotto deve essere rilasciato se è in livello "Accettabile". La differenza tra "La perfezione" e "accettazione" è "Problemi noti"
La maggior parte delle aziende hanno un criterio di rilascio che potrebbe apparire come-
rilascio del software potrebbero avere alcuni bug minori il cui conteggio è impostato su un limite - Tali problemi potrebbero essere problemi minori dell'interfaccia utente.
La versione del software può presentare alcuni bug importanti il cui conteggio è impostato su un limite. Vengono fatti tentativi per rendere la versione esente da tali errori ma se non riescono a scappare (a causa di motivi diversi), non dovrebbero rompere il prodotto e c'è un po 'di lavoro disponibile per aggirarli.
La versione del software non dovrebbe presentare bug critici. Il software non verrà spedito se viene rilevato un errore critico. Tali bug rompono il prodotto senza alcun intralcio di sorta.
Anche in questo caso le classificazioni di cui sopra potrebbero essere fuori bersaglio e dipendono dalla società e dai relativi processi coinvolti.
applausi
Vedi i vantaggi della liberazione anticipata/release spesso la politica, per esempio il feedback inestimabile dei tuoi utenti.
Il tempo e la marea non aspettano nessuno. – maxaposteriori
$$$$$$$$$$$$$$$$$$$$$$$$ – Troggy
Come scegliere un partner - quando perfetto, è troppo tardi – peterchen