He visto muchas API que enumeran los detalles sobre problemas conocidos. Si hay problemas conocidos, ¿por qué publicarlo en público antes de solucionarlo?Si hay "problemas conocidos" ¿por qué liberarlos?
¿Cuál es el motivo? ¿Líneas muertas? ¿O arreglar eso puede romper algo más?
Nota: No estoy seguro de si esta pregunta pertenece aquí. Así que siéntete libre de cerrar si esta no es una pregunta válida.
El software no es perfecto y esperar hasta que se solucione cada problema para liberar algo dará como resultado un mundo sin software.
Exactamente a la derecha. –
Bueno, yo no llegaría tan lejos. Hay muchas buenas razones para lanzar un software que tiene problemas conocidos, pero ser flojo en general y decir que todo el software tiene errores no es uno de ellos. Si bien es cierto que casi todos los software tienen errores, eso debería verse como un PROBLEMA con el estado de la ingeniería de software en esta época, y no es una conclusión inevitable. –
¿Ve usted como un problema que cada edificio que se haya construido tenga fallas e imperfecciones, grietas y estructuras desalineadas? La verdad es que es virtualmente imposible escribir software de cualquier tamaño significativo que no tenga fallas. Existe una gran diferencia entre "técnicamente factible" y "comercialmente viable". –
La razón principal es el tiempo de comercialización
Problemas conocidos a menudo afectan a un pequeño número de usuarios, y todos los demás podían realmente utilizar las mejoras en la nueva versión. Además, pueden existir los mismos problemas con la versión existente, en cuyo caso, no se le están dando nuevos errores (conocidos) a los usuarios. Entonces, realmente es una victoria.
Algunos problemas también pueden tardar mucho tiempo en solucionarse.
Porque el software es útil y útil, incluso con los problemas, y porque los usuarios preferirían tenerlo antes de esperar el lanzamiento. Debido a que sus desarrolladores quieren la retroalimentación que proporcionará la publicación anticipada.
Hay siempre problemas conocidos. Si no lo liberas hasta que no haya más problemas conocidos, nunca lo liberarás. A veces es mejor obtener una versión que funcione en su mayoría con advertencias sobre algunos problemas no críticos.
Muchas veces el software más nuevo es aún mejor que las versiones disponibles anteriormente, incluso con los problemas conocidos. Especialmente cuando se trata de bibliotecas, los clientes a menudo preferirían tener el código entregado antes que el que tiene problemas que esperar a que se resuelvan los problemas que no les importa.
A veces, el beneficio de liberar algo que funciona es más importante que los problemas que solo afectarán a algunos usuarios.
Los errores pueden ser menores o crítica: S
A veces simplemente no puede solucionar esos problemas.
Imagine que tiene un script JS y algunos errores en un navegador que no puede evitar. Entonces no lanzarías tu biblioteca hasta que ese navegador sea reparado, ¿o sí? O simplemente podría agregar una nota de "problemas conocidos" sobre un problema del navegador y liberarlo.
Beneficio.
El software del mundo real de cualquier complejidad nunca será perfecto. Sin embargo, hay un cierto punto en el que es "lo suficientemente bueno", y es entonces cuando es hora de enviar.
Los debates reales suceden al decidir qué nivel de calidad se encuentra con la barra "lo suficientemente buena".
Si tiene poco impacto (afecta a pocos usuarios o tal vez es interno), entonces esa es probablemente una de las razones. Otros pueden ser grandes pelucas que desean cosas y en el mercado lo antes posible, por lo que a veces las cosas deben quedar incompletas en función de una serie de factores.
Especialmente con proyectos de fuente abierta, esto permite que la mayoría de los usuarios obtengan el producto sin problemas y también crea conciencia de los errores para que los usuarios puedan contribuir al código.
De lo contrario, nunca se liberaría.
Los problemas conocidos están bien. Es el desconocido problemas que causan el problema.
Si un problema conocido solo afecta a un pequeño porcentaje de usuarios potenciales, entonces probablemente valga la pena liberarlo.
Una API es un contrato entre el implementador de la API y el programador que usa la API. Incluso si la implementación tiene problemas conocidos, es bueno publicar la documentación de API, para que los programadores puedan comenzar a desarrollar código que pueda aprovechar la API. Se entiende que el proveedor de la implementación cumplirá (eventualmente) su parte del contrato, lo que hará que la implementación cumpla plenamente con la API. Si la API solo se lanzara cuando la implementación fuera perfecta, los desarrolladores de la aplicación se verían obligados a perder una gran cantidad de tiempo de desarrollo en el que podrían ser productivos, incluso si estuviera basado solo en los documentos API, y no podrían en realidad prueba el código todavía.
Porque el software es estable. Si hay algunos problemas conocidos que no afectan directamente el uso diario del software y que pueden corregirse en parches, ¿por qué no liberarlos?
Además, hay plazos y costos a considerar, pero obviamente esto último no se aplica realmente a Open Source.
"Compromiso".
Eso es más importante.
Una vez que la fecha de entrega finaliza (Comprometida), el producto debe ser liberado si está en el nivel "Aceptable". La diferencia entre "la perfección" y "aceptación" es "Problemas conocidos"
La mayoría de las empresas tienen unos criterios de liberación que puede lucir de como-
liberación de software podría tener algunos errores menores cuyo recuento se establece en un límite - Tales problemas pueden ser problemas menores de UI.
El lanzamiento del software puede tener algunos errores importantes cuyo conteo se establece en un límite: se intenta liberar el parche de dichos errores, pero si aún escapan (debido a razones diferentes) no deberían romper el producto y hay algo de trabajo disponible para evitarlos.
La versión de software no debería tener ningún error crítico: el software no se enviaría si se encuentra algún error crítico. Estos errores rompen el producto sin soluciones entretenidas en absoluto.
De nuevo, las clasificaciones mencionadas anteriormente pueden estar fuera del objetivo y depende de la compañía y sus procesos involucrados.
aplausos
ver los beneficios de la pronta liberación/liberación menudo la política, por ejemplo, los valiosos comentarios de tus usuarios.
El tiempo y la marea no esperan a nadie. – maxaposteriori
$$$$$$$$$$$$$$$$$$$$$$$$ – Troggy
Como elegir un compañero: cuando es perfecto, es demasiado tarde – peterchen