¿Cómo administrar código de producción frecuentemente modificado?

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 layout general del software. ¿Cómo se puede manejar esto de manera efectiva? Cualquier patrón de layout para manejar esto?

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 process.

Los usuarios siempre quieren 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. Ven el costo de no tener la function pero no anticipan lo que sucedería y cuánto dinero se perdería si el cambio rompe algo. (No pretendo sugerir que no eres un buen desarrollador, solo que en cualquier software no trivial habrá errores y que los cambios descontrolados probablemente los expondrán más rápidamente).

Por lo tanto, creo que es necesario dar un paso atrás y tratar de instigar un calendar de lanzamiento regular. Habrá resistencia pero puedes ser más efectivo de esa manera. Por supuesto, a veces habrá un cambio que debe hacerse de inmediato, pero si hay un calendar, 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 / testing, un procedimiento de liberación con un solo clic, etc. (Consulte The Joel Test ).

En las testings, necesita un marco de testing sólido para asegurarse de que sus soluciones no interrumpan nada más.

Editar: responde a la pregunta del comentario.

Lamentablemente, no puedo pensar en un patrón / solución verdaderamente sólida para mantener la architecture intacta, además de tomarse su time para refactorizar los "hackeos". Pero es probable que tenga poco time de sobra desde su producción. Entonces no es fácil …

Sin embargo, lo más importante es que si la architecture se está echando a perder porque realmente necesita "piratear" la solución, esto podría ser una señal de que el layout original no cumplía con los requisitos reales del producto , porque si fuera así, debería ser capaz de corrección / parche dentro del marco actual de la Arquitectura.

Por lo tanto, tratando de ser positivo acerca de toda la situación, debe tomar nota de sus soluciones, y de cómo la Arquitectura actual no está ayudando / cumpliendo, para que más adelante en el path, cuando las soluciones calientes comiencen a asentarse, tenga datos y sugerencias. como networkingiseñar cualquier parte de la architecture que necesite un layout ahora que tiene los requisitos más precisos que descubrió durante la producción.

Todos aquí han sugerido cosas muy buenas, como testings, 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 layout para resolver problemas de layout. Lo que esencialmente tienes es un problema de "process".

Preguntaría "¿Qué process puedo usar para prevenir esto?"

Desafortunadamente, (y es lo mismo donde yo trabajo) el layout es un problema para los desarrolladores y arquitectos, pero el process es un problema para los gerentes. Y realmente se necesita liderazgo para implementar un buen process y atenerse a él. Lamentablemente, eso a menudo falta.

Puede ser una respuesta demasiado básica, pero creo que debería investigar sobre el desarrollo de software ágil .

Estoy en la position afortunada donde mi CABEZA casi siempre se puede liberar. Al less 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 twig de versió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 twig de versiones y probarse 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 set de testings 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 testings internas cada vez que se implementa, lo que me vuelve seguro.

En realidad, la suerte es less un factor de lo que piensas. Esto no solo sucedió por crash; Tuve que trabajar para que sea posible. Tuve que comprometerme a escribir y mantener buenas testings automatizadas, y a get un server de integración continuo y una capacidad de compilation y deployment con un solo clic.

Regularmente dedico time a limpiar 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 architecture es bastante flexible. En segundo lugar, significa que soy bueno en la refactorización, ya que lo hago todo el time. 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.

Además de las respuestas obvias de control de revisión, testings unitarias y un sistema de compilation automatizado, parece que también necesita hacer algunas refactorizaciones pesadas. Si su layout cambia constantemente según los requisitos cambiantes, debe intentar aislar las partes de su código que cambian constantemente en sus propios modules.

Debe imponer disciplina en su 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 layout. 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 progtwigdo, 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 request en segmentos de 2,4 y 8 semanas y sea rígido con respecto a lo que includeá en esos ploops.

Hay muchos patrones de layout que pueden ayudarlo si tiene un dominio definido de problemas y sus soluciones. Revise específicamente el patrón de command , el patrón de estrategia y la architecture de complemento , ya que lo ayudarán a ampliar su set de soluciones más fácilmente. Si eres desarrollador de .Net, echa un vistazo a la architecture de plugins de Migeul Castro que revisó en DNRTV .

Hay varios ciclos de vida del proyecto contra los que puede pautar su enfoque. Este sitio enumera algunas (¡parece que estás usando el código "Code-And-Fix"!), Pero esto de ninguna manera es una list definitiva, una list más grande se puede encontrar aquí .

Como Robert Gould señaló, realmente necesitas tener una plataforma de etapas para verificar que no vas a romper nada cuando implementes para vivir.

dos herramientas obvias son el control de versiones y las testings. intente integrar el sistema de lanzamiento con ellos, para que pueda comprometer sus cambios en cada paso, y cuando todas las testings se aprueben (incluidas las de los nuevos requisitos), el sistema de lanzamiento elige la versión 'buena conocida', que será la nueva .

No sé de otros sistemas, pero monotone tiene algunos ganchos específicamente para que las testings etiqueten los commits, por lo que hay un command para "darme la última versión que pase todas las testings"

Obviamente, las testings son importantes. Pero para mí la automation es aún más. Debería poder implementar todo el proyecto desde el control de origen hasta el server de producción en less de 3 commands. Herramientas como Maven , Ant , Capistrano , (inserte aquí su herramienta favorita <…>) pueden ayudarlo mucho. Tener un sistema de continuous integration que se implemente automágicamente en un server de testing o integración cada vez que haya un cambio en el control de la fuente también puede ayudar.

Poner toda esa automation en su lugar tomará time la primera vez que lo haga …

Esto es algo de process, no de layout.

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 less 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 process 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 less satisfactoria, y luego te tomas un time 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.

La tercera cosa es asegurarte de que tienes los resources. 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 bien, puede suceder que sus usuarios no puedan enseñar, que no puedan convencer a las personas de que las soluciones rápidas son muy costosas a largo ploop, y así sucesivamente. En ese caso, recomiendo lo cuarto: pulir su currículum y comenzar a search 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.