La solución web de nuestra compañía está en su cuarta generación mayor, que ha evolucionado considerablemente en los últimos 8 años. La generación más reciente presentó una amplia variedad de construcciones para ayudar con exactamente esta tarea, ya que se estaba volviendo difícil de actualizar la generación anterior en función de las nuevas demandas de los clientes. Por lo tanto, pasé bastante tiempo en 2009 pensando exactamente en este problema.
Lo más valioso que puede hacer es emplear un enfoque ágil para construir software. En particular, debe mantener un entorno en el que se pueda crear (y se cree) una nueva compilación a diario. Si bien las construcciones diarias son solo un aspecto de Agile, esta es la práctica más importante para abordar su pregunta. Si bien esto no es lo mismo que la capacidad de actualización, per se, no obstante introduce una disciplina en el proceso que ayuda a reducir las posibilidades de que su base de códigos se vuelva difícil de manejar (o que se convierta en Architect Astronaut).
En lo que marcos y lenguajes ir, hay dos requisitos principales: que el marco sea duradero y estable y que el entorno soporta una Separation of Concerns. ASP.NET me ha funcionado bien en este aspecto: ha evolucionado de manera racional y sin discontinuidades que invalidan el código anterior. Utilizo una capa de lógica de negocios separada para administrar SoC, pero ASP.NET también admite el desarrollo de MVC.Por el contrario, después de algunos meses me disgustó PHP porque simplemente parecía alentar prácticas desordenadas que pondrían en peligro futuras actualizaciones.
Con respecto a selección de DBMS, cualquier RDMS moderno (SQL Server, MySQL, Oracle) le serviría bien. Sin embargo, esta es la clave: necesita mantener las secuencias de comandos DDL para administrar las actualizaciones. Es solo un hecho de la vida. Entonces, ¿cómo haces de esto un proceso manejable? La herramienta más valiosa de cualquier desarrollador externo es mi copia de SQL Compare de Red Gate. Este proceso solía ser una pesadilla completa y un lastre significativo en mi capacidad para desarrollar mi código hasta que encontré esta herramienta. Entonces, la recomendación genérica es usar una base de datos para la cual existe una herramienta para comparar las estructuras de la base de datos. SQL Server es muy afortunado en este sentido.
Hardware es casi un cuidado. Siempre puede pasar a un nuevo hardware siempre que su proceso de desarrollo incluya un proceso razonable de lanzamiento.
Estrategia para constantes cambios en los requisitos. Nuevamente, vea Agile. Te animo a que ya no pienses en ellos como "requisitos" más, en el sentido tradicional de un gran documento lleno de especificaciones. Ágil cambia eso de manera importante. Tampoco conservo un documento de requisitos, excepto cuando trabajo en un contrato con un cliente externo que paga para que pueda estar seguro de la facturación adecuada y evitar el arrastre de características. En este punto, nuestro proceso interno es tan rápido y fluido que los informes de nuestro software de solicitud de funciones/gestión de errores (FogBugz si usted quiere saber) sirven como nuestra documentación al documentar un nuevo lanzamiento para su comercialización.
La estrategia/decisión para el rediseño total es: no. Si pone un grado razonable de pensamiento en el proceso que va a utilizar, elija las herramientas principales y aplique una Separación de preocupaciones, entonces nada menos que un abandono completo de HTTP y RDBMS debería causar un rediseño total.
Si usted es lo suficientemente ágil que nada puede cambio, es poco probable que estar siempre en una posición donde todo necesidad cambio.
Gran respuesta:) –
+1 buena explicación. Además, la tecnología cambiante también juega un papel en el enfoque de la gradación ascendente.Porque si uno ve que una nueva tecnología estaría disponible dentro de un año más o menos, ¿debería uno esperarla o buscar una actualización basada en la tecnología actual? – HotTester
HotTester - dependería de la tecnología. Por lo general, prefiero un enfoque de "esperar y ver" para las nuevas tecnologías solo porque me han quemado una o dos veces para respaldar una tecnología que no obtiene aceptación de parte de mis clientes. Dicho esto, * estoy * usando Visual Studio 2010 (que no se lanzó formalmente) y siempre estoy * buscando * nueva tecnología, simplemente porque me gusta. –