Mejores prácticas para la compatibilidad heredada

Question

Según mi experiencia, los compromisos con la compatibilidad hacia atrás/adelante son los gilded cage de la industria de ingeniería de software. Particularmente he observado que este es el caso de los formatos de archivo de documentos y los lenguajes de programación/API. Los clientes y socios lo odian cuando se rompen sus datos o códigos existentes; Sin embargo, si nunca se rompe la compatibilidad, puede limitar seriamente su capacidad de innovar a largo plazo.

¿Existen soluciones a este problema, aparte de la desaprobación gradual de las funciones anteriores? Parece que la virtualización, como en el modo XP de Windows 7, es una posibilidad emocionante. ¿Hay otros?

Además, para aquellos de nosotros que deseamos diseñar nuevos sistemas que sean tan resistentes al futuro como sea posible, ¿qué lecciones podemos aprender de los errores del pasado realizados en la industria?

Answer 1

Innovar mediante la extensión, no reescribiendo las API públicas. Tener interfaces públicas genéricas consistentes con la funcionalidad de back-end. Puede reescribir los módulos privados en cualquier momento, siempre que suministre a los módulos API públicos los resultados que esperan.

Haga sus mejoras en el back-end y deje la API constante tanto como sea posible. Cree nuevos módulos y documentelos claramente al extender las partes públicas de su API, desaprovechando las viejas formas vendrá naturalmente si proporciona nuevas y mejores formas de hacer cosas que vienen como adiciones a las viejas formas.

Para formatos de documentos, siempre incluya los números de versión y asegúrese de que tiene formas de admitir todas las versiones existentes. Al igual que con las API, agregue la nueva funcionalidad extendiéndola, no reescribiéndola.

Cuando desee llevar a cabo cambios fundamentales en la arquitectura general de su software, haga que la nueva versión incluya la anterior como módulo; esto dará como resultado un mayor tamaño pero una mejor compatibilidad con datos y programas anteriores.

Answer 2

Utilice XML como base para su formato de archivo, y solo agréguelo a la especificación DTD, no lo elimine. De esta manera, sus archivos deberían ser compatibles con versiones anteriores, lo que es un plus.

Answer 3

He aquí un buen ejemplo: usar SLF4J Bridges para permitir la migración fácil de un módulo de registro a otro en Java.