¿Cuánto tiempo y esfuerzo debe gastar un proyecto en compatibilidad con versiones anteriores?

Question

Dado que cada proyecto de software solo tiene tantas horas de programador dedicadas a él, ¿cuánto gastaría para asegurarse de que el producto sea compatible con versiones anteriores? En realidad, hay varios puntos a considerar:

• ¿La antigüedad del software afecta su decisión? ¿Invertirá menos tiempo en compatibilidad con versiones anteriores cuando el programa sea más nuevo?
• ¿La decisión se basa únicamente en la cantidad de clientes con copias instaladas?
• ¿Hace un esfuerzo activo para producir código y formatos de archivo que admitan cambios futuros?
• Cuando está desarrollando v1.0, ¿intenta construir para que sea más fácil para v2.0 ser compatible con v1.0? (Salir de los campos "reservados" es un ejemplo.)
• ¿Cómo decide que "No, no vamos a admitir eso más" en las funciones?

Answer 1

La base del cliente es clave para determinar si debe admitir o no un gran problema de compatibilidad con versiones anteriores.

Básicamente, es necesario evaluar que al igual que cualquier otro requisitos no funcionales que necesita para implementar, y es necesario que especifique cuidadosamente lo que está incluido en un "backward compatibility" feature: Compatibilidad

• API. Esto significa que las versiones posteriores de una biblioteca proporcionan la misma API que las versiones anteriores, por lo que los programas escritos con la versión anterior aún podrán compilarse y ejecutarse con la nueva versión. Además de dejar realmente las mismas funciones, esto también implica que esas funciones hacen lo mismo en la versión más nueva que en las versiones anteriores
• Application Binary Interface, o ABI, compatibilidad. Esto significa que la compatibilidad con versiones anteriores se conserva en el nivel del código objeto binario producido cuando compila la biblioteca.
  Generalmente existe cierta superposición entre la compatibilidad API y ABI, pero existen diferencias importantes.Para mantener la compatibilidad ABI, todo lo que tiene que hacer es asegurarse de que su programa exporte todos los mismos símbolos.
  Esto significa que deben estar presentes todas las mismas funciones y objetos accesibles a nivel mundial, de modo que los programas vinculados con la versión anterior aún puedan ejecutarse con la nueva versión.
  Es posible mantener la compatibilidad ABI mientras se rompe la compatibilidad de la API. En el código C, deje símbolos en los archivos C pero elimínelos de los encabezados públicos, de modo que el nuevo código que intente acceder a los símbolos no compile, mientras que el código anterior que los usuarios compilaron contra la versión anterior continuarán ejecutándose
• compatibilidad del protocolo cliente-servidor. Esto significa que un cliente que use la versión del protocolo de red proporcionado en las versiones anteriores continuará funcionando cuando se enfrente a un servidor más nuevo, y que los programas cliente más nuevos continuarán funcionando con un servidor anterior.
• compatibilidad de formato de datos. Las versiones más nuevas del código deben poder trabajar con archivos de datos escritos por versiones anteriores, y viceversa. Idealmente, también debería ser capaz de construir compatibilidad hacia adelante en formatos de datos. Si las rutinas de manejo de archivos pueden ignorar y preservar los campos no reconocidos, la nueva funcionalidad puede modificar los formatos de datos de forma que no rompa las versiones anteriores. Este es uno de los tipos más críticos de compatibilidad, simplemente porque los usuarios se molestan mucho cuando instalan una nueva versión de un programa y de repente no pueden acceder a sus datos anteriores.

Si se combinan los criterios anteriores (la naturaleza de la compatibilidad con versiones anteriores) con la naturaleza de su base de clientes, puede decidir que:

• Si sus clientes son internos a su empresa, la necesidad es más bajo, y 2.0 puede romper funciones significativas.

• Si sus clientes son externos, un 2.0 todavía se puede romper cosas, pero puede que tenga que provide migration guide

• En el otro extremo, si sus clientes son los de todo el mundo, como ya mencionado en este SO question about java , ¡puedes terminar proporcionando nuevas funcionalidades sin desaprobar las antiguas! O incluso preserving BUGS of your old products, ¡porque las aplicaciones del cliente dependen de esos errores!

---

