¿Cuáles son las características o características del código de calidad de producción?

Esta es la primera vez que entregaré código para un proyecto independiente (aplicación web) y, dado que no tengo mucha experiencia en el envío de códigos, me cuesta decidir si mi programa está listo para la implementación o no.

Entiendo que un código de nivel de producción debe tener las siguientes características:

Tolerancia a fallos : capacidad de sobrevivir excepciones no detectadas
Redundancia de datos : nunca pierda los datos del usuario
Escalabilidad : el manejo de la carga adicional no debería requerir volver a escribir la aplicación
Cobertura de prueba : una cantidad "decente" de código probado

Algunas de estas características son específicas del programa en sí, mientras que otras están más relacionadas con el entorno (ya sea que utilicen múltiples clústeres). Sin embargo, incluso las características dependientes del entorno sí afectan la forma en que se diseña el programa.

Mi pregunta es: ¿cuáles son las otras características que hacen que el código de producción sea tan diferente del código que no está destinado a la producción?

Solo para reducir el alcance de la pregunta, concéntrese solo en las aplicaciones web .

Editar : Intentaré reducir el alcance preguntando características específicas de mi situación. Como profesional independiente, era responsable de todo, desde comprar un VPS, hasta configurarlo, escribir el código y desplegarlo. Aunque el proyecto y su configuración están bien documentados, el cliente no podrá mantenerlo. La aplicación no es compleja, pero depende de muchos componentes externos, lo que la hace muy propensa a romperse si estos componentes cambian / desaparecen. El objetivo es establecer un servicio que pueda durar el mayor tiempo posible sin la intervención del cliente.

web-applications freelancing production

— verybadalloc
fuente

La escalabilidad también puede referirse a la capacidad de un sistema para escalar los requisitos. Algunos lo llaman extensibilidad. Tal vez eso merece un punto en tu lista. El hecho es que si no se puede extender fácilmente ... pierde el tiempo haciendo grandes reescrituras solo para agregar una función ... y en algunos casos (no todos) ... no puede cobrar por ese tiempo extra.

— Simon Whitehead

Hay demasiadas respuestas posibles, o las buenas respuestas serían demasiado largas para este formato. Agregue detalles para limitar el conjunto de respuestas o para aislar un problema que puede responderse en unos pocos párrafos.

— mosquito el

¿Cuál es el propósito previsto de su aplicación? ¿Está jugando sonidos de pedos? ¿Está controlando la reentrada de un transbordador espacial?

— el.pescado

"código de calidad de producción" es cualquier otro usuario, que no sea usted, es ...

capaz de usar con o sin soporte mínimo. Si cada acción se encuentra con un error, su software irá a la basura
capaz de entender cómo usar con un mínimo soporte o documentación. Si su usuario no puede entender cómo usar su software, entrará en la basura.
dispuesto a usar porque agrega valor. Si su software agrega suficiente valor, tal vez incluso le darán dinero por ello. Si no agrega suficiente valor para regalarlo gratis, su software irá a la basura.

ESO ES.

Algunas personas necesitan tolerancia absoluta a fallas. A otros no les importa tanto si se pierden algunos datos cuando se produce un bloqueo ... suponiendo que vean fallas con poca frecuencia. No hay cualidades o requisitos establecidos. Y a ningún cliente le importa la cobertura de la prueba, lo que les importa son los tres puntos anteriores. La cobertura de prueba es una herramienta (una de muchas) que puede usar para llegar allí, pero se ha creado una gran cantidad de software, algunos incluso buenos, con nada más que pruebas manuales.

Independientemente del software que cree, los requisitos están entre usted y su cliente y si está creando software para consumo general, elija uno o pocos grupos objetivo y no intente ser todo para todos. Intentar crear algún tipo de molde genérico me parece bastante tonto.

En lugar de tratar de predecir o adivinar cuándo su software estará listo para la producción, ¿por qué no trabaja con su cliente? Déles una vista previa pero explíqueles que no está lista para producción. Publíquelo en su propio servidor y pídales que lo usen, hurguen y den su opinión. Continúa trabajando con ellos hasta que estén contentos con lo que les diste. En otras palabras, le dirán cuándo está lista la producción.

— DXM
fuente

El código de calidad de producción es ese código que satisface los requisitos del cliente, y eso es todo.

— Robert Harvey

@RobertHarvey: esa lista de 3 puntos fue un intento de dar una versión un poco más elaborada de "satisface los requisitos del cliente", claramente no fue un intento muy exitoso, pero sí ... eso es todo

— DXM

@DXM Me gusta la idea de definir "preparación para la producción" con el cliente. Supongo que mi error fue no hacerlo como parte de los requisitos. Sin embargo, ¿qué pasa con los elementos que no se pueden demostrar (recuperación de una falla, por ejemplo)?

— verybadalloc

@verybadalloc, diría que estas definiciones realmente deberían estar en el contrato o SoW en lugar de los requisitos, pero sí defina lo que quiere decir como 'hecho' lo antes posible

— jk.

@verybadalloc: ese desafortunadamente realmente debiste haberlo discutido como parte del contrato. Ahora, si les preguntas, "¿te gustaría tolerar la falla total", la respuesta será afirmativa? Haga los cálculos: P = qué tan probable es que su producto se bloquee; L = cuando falla, qué tan probable es que pierda datos; C = ¿cuánto costaría realmente esa pérdida de datos? (es decir, ¿estamos hablando de una base de datos completa o de los últimos 5 minutos de transacciones? hace la diferencia). P x L x C = valor negativo en su diseño actual. ¿Esto negativo compensaría todos los aspectos positivos que está ofreciendo? Si es así, debes arreglarlo. Si cree que su cliente ...

— DXM