design - studio - support library features android
¿Cómo se equilibran las necesidades conflictivas de compatibilidad con versiones anteriores e innovación? (4)
Trabajo en una aplicación que tiene una interfaz GUI (gráfica) y API (scripting). Nuestro producto tiene una base instalada muy grande. Muchos clientes han invertido mucho tiempo y esfuerzo en escribir guiones que usen nuestro producto.
En todos nuestros diseños e implementación, (comprensiblemente) tenemos un requisito muy estricto para mantener el 100% de compatibilidad con versiones anteriores . Una secuencia de comandos que se ejecutó antes debe continuar ejecutándose exactamente de la misma manera, sin ninguna modificación, cuando presentamos una nueva versión de software.
Desafortunadamente, este requisito a veces nos ata las manos a la espalda, ya que realmente restringe nuestra capacidad de innovar y crear nuevas y mejores formas de hacer las cosas.
Por ejemplo, podríamos encontrar una forma mejor (y más útil) de lograr una tarea que ya es posible. Sería deseable mejorar esta forma de la manera predeterminada, pero no podemos hacer esto, ya que puede tener implicaciones de compatibilidad con versiones anteriores. Por lo tanto, estamos obligados a dejar la nueva (mejor) forma como un modo, que el usuario debe "encender" antes de que esté disponible para ellos. A menos que lean la documentación o la ayuda en línea (que muchos clientes no hacen), esta nueva funcionalidad permanecerá oculta para siempre.
Sé que Windows Vista molestó a mucha gente cuando salió por primera vez, debido a todo el software y los periféricos que no funcionaban en él, incluso cuando trabajaban en XP. Recibió una muy mala recepción debido a esto. Pero se puede ver que Microsoft también ha tenido éxito en hacer algunas grandes innovaciones en Vista, a expensas de la compatibilidad con versiones anteriores para muchos usuarios. Ellos se arriesgaron. ¿Pagó? ¿Tomaron la decisión correcta? Supongo que sólo el tiempo dirá.
¿Se encuentra equilibrando las necesidades conflictivas de innovación y compatibilidad con versiones anteriores? ¿Cómo manejas el acto de malabarismo?
Dividir el desarrollo en dos ramas, una que mantiene la compatibilidad hacia atrás y otra para una nueva versión principal, en la que deja en claro que se está rompiendo la compatibilidad con versiones anteriores.
En lo que se refiere a mi experiencia en programación, si voy a cambiar de manera fundamental algo que evitará que los datos entrantes pasados se usen correctamente, necesito crear una capa de abstracción para los datos antiguos donde se pueda convertir para usar en el nuevo formato.
Básicamente configuré el modo "mejorado" como predeterminado y me aseguro de que a través de un convertidor pueda leer datos del formato antiguo, pero guardar o almacenar datos como el nuevo formato.
Creo que lo más importante aquí es prueba, prueba, prueba. La compatibilidad hacia atrás no debe obstaculizar el progreso hacia adelante.
Eso es solo mi 2c
La pregunta crítica que debe hacerse es si los clientes quieren / necesitan esta "mejora", incluso si la perciben como una que sus clientes tal vez no lo necesiten. Una vez que se ha establecido una cierta forma de hacer las cosas, cambiar el flujo de trabajo es una operación muy "costosa". Dependiendo de la capacidad de la computadora de sus usuarios, puede llevar bastante tiempo ajustarse al cambio en la IU.
Si está tratando con clientes, la innovación por el bien de la innovación no siempre es tan divertido como lo sería para usted desarrollar estas mejoras.
Podrían buscar maneras innovadoras de mantener la compatibilidad hacia atrás.