• ¿La edad del software afecta a su decisión? ¿Invertirá menos tiempo en compatibilidad con versiones anteriores cuando el programa sea más nuevo?
  Creo que esto tiene que ver con lo que ya está implementado: un programa reciente tendrá que lidiar con menos necesidades de compatibilidad hacia atrás que uno que está alrededor de los 20 años.

• ¿La decisión se basa únicamente en el número de clientes con copias instaladas?
  Debe basarse en un caso comercial: ¿su migración, si es necesaria debido a la falta de compatibilidad con versiones anteriores, puede "venderse" de manera efectiva a sus clientes (debido a todas las nuevas funciones brillantes que trae?)

• ¿Hace un esfuerzo activo para producir código y formatos de archivo que admitan cambios futuros?
  Intentar predecir el "cambio futuro" puede ser muy contraproducente y rápidamente estar al borde de YAGNI (No lo va a necesitar): un buen conjunto de herramientas de migración puede ser mucho más efectivo.

• Cuando está desarrollando v1.0, ¿intenta construir para que sea más fácil para v2.0 ser compatible con v1.0? (Salir de los campos "reservados" es un ejemplo.)
  Para las aplicaciones internas en las que he trabajado, no. Un Parallel Run es nuestra manera de garantizar una compatibilidad hacia atrás "funcional". Pero esa no es una solución universal.

• ¿Cómo decide que "No, ya no vamos a admitir eso" en las funciones?
  Una vez más, para las aplicaciones internas, el proceso de decisión puede ser muy diferente al de una implementación externa. Si una característica no aporta ningún valor agregado para la empresa, se establece una tarea interna de "coherencia" para verificar con cada otra aplicación interna el costo de su migración (es decir, "no usar más esta función"). La misma tarea es mucho más difícil de hacer con clientes externos a su organización.

Answer 2

Mi opinión sobre la compatibilidad del software:

1.) Si es un producto ampliamente utilizado ya por muchos clientes, entonces se aseguraría de que la nueva versión de este producto sigue utilizando el mismo " código base "(Código que logra la funcionalidad básica de la aplicación en desarrollo). Las nuevas características deben tenerse en cuenta en esta base de código o construirse sobre esta base de código con el mínimo cambio necesario en el entorno de ejecución de esta aplicación como sea posible. No desea que sus usuarios actuales realicen muchos cambios en sus instalaciones existentes. Por lo tanto, se trata de una solución de compromiso entre la compatibilidad con una nueva funcionalidad y la renovación de la configuración existente y el proceso de uso para el cliente.

2.) En un nuevo producto, si es posible, identifique todas las características posibles de esa aplicación desde el principio, incluso antes de que v1.0 esté fuera. Identifique qué características va a enviar en v1.0. y cuáles se guardarían para lanzamientos posteriores. Siempre que sea posible, tenga en cuenta estas "funciones posteriores" mientras diseña, implementa el código, finaliza la salida desde/de la aplicación para acomodar características en futuras versiones. p.ej. Deje elementos/campos de bits adicionales en sus estructuras de datos.

-AD.

Answer 3

Mucho. ¡Si no quieres cabrear a todos tus clientes leales!

Answer 4

Cuanto más se usa su sistema día a día, más debe centrarse en él.

Cuanto más integrado esté su sistema en los procesos centrales de sus clientes, más debe centrarse en él.

Cuanto más competencia tenga tu sistema, más deberías concentrarte en él.

Cuantos más usuarios usan versiones anteriores, más debe centrarse en ellas.

Cuanto más compleja y profunda es la aceptación para un cliente de su sistema, en términos de qué tan grande es el impacto que su software tiene en su negocio, más debe centrarse en la compatibilidad con versiones anteriores.

Si no puede ayudarlos con las nuevas versiones a través de precios atractivos, etc., podría valer la pena considerar el riesgo de forzar a todos.

Me gusta Vista, u Office 2007. Fue fantástico ayudarme a Apple.

Answer 5

Mi experiencia es con sistemas de envoltura compleja con relativamente pocos (100 - 5000) usuarios.
El marketing a menudo tiene que tener una actitud hacia la compatibilidad hacia atrás sin una apreciación completa de los costos del ciclo de vida. Por ejemplo, los ahorros para mantener los errores en su sistema para la base de usuarios actual pueden empequeñecerse fácilmente por los costos de soporte para los nuevos usuarios durante la vida útil del sistema.