¿Qué debe hacer cuando la aplicación web principal de su inicio se vuelve inutilizable, pero el código es difícil de mantener?

1. Averigua exactamente lo que quieres que haga
2. Escriba el código de prueba de unidad para que coincida exactamente con eso. Todos en el equipo tienen que escribir pruebas unitarias y pruebas de sistema. No se escribe ningún código nuevo hasta que todo el proyecto tenga al menos un 80% de cobertura de código.
3. Las fallas en las pruebas unitarias probablemente revelarán algunos lugares que deben reescribirse. Nadie puede enviar código que no pase todos los casos de prueba de unidad.
4. Probablemente despida a algunas personas, pero no estoy seguro de eso. Hay algo disfuncional en el grupo: pueden ser las personas, o tal vez solo necesita un mejor proceso de desarrollo de software (como Agile, por ejemplo).
5. Cree un conjunto de pruebas automatizadas que se ejecute periódicamente (como después de cada envío o una vez al día). Esto es diferente de las pruebas unitarias, que prueban pequeños bits de código de forma aislada. Las pruebas periódicas son de sistema completo.
6. Simplifique las interfaces lentamente después de tener estabilidad de código y un conjunto de pruebas que pasan constantemente.

Si su producto es viable y tiene usuarios y puede generar ingresos, entonces persevere.

En primer lugar, tengo que estar en desacuerdo con Eric Nelson arriba. Nunca establezca una métrica como “No se escribe ningún código hasta que alcanza el 80% de cobertura”. Todavía estará allí sentado dentro de 10 meses escribiendo pruebas unitarias para cosas tontas porque debe alcanzar una cobertura de código del 80%. Las pruebas unitarias son importantes cuando son importantes y no lo son cuando no lo son. El truco es ser pragmático y probar la unidad donde sea necesario. Eric hizo la prueba de lo más destacado de su respuesta, mientras que creo que lo más destacado debería ser reiniciar su inicio.

Segundo, descubra cuál quiere que sea su resultado final. Comience desde el frente. Tome su diseñador y juntos simule toda la interfaz de usuario como le gustaría que fuera, como debería ser. Al mismo tiempo, haga que su equipo de fondo acuerde cuáles son los requisitos con respecto a los datos. Diseñe una API que exponga solo los puntos finales que necesita, es decir, solo las llamadas necesarias para que un front-end interactúe con sus datos. Los dos equipos junto con la gente del producto deben interactuar constantemente para determinar esos requisitos. Esto no debería llevar mucho tiempo ya que ya tienes una aplicación. Solo tiene que simplificarlo y describirlo en términos de una API. Creo que es mejor si las personas de la parte delantera manejan este automóvil, ya que la forma en que se interactúan los datos será su responsabilidad.
Luego átalo todo junto. El front end debería hablar con la API. La API debe interactuar con los modelos y datos que conforman su aplicación. Si mañana desea crear otro cliente (una aplicación móvil, por ejemplo), también hablará con la misma API. Un día después, es posible que desee abrir la API para aplicaciones externas de terceros. Podrá hacerlo fácilmente porque ya tiene la API.

Si te tomó 4/5 meses construir algo malo, entonces con las lecciones aprendidas puedes construir algo Great ™ en 3 meses o menos. Recuerde diluir, diluir, diluir. Características que nadie quiere – fuera. Cuenta con solo 2 personas que quieren salir. Características que realmente no funcionan y que nadie tuvo la oportunidad de querer salir. Comience de nuevo y simple y construya desde allí.

Si debe despedir a alguien, despida a aquellos que no se hagan responsables y reconozca que se requiere reiniciar.
Una reescritura no es algo bueno o malo. Es algo que debe tomarse en contexto. Si su aplicación no se puede usar y la base del código es imposible, parece que reescribir es su única opción. Acéptalo como una segunda oportunidad.