Pregunta

Cuando está considerando una actualización en una herramienta de desarrollo, ¿qué importancia tiene para usted la compatibilidad con versiones anteriores? ¿Seguiría comprando Visual Studio 2010 si requiriera cambios significativos en su código fuente? ¿Dónde está el punto de inflexión para usted en términos de intercambio de compatibilidad con versiones anteriores para nuevas características?

¿Fue útil?

Solución

Si bien preguntaste esto desde el punto de vista del desarrollador, creo que sería una pregunta más interesante en referencia al software que desarrollas. Entonces voy a responder esa pregunta en su lugar. :)

El hardware y el software que es compatible con versiones anteriores (y, lo que es más importante, compatible con el futuro) proporciona una sensación de seguridad a sus usuarios, especialmente al comprar o actualizar plataformas como Windows. Por lo menos, Windows es conocido por su meticulosa atención a la compatibilidad con versiones anteriores. Puede ejecutar programas escritos hace más de una década en Windows Vista con problemas menores, siempre que estén bien escritos. (es decir, no use API no documentadas).

Por otro lado, la atención estricta a la compatibilidad con versiones anteriores puede atarte las manos cuando intentas introducir nuevas funciones o revolucionar la plataforma. Apple sabía que tenía un sistema operativo moribundo, y en uno de sus movimientos más atrevidos, compró NeXT y decidió hacer de NeXTSTEP el nuevo MacOS. Una de las cosas clave que vendió a las personas en la transición fue la capa Classic compatible con versiones anteriores. Nuevamente, cuando Apple decidió cambiar a los chips Intel, un mecanismo para ejecutar aplicaciones PowerPC en Intel llamado Rosetta, junto con los Binarios universales, permitió a las personas moverse libremente entre PowerPC e Intel sin temor a perder la aplicación.

Una cosa interesante es que con la transición a Intel, el entorno clásico desapareció, pero a nadie realmente le importa porque tuvieron los 5 años anteriores para alejarse de Mac OS 9. Por lo tanto, es posible dejar de admitir sistemas heredados por tanto tiempo. ya que tiene una manera fácil de migrar al nuevo sistema y ofrece a sus usuarios suficiente tiempo para hacerlo.

Otros consejos

En una herramienta de desarrollo, si no proporciona compatibilidad total con mi código anterior, no lo compraré y dudo que alguien lo haga. Francamente, no tiene sentido. Si ya tengo un compilador que funciona para construir mi código fuente en código ejecutable que funcione para mí, entonces lo usaré. ¿Por qué molestarme en cambiar mi código para cumplir con lo que obviamente no es un estándar para el fabricante de herramientas? Si fuerzan los cambios en el código fuente de una versión a otra, ¿por qué se molestarían en hacer que la próxima versión sea compatible?

100% de compatibilidad con versiones anteriores es un requisito. La única situación en la que esto no es un requisito total es cuando los bits incompatibles son extensiones; es decir, cambios de API que son específicos de la herramienta, como complementos de Eclipse, etc. Incluso entonces, me gustaría la compatibilidad, pero me doy cuenta de que no se puede esperar por completo. Pero si proporciona una API para el desarrollo de aplicaciones / herramientas base, y no puede molestarse en mantener la compatibilidad; bueno, entonces, claramente no tomas en serio tus herramientas, y no pagaré mucho dinero por ellas.

Para proyectos caseros, la compatibilidad con versiones anteriores realmente no es importante. Para la oficina / empresa, es absolutamente crítico.

Depende de qué entornos necesita admitir y qué herramientas de terceros se utilizan que pueden ser o no compatibles.

Por ejemplo, donde trabajo actualizamos a todos a VS2008 desde VS2005, excepto nuestro grupo de BI, ya que las herramientas de SQL Server BI no eran compatibles con VS2008. Una vez que se actualizaron, se actualizaron a VS2008.

Al mirar VS específicamente, tenga en cuenta que VS2008 puede apuntar a .NET 2.0, .NET 3.0 y .NET 3.5. El truco es darse cuenta de que en realidad apunta a .NET 2.0 SP1 y .NET 3.0 SP1. Como tal, actualizar el IDE no debería requerir que realice cambios en su código.

En general, si está desarrollando una plataforma que será utilizada constantemente por muchos otros usuarios para crear sus propios productos, y planea desarrollar la aplicación durante mucho tiempo, entonces es importante. Vea PHP, Python, Eclipse y otros proyectos de código abierto que le dan mucha importancia a la compatibilidad con versiones anteriores. También es importante cuando se desarrollan servicios u otras API abiertas utilizadas en la arquitectura de n niveles. Puede cambiar todas las aplicaciones en una empresa todo el tiempo cuando cambia sus servicios.

Ahora, si está creando una aplicación retráctil o una aplicación comercial, entonces no es tan importante, porque cada versión es independiente de sus predecesoras.

Dado que se están produciendo muchos cambios en el campo de Software y Hardware, creo que es una buena idea estar abierto a nuevos cambios y mejores herramientas mientras diseña su solución. Por ejemplo, no teníamos procesadores multinúcleo y tarjetas gráficas de gama alta o tarjeta de red en los años 90, por lo que, naturalmente, los objetivos de optimización de los compiladores y las herramientas eran diferentes. Pero al mismo tiempo, Visual studio como herramientas están haciendo todo lo posible para acomodar los marcos y aplicaciones antiguas.

Creo que si esperamos un mundo mejor, deberíamos estar abiertos a un cambio constante hasta que esta industria esté súper madura. (Puede que no suceda en nuestra vida :))

Definir " cambios significativos " ;. Lo haría si los cambios se pudieran hacer con una búsqueda & amp; amp; cuidadosamente diseñada reemplazar " incluso si fueran extensos.

Sin embargo, eso es lo que I haría. Cualquier empresa para la que he trabajado se negaría a cualquier cambio en el código existente.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top