Mi proyecto me invita a hacer muchos cambios en el código de producción. El requisito sigue apareciendo y necesito hacer cambios y desplegarlo lo más pronto posible. A veces termino creando código de trabajo de parche porque algunos de los requisitos no encajarían en el diseño general del software. ¿Cómo se puede manejar esto de manera efectiva? Cualquier patrón de diseño para manejar esto?¿Cómo administrar código de producción frecuentemente modificado?
He visto esto suceder muchas veces y siempre termina en lágrimas. La última vez que el cliente perdió millones de dólares antes de que mejoraran su proceso.
Los usuarios siempre desean que los nuevos requisitos estén disponibles "tan pronto como sea posible", pero no comprenden los riesgos de realizar los cambios de la misma manera que usted. Consideran que el costo de no es, pero no anticipan qué sucedería y cuánto dinero se perdería si el cambio rompiera algo. (No pretendo sugerir que no eres un buen desarrollador, solo que en cualquier software no trivial habrá errores y que los cambios incontrolados probablemente expondrán más rápidamente).
Así que, creo necesitas dar un paso atrás e intentar instigar un cronograma de lanzamiento regular. Habrá resistencia pero puedes ser más efectivo de esa manera. Por supuesto, a veces hay será un cambio que debe hacerse de inmediato, pero si hay un calendario, entonces la responsabilidad recaerá en el usuario para justificar por qué tiene sentido romper el ciclo de lanzamiento.
Ah, y como todo el mundo sugiere, necesita una infraestructura técnica como un sistema de ensayo/prueba, un procedimiento de liberación con un solo clic, etc. (Consulte The Joel Test.)
Estoy totalmente de acuerdo con usted, Stephen Darlington, pero a veces los productos se encuentran con situaciones inesperadas cuando se publican, y deben repararse rápidamente. Decir pensar en cualquier sistema operativo en el mercado. Siguen un lanzamiento importante, pero siempre habrá una necesidad de arreglos urgentes porque es demasiado crítico –
@Robert Gould, no estoy seguro si lees su publicación completa, pero él dice que hay momentos en los que podrías tener que liberarlos inmediatamente. "Por supuesto, a veces habrá un cambio que debe hacerse de inmediato" – mmcdole
@Robert. Hay absolutamente un lugar para arreglos urgentes. Sin embargo, estos deberían ser una gran excepción. Debe tomar una decisión consciente para aplicar una; no debería ser la opción predeterminada. –
Puede ser una respuesta demasiado básica, pero creo que deberías investigar un poco sobre agile software development.
Pruebas, necesita un marco de prueba sólido para asegurarse de que sus soluciones no rompan nada más.
Editar: Responde la pregunta del comentario.
Desafortunadamente, no puedo pensar en un patrón/solución verdaderamente sólida para mantener la arquitectura intacta, además de tomarse su tiempo para refactorizar los "hacks". Pero es probable que tenga poco tiempo de sobra desde su producción. Así que no es fácil ...
Sin embargo, más importante aún si la arquitectura es cada vez estropeado porque realmente se necesita para "cortar" la solución en, en realidad esto podría ser una señal de que el diseño original no estaba cumpliendo con el requisitos reales del producto, porque si fuera así, debería poder corregir/aplicar parches dentro del marco actual de la Arquitectura.
Por lo tanto, tratando de ser positivo sobre toda la situación, debe tomar nota de sus soluciones, y cómo la arquitectura actual no está ayudando/cumpliendo, para que más tarde en la carretera, cuando las soluciones calientes comiencen a establecerse, tenga datos y sugerencias para rediseñar cualquier parte de la Arquitectura que necesite un diseño ahora que tiene los requisitos más precisos que descubrió durante la producción.
Gracias por esa sugerencia. Estoy preocupado por una cosa más. Realmente estoy arruinando toda la arquitectura modificando el código regularmente. ¿Alguna sugerencia al respecto? – Manoj
+1 : Si el cambio "rompe" la arquitectura, entonces usualmente la arquitectura no estaba bien para empezar. Raramente se rompe la arquitectura porque el cambio es una idea muy mala. –
Sí, creo que necesito echar un vistazo al arquitectura. Debería tomar nota de las soluciones e intentar rediseñarlas en el camino.¡Gracias por la sugerencia! – Manoj
Como señaló Robert Gould, realmente necesitas tener una plataforma de etapas para comprobar que no vas a romper nada cuando implementes en vivo.
Estoy en una posición afortunada donde mi HEAD casi siempre se puede soltar. Al menos una vez por semana, tengo un código en HEAD que, como desarrollador, me gustaría publicar. Eso no significa que cada versión liberable en realidad tenga un lanzamiento, pero podría hacerlo. En mi entorno, un lanzamiento semanal es bastante práctico, y generalmente se hace ...
Inmediatamente antes de implementar en etapas, promociono mi código a una rama de Liberación. Siempre despliego el mismo código para vivir que se ha probado previamente en la etapa.
Luego, se pueden realizar arreglos urgentes en la rama de versiones y probarlos en etapas antes de implementarlos. Si la solución es lo suficientemente buena, puedo fusionarla nuevamente en HEAD. Si fue un hack horrible, puedo volver a implementarlo correctamente en HEAD más tarde.
Tengo un buen conjunto de pruebas de desarrollador que se ejecutan automáticamente en cada check-in, lo que confirma que no he roto nada importante. Mi aplicación también ejecuta pruebas internas cada vez que se implementa, lo que me vuelve seguro.
En realidad, la suerte es menos un factor de lo que piensas. Esto no solo sucedió por accidente; Tuve que trabajar para que sea posible. Tuve que comprometerme a escribir y mantener buenas pruebas automatizadas, y a obtener un servidor de integración continuo y una capacidad de compilación y despliegue con un solo clic.
Paso regularmente tiempo limpiando mi código, como parte de mis actividades normales de desarrollo. Esto tiene dos beneficios. En primer lugar, significa que mi base de códigos comienza relativamente limpia, por lo que la arquitectura es bastante flexible. En segundo lugar, significa que soy bueno en la refactorización, ya que lo hago todo el tiempo. Con esto, me refiero a la refactorización en el sentido de hacer una serie de pequeñas transformaciones individualmente al código existente, en lugar de hacerlo en el sentido de "echarlo todo de quicio y poner en práctica" (que es algo más peligroso).
En mi opinión, esta "capacidad de liberación continua" es el mayor beneficio individual de las metodologías Agile.
dos herramientas obvias son control de versiones y pruebas. intente integrar el sistema de lanzamiento con ellos, para que pueda comprometer sus cambios en cada paso, y cuando todas las pruebas se aprueben (incluidas las de los nuevos requisitos), el sistema de lanzamiento elige la versión 'buena conocida', que será la nueva .
No sé sobre otros sistemas, pero monótona tiene unos ganchos específicamente para hacer las pruebas de etiquetar las confirmaciones, por lo que hay un comando para "dame la última versión que pasa todas las pruebas"
Obviamente, las pruebas es importante. Pero para mí la automatización es aún más. Debería poder implementar todo el proyecto desde el control de origen hasta el servidor de producción en menos de 3 comandos. Herramientas como Maven, Ant, Capistrano, (inserte su herramienta favorita aquí < ...>) pueden ayudarlo mucho. Tener un sistema de integración continua que se implemente automágicamente en un servidor de prueba o integración cada vez que haya un cambio en el control de la fuente también puede ayudar.
Poniendo todo en su lugar que la automatización va a tomar tiempo la primera vez que lo hace ...
Además de las respuestas obvias de control de revisiones, pruebas unitarias, y un sistema automático de generación, parece que también es necesario hacer un poco de refactoring pesado. Si su diseño cambia constantemente según los requisitos cambiantes, debe intentar aislar las partes de su código que cambian constantemente en sus propios módulos.
Todo el mundo aquí ha sugerido cosas muy buenas, como pruebas, etc. Pero creo que debo señalar que puede estar haciendo la pregunta incorrecta.Usted está preguntando si hay un "patrón" que pueda ayudar con esta situación. Un patrón es una opción de diseño para resolver problemas de diseño. Lo que esencialmente tienes es un problema de "proceso".
Preguntaría "¿Qué proceso puedo usar para prevenir esto?"
Desafortunadamente, (y es lo mismo donde yo trabajo) el diseño es un problema para los desarrolladores y arquitectos, pero el proceso es un problema para los gerentes. Y realmente se necesita liderazgo para implementar un buen proceso y atenerse a él. Lamentablemente, eso a menudo falta.
Debe imponer disciplina en la acumulación de requisitos. A riesgo de sonar a la vieja escuela y de estar deprimido, dígales a las personas que no y que necesitan sentarse con usted y aprender los puntos específicos de dolor y esfuerzo para realizar cambios drásticos en el diseño. Para las bases de datos, explique sobre cardinalidad y cómo esto causa dolor de corazón. Arroje su heno contra la jaula e insista en un ciclo de lanzamiento programado, en el que solo participará en la producción todos los martes, pero solo después de que la aceptación del usuario haya tenido lugar. Divida cada solicitud en segmentos de 2,4 y 8 semanas y sea rígido con respecto a lo que incluirá en esos plazos.
Hay muchos patrones de diseño que pueden ayudarle si tiene un dominio definido de problemas y sus soluciones. Específicamente revise Command Pattern, Strategy Pattern y Plug-in architecture, ya que lo ayudarán a ampliar su conjunto de soluciones más fácilmente. Si eres desarrollador de .Net, echa un vistazo a la arquitectura de plugins de Migeul Castro que revisó en DNRTV.
Lo que no ayuda cuando la aplicación simplemente no está funcionando de manera crítica, y dejarla hasta el martes siguiente costará millones de dólares. –
Esto es algo de proceso, no de diseño.
Lo primero que debe hacer es educar a sus usuarios para que tengan una idea del costo de cambiar los requisitos. Esto no tiene la intención de evitar que los cambien, sino para evitar cambiarlos y solicitar la implementación lo antes posible, a menos que haya una necesidad comercial definida. (Supongo que esto es un asunto de negocios, en cuyo caso es su trabajo hacer lo que la empresa necesita de la mejor manera posible, y dejar que la gente sepa cuál es la mejor de sus capacidades, y qué costos de funcionalidad tiene el esquema general de cosas.)
Lo segundo es establecer un proceso de dos soluciones para soluciones rápidas. En primer lugar, tienes el parche en su lugar para que la aplicación funcione de manera más o menos satisfactoria, y luego te tomas un tiempo y encuentras la solución real. Esto también puede requerir un poco de educación del usuario, y puede encontrar la idea de la "deuda técnica" útil para explicar esto.
Lo tercero es asegurarse de tener los recursos. Si no puede mantenerse al día con los cambios de requisitos como este, necesita ayuda y necesita mostrar por qué. Si los poderes deciden no atraer a más personas, y entienden que eso limita la cantidad de modificaciones, eso también es bueno.
Ahora, puede suceder que los usuarios no puedan enseñar, que no se puede convencer a la gente de que las soluciones rápidas son muy costosas a largo plazo, y así sucesivamente. En ese caso, recomiendo lo cuarto: pulir su currículum y comenzar a buscar un nuevo trabajo. En este momento, parece que te están preparando para fallar, y ese es un lugar muy malo para estar. Como dice el viejo dicho, cambie su trabajo o cambie su trabajo.
Código de producción modificado con frecuencia?!?! QUERIDO DIOS NOOOOOOO! –
No hay otra opción :(! – Manoj
Siempre hay otras opciones ... – Ilya