.NET Framework: ¿cuándo actualizar?

Question

Me enfrenta al desafío de liderar dos (actualmente) grupos de desarrollo .NET separados con diferentes estrategias de desarrollo. Un grupo está desarrollando en .NET Framework 2.0 (con quizás unas pocas aplicaciones en 3.5). El otro grupo adopta inmediatamente cualquier nuevo marco que surja, y comienza a codificar cualquier aplicación nueva con él (están ejecutando aplicaciones 2.0-4.0). Para este último grupo, las aplicaciones escritas en una versión anterior que el último marco no se actualizan.

¿Cuál es la corriente de pensamiento cuando se trata de una empresa que desarrolla aplicaciones web sobre cuándo adoptar un nuevo marco, y si migrar aplicaciones creadas en versiones anteriores al último marco o no? Hace años, la idea era esperar hasta que la tecnología se generalizara, pero parece que ahora no se aplica mucho con .NET.

Answer 1

(Lo que sigue es mi opinión personal, basada en aprox. 1 1/2 años de experiencia con .NET en el mismo entorno corporativo. Otras opiniones pueden diferir de duda mía.)

Probablemente lo más importante a considerar serían las versiones de .NET Framework que sus clientes han instalado en sus máquinas.

Por ejemplo, nuestro cliente principal en el trabajo ha instalado .NET 3.5 y Silverlight 3 en todas las máquinas (> 5,000). Si bien nos gustaría mucho desarrollar contra los frameworks de la versión 4, no es realmente una opción hasta que el personal de TI del cliente finalmente decida que debería implementar estos frameworks. (Esperamos que finalmente ocurra a mediados de 2011. Pero el cliente tiene muchas máquinas, por lo que las cosas siempre tardan más de lo que desea. También siguen ejecutando Windows Vista en todas las máquinas de escritorio. En otras palabras, los grandes clientes son probablemente sea más lento adoptar las nuevas versiones .NET framework. Eso es otra cosa a tener en cuenta.)

Sin embargo, creo que es seguro esperar que sus clientes ya tengan instalado .NET 3.5. .NET 2 lentamente es una cosa del pasado, y probablemente incluso pueda dejar de soportar .NET 1.1 en máquinas de escritorio.

Answer 2

La forma en que administro mis equipos de desarrollo es hacer lo mejor para el proyecto individual teniendo en cuenta las necesidades del equipo Y de los clientes a los que apoyamos.

Normalmente, la actualización proporciona nuevas funciones y hace que escribir código sea más fácil/rápido para lograr lo que un cliente puede desear. Sin embargo, hay un costo obvio con la actualización: a veces se necesita capacitación nueva y, a veces, hay problemas con la compatibilidad con versiones anteriores (especialmente para cualquier aplicación no trivial). Por supuesto, todo esto cuesta dinero.

En general, trato de mantener a mis equipos a la vanguardia ya que hemos aprendido (a través de la experiencia) que mantener varias versiones de marcos puede crear mucha confusión y, en última instancia, requiere la misma, o más, costos como solo hacer una actualización única. Dicho esto, hay un par de clientes que tenemos que específicamente no quieren que actualicemos. Esos son casos especiales, por supuesto, pero los administramos según sea necesario.

Básicamente, para resumir la respuesta, decida qué es lo más importante para usted. ¿Nuevas características? Ahorro de costos (¿qué debe pensar sobre los costos múltiples - costos de desarrollo y de los clientes)? Mantenibilidad? ¿Apoyo? Una vez que haya decidido esas cosas y haya recibido la opinión de sus equipos de desarrollo, la respuesta debería ser bastante clara.

Answer 3

Tenemos una tienda para dos personas. Si fuera por mí, actualizaríamos tan pronto como se lance una nueva versión de .NET y Visual Studio. Mi compañero es más cauteloso y prefiere esperar al menos 6 meses para ver si hay algún problema conocido que surja.

De cualquier manera, creo que es mejor actualizar de forma razonablemente rápida, y el enfoque de mi pareja, aunque frustrante para mí, tiene sentido, así que sigo su ejemplo. La mayor preocupación que tengo es la cantidad de versiones de Visual Studio que necesitamos mantener para admitir aplicaciones antiguas. Todavía tenemos la aplicación VB6 (y una FoxPro para DOS) porque nuestros predecesores nunca quisieron actualizar. Vivimos con el temor de que deba realizarse una modificación en una de esas aplicaciones. generalmente termina en una nueva escritura porque el código anterior es tan malo (o tal vez somos malos al leer el código anterior).

Creo que es muy inteligente actualizar los programas y la base de código razonablemente rápido a medida que sale un nuevo conjunto de herramientas. Por lo general, las herramientas de migración funcionan mejor con relativamente nuevas conversiones, a diferencia de las conversiones muy antiguas o nuevas. Simplemente hace la vida más fácil.