Iniciar una arquitectura coherente en una aplicación heredada

Tengo la responsabilidad de un gran sitio web basado en Asp.Net. Actualmente es un sitio web (no una aplicación web), algunos servicios de Windows y varias bibliotecas de clases.

La capa de datos utiliza una mezcla de LLBLGEN y Linq To LLBGen, así como una serie de instancias de SQL en línea heredado que no se han refactorizado.

Hay algunas implementaciones de tipo administrador, pero en muchos casos la aplicación exhibe el antipatrón de Smart UI (es decir, demasiada lógica de negocios en el código detrás de las clases)

El sitio tiene un tráfico razonablemente alto y el rendimiento es bueno, pero estamos ampliando nuestra capacidad de desarrollo a un equipo de alrededor de 10, y cada vez está más claro que necesitamos un diseño en capas global sobre el middleware existente.

Mi pregunta es por dónde empezar? Tenemos 10 años de código (algunos de ellos todavía solo migraron cosas de ASP Classic), muchos enfoques y estilos diferentes.

Refactorizar todo el código base no es realista y, probablemente, no deseable

Sé que esta no es una situación nueva, ¿hay ideas o conceptos útiles sobre cómo abordar este problema?

También he estado trabajando en situaciones similares y puedo darte el siguiente consejo.

1. Necesita reducir la deuda técnica . Ahora. ¿Por qué? Porque la deuda técnica es como la deuda financiera. Pagarás intereses por ello.
2. Como refactorizar todo el código base no es factible, pregúntese: ¿qué lo impide? ¿Es simplemente demasiado trabajo? ¿Por qué?
3. Cree un plan para reducir la deuda técnica a tiempo. Por ejemplo, al establecer reglas como " cada bit de código que toca el equipo debe ser reparado / refactorizado al nuevo estándar ". Típicamente: las pruebas unitarias deben escribirse, el código debe moverse en las capas correctas, etc. Esto le permite corregir una gran cantidad de código sin recurrir a proyectos de "refactorización" ridículamente caros y de bajo valor.
4. Envuelve la basura. El desacoplamiento es clave para la refactorización y la buena arquitectura. Si puede particionar la base del código de alguna manera, tal vez pueda refactorizar bits más pequeños.
5. No aumente más la deuda tecnológica. No aumente más la deuda tecnológica. No aumente más la deuda tecnológica. No haga...

Tienes razón en que refactorizar toda la base de código no es deseable. Refactorizar es algo que se hace antes del nuevo desarrollo para que ese desarrollo sea más fluido. Si no planea modificar todo el código en su base de código, la refactorización demostrará un uso ineficiente del tiempo.

Algunos consejos además de lo que dice Sklivvz:

1. Separe el código en secciones modificadas con frecuencia y con poca frecuencia. Solo las secciones que se modifican con frecuencia deben integrarse completamente en la nueva arquitectura. Integre el código modificado con poca frecuencia con la nueva arquitectura utilizando la menor cantidad de cambios posible (o ningún cambio si puede salirse con la suya). Resista la tentación de la reescritura completa, le costará más de lo que gana. Aprecia que el código existente funciona, incluso si es feo.

2. Descubra cuál es su objetivo de refactorización. ¿Desea facilitar la entrada de contenido al sitio? ¿Tiene muchos errores y desea mejorar la calidad percibida por el usuario? ¿Desea reducir el tiempo de desarrollo de funciones? ¿O quieres principalmente una mejor experiencia de usuario? Su arquitectura debería facilitar la refactorización del código para cumplir con los objetivos establecidos. Nunca olvide que el principal beneficiario de su refactorización debería ser su usuario / cliente / negocio. El código más limpio no es un objetivo en sí mismo, es un método para un fin, y el fin involucra a un usuario.

3. Intente encontrar tantas arquitecturas de referencia como sea posible y no tenga miedo de copiarlas. No reinventes la rueda. Si alguien más tiene una arquitectura que funciona bien para sitios como el suyo, aprenda de ellos.

4. Piensa en el lado de la administración de personas. En mis propios proyectos de migración, la parte más difícil fue hacer que las personas aprendieran las nuevas formas y se apegaran a ellas. Necesitará implementaciones de referencia y una forma de enseñar la arquitectura a todos los miembros del equipo (tanto antiguos como nuevos). Para reducir la resistencia al cambio, solicite la opinión de todos en el equipo antes de tomar decisiones. Asegúrese de que el nuevo diseño realmente mejore las cosas desde la perspectiva personal de los desarrolladores, y no sea un salto tan grande como para que se sientan fuera de su profundidad.

Lo más importante que vi al tratar de lidiar con una base de código antigua es NO seguir cambiando lo que está buscando. Es decir, descubra la arquitectura que desea, ¡luego PEGUE CON ESE PLAN! Uno de los grandes problemas que tuvo mi última posición fue que la base de código tenía varias ideas diferentes de cómo debería verse con el tiempo. Cada vez que se intentaba una nueva idea, parte del código se convertía, otra no, y luego alguien más tenía una idea 'mejor'. Se hizo cada vez más incoherente con el tiempo y finalmente fue desechado.

Hay un libro / pdf gratuito realmente bueno sobre la reingeniería de software heredado: http://scg.unibe.ch/download/oorp/

Dice OO en el título, pero la mayoría de las ideas se aplican a cualquier software. Discute por dónde empezar, cómo lidiar con diferentes partes de un sistema durante la reestructuración y muchos más de esos temas.

Si no tiene una arquitectura coherente, es porque la gerencia no entiende / no se preocupa por el problema. Solo codifique. Debe introducir una nueva arquitectura buena a medida que escribe un nuevo código.

Debe volver a diseñar las cosas solo si comienzan a tener errores realmente serios, necesita extenderlo y simplemente no puede, o simplemente no cumple con sus requisitos.

Básicamente estoy diciendo que solo le importan los problemas que realmente les interesan a sus gerentes, no los temas que les importarían si tuvieran su conocimiento.

Si puede vender una nueva arquitectura a la administración, comience con las pruebas. Si no quieren invertir en pruebas, sus esfuerzos solo le causarán problemas.