¿Qué hacer como líder de un nuevo equipo en un proyecto con problemas de mantenimiento?

Me acaban de poner a cargo de un proyecto de código con problemas de mantenimiento. ¿Qué cosas puedo hacer para que el proyecto se mantenga estable?

Me encuentro en un lugar donde estamos trabajando con un sistema .NET multinivel muy grande al que le faltan muchas cosas importantes, como pruebas unitarias, IOC, MEF, demasiadas clases estáticas, conjuntos de datos puros, etc. Estoy solo 24 pero he estado aquí durante casi tres años (esta aplicación ha estado en desarrollo durante 5) y principalmente debido a limitaciones de tiempo, hemos estado agregando más basura para adaptarse a la otra basura. Después de hacer varios proyectos en mi tiempo libre, he comenzado a comprender cuán importantes son todos esos conceptos. Además, debido al cambio de personal, ahora me encuentro a la cabeza del equipo en este proyecto y realmente quiero encontrar algunas formas inteligentes de mejorar esta aplicación. Formas en que el valor puede explicarse a la gerencia. Tengo ideas de lo que me gustaría hacer, pero todas parecen tan abrumadoras sin mucha ganancia inicial. Cualquier historia sobre cómo la gente ha tratado o habría tratado esto sería una lectura muy interesante. Gracias.

Presupuesto de tiempo para atacar la deuda técnica. Solo tienes que hacerlo. Las partes que atacas primero dependen de dónde pasan la mayor parte del tiempo tus desarrolladores actualmente, pero es más importante que comiences que las cosas ideales. Si está utilizando Scrum, coloque piezas específicas de deuda técnica en su cartera de pedidos y trátelas como características hasta que las maneje.

Trabajar eficazmente con código heredado es muy recomendable, y probablemente sea útil. No lo he leído, pero parece tener mucha información sobre cómo obtener pruebas unitarias en código heredado para que pueda modificarlo y actualizarlo de manera segura.

Use la analogía de la tarjeta de crédito con la administración: está "pagando intereses" en todo lo que hace porque es muy difícil lograr algo. Si paga su deuda técnica, liberará esos recursos y podrá desarrollar nuevas funcionalidades más rápidamente en el futuro. Si no lo hace, sus "pagos de intereses" (pagados en tiempo de desarrollo) continuarán acumulándose y su equipo producirá nuevas funcionalidades más lentamente.

Tal vez comience a estimar la cantidad de tiempo que pasa cada ciclo luchando contra la deuda técnica para darles una idea de cuánto ya se ha acumulado. Describa cómo se vería un arreglo o cambio de característica en un sistema que se puede mantener, cómo se ve en el sistema real y qué cambios necesitarían hacerse o podrían ser buenos primeros pasos para llegar allí.

Transforme la deuda técnica en correcciones de errores y características adicionales.

He encontrado que un enfoque iterativo para mejorar produce los mejores resultados. El mantra en mi trabajo es mejorar la calidad del código cada vez que lo tocas. Cada trabajo, ya sea una corrección de errores o una característica, comienza con un análisis de lo que se puede arreglar / refactorizar / limpiar. Intentamos hacer que el refactor esté a la par (en escala) para el trabajo que tenemos que completar.

Cree una lista ordenada de los problemas en la base del código. Asegúrese de que todos conozcan la lista y el orden de prioridad. Siempre que obtengan un trabajo, deben buscar un problema de la lista que esté relacionado con el código en el que trabajarán.

Esto no arreglará todo. Hay algunos refactores o correcciones que requieren una gran cantidad de tiempo y recursos. Por lo general, trato de vincularlos con otras grandes piezas de trabajo que se beneficiarán.

Podría estar diciendo lo obvio, pero bueno.

Escriba una pequeña prueba unitaria que ejercite una porción de código que tenga problemas, luego refactorice dicha porción, asegurándose de que la prueba aún pase. Pase a otro fragmento de código, el que puede alcanzar más fácilmente desde esa pequeña porción de tierra sólida que acaba de construir. Enjabonar, enjuagar, repetir.

Esto también lo ayudará a familiarizarse un poco más con la base de código.

Después de haber estado haciendo eso por un tiempo, pensará que es hora de hacer una refactorización más extendida. Descubrir códigos duplicados, violaciones del principio DRY ... ya sabes, lo habitual. Para entonces, tendrá una cobertura de código posiblemente decente, que le permitirá barajar métodos, extraer interfaces y todas esas comodidades.

Siempre deje la base de código un poco mejor de lo que era antes de comenzar a hackearla. Estoy bastante seguro de que es una pequeña inversión que valdrá la pena, incluso en el corto plazo.

Podría intentar explicar la deuda técnica que tiene este proyecto para tener una idea de por dónde empezar. También podría tratar de negociar que, debido a los cambios de los empleados, debe pasar algún tiempo para ponerse al día con el código y esto significa realizar algunas pruebas para ayudar a garantizar un mejor desarrollo futuro, ya que las pruebas pueden ayudar a prevenir errores y facilitar las cosas. Posiblemente gente nueva para trabajar en el proyecto.

En casos como ese, me gusta tratar de optimizar el proyecto tanto como sea posible. Descubra qué características son absolutamente necesarias para que avance. Cualquier sistema que haya existido durante mucho tiempo probablemente tenga un retraso muy largo. Muchos de estos elementos serán críticos y muchos serán simplemente "campanas y silbatos".

En cuanto a las pruebas, las pruebas unitarias definitivamente serán útiles, pero es posible que desee pedirle a parte del personal no técnico que participe en las pruebas y envíe errores a los miembros de su equipo.

Buena suerte.

Una opción es desempolvar su currículum y comenzar a buscar trabajo.

Una buena pregunta que debe hacerse es si este proyecto mal ejecutado es indicativo de cómo se ejecuta toda la empresa. Si la respuesta es sí, pregunte si le pagan lo suficiente como para permanecer en una empresa mal administrada.

Muchas veces puede impulsar la refactorización por parte de la administración superior si puede decirles que será una actualización de rendimiento o corrige algún error existente. No vuelva a factorizar solo para cambiar algo a lo que haría, especialmente si funciona. El tiempo de corrección de errores también puede ser una buena manera de encajar en algunas refactorizaciones, ya que de todos modos ya está allí. Sé asertivo y no lo mires porque eres más joven que tus compañeros programadores. Comience con algo pequeño, como realizar algunas pruebas unitarias y trabajar desde allí, puede exponer algunos errores que pueden hacer que la administración le brinde ciclos para otras cosas.

Actualmente estoy leyendo Brownfield Application Development en .NET que, básicamente, trata sobre cómo lidiar con los problemas que tiene actualmente. Hasta ahora, me gusta la mayor parte de lo que dice (no todo, pero este es el tipo de libro que te ayuda a pensar tu propio camino a través de los problemas, no uno que pretenda ser completamente prescriptivo). Puede ayudar de dos maneras: muestra que no estás solo; con suerte le dará pistas sobre cómo abordar algunos de los problemas.

Básicamente, estoy de acuerdo con la mayoría de los enfoques: no se puede arreglar todo de la noche a la mañana, pero puede mejorarlo gradualmente en pasos muy pequeños. Y sí, la deuda técnica es la metáfora que necesita usar.

En última instancia, depende de cuán bueno sea su gente en el proyecto. Si es el mismo equipo que creó el desastre, entonces tienes pocas posibilidades de mejorarlo con el mismo grupo. Analice a su personal, descubra a sus miembros más débiles y reemplácelos (si tiene la capacidad de hacerlo).

"No se puede hacer un bolso de seda de la oreja de una cerda".