¿Cómo convence a su gerente de que su proyecto necesita una gran refactorización?

Question

Me he unido a un proyecto de rails como contratista. El proyecto ha estado funcionando por más de un año. El código está escrito por aproximadamente 10 desarrolladores diferentes y la mayoría de ellos también son contratistas. Tienen un estilo de código diferente. Algunos de ellos vinieron de Java. El código tiene puntajes horribles con metric_fu. Muchas funciones son muy largas (100 - 300 líneas). Algunas funciones tienen una cantidad insensata de ramas lógicas, bucles y recursiones. Cada solicitud genera una tonelada de consultas sql. El rendimiento es muy malo. Muchos códigos obsoletos que nunca se usan pero que nunca tuvieron la oportunidad de limpiarse. La arquitectura del núcleo está completamente equivocada o sobre ingeniería. La cobertura del código es solo de aproximadamente el 25%. Las vistas y los parciales son caóticos y terribles de leer y entender.

El gerente está en una posición que intenta satisfacer al CEO agregando continuamente nuevas características, sin embargo, cada vez es más difícil implementar las funciones nuevas sin romper otra cosa. Él sabe que el código es malo, pero no quiere poner demasiado esfuerzo en solucionarlos, ya que la refacturación llevará demasiado tiempo.

Como contratista/desarrollador, ¿cuál es una buena manera de aclarar esta situación y conveniencia al gerente o al CEO para repartir algo de tiempo para refactorizar?

preguntas relacionadas

How can I convince skeptical management and colleagues to allow refactoring of awful code?

How to refactor on a budget

Dealing with illogical managers

Answer 1

En mi experiancia limitada:

1. Es imposible convencer a un gerente que es necesario reservar un tiempo para refactorizar. Puede informarlo y reforzar el punto cada vez que se encuentre con un problema debido a un código incorrecto. Entonces solo sigue adelante. Con suerte su jefe lo resolverá.

2. Es bastante común entrar en un proyecto en marcha y pensar "esto es basura total". Dale tiempo. Puede comenzar a ver un patrón en la locura.

Answer 2

He estado en situación similar. Básicamente, hay sólo dos opciones:

• Usted obtiene un tiempo relajado y se le podría conceder tiempo para refactorizar algo
• debido al código mal mayor desarrollo de algún componente llega a un puesto. No puede proceder a agregar nada porque cada pequeño cambio hace que todo lo demás deje de funcionar. En este caso de emergencia, obtendrá un "avance" con refactorización.

simplemente he respondido de alguna otra pregunta, mi historia de horror:

https://stackoverflow.com/questions/1333077/dirty-coding-tricks-to-deliver-project-on-time/1333095#1333095

He trabajado en un proyecto donde trucos sucios fueron el principio motor principal del desarrollo. Needlees para decir, después de un tiempo estos trucos han comenzado a entrar en conflicto entre sí. En un componente de análisis, tuvimos que implementar el otro truco muy sucio: ocultar los valores calculados que, debido a los trucos en conflicto, no se calcularon correctamente. Después, los trucos de segundo nivel comenzaron a entrar en conflicto y tuvimos que crear trucos para lidiar con ellos. Desde entonces, incluso la mención de este componente me hace sentir horror de tener que trabajar en él nuevamente.

Es exactamente la segunda situación donde la refactorización es la única salida.

En general, muchos gerentes sin experiencia técnica (en realidad, aquellos que también provienen de programadores malos) ni se preocupan ni comprenden el valor del código de calidad y la buena arquitectura. No puede hacer que escuchen hasta que algo interrumpa sus planes, como un golpe de características "no implementables", errores crecientes y recurrentes, solicitudes de clientes que no pueden satisfacerse, etc.Solo entonces la comprensión de los problemas del código puede venir por primera vez. Por lo general, es demasiado tarde para entonces.

Answer 3

Tomaría una pequeña porción de la aplicación y la refactorizaría y optimizaría hasta que brille (y lo haría en mi tiempo personal para no molestar a mi gerente). Entonces podrá mostrarle a su gerente/director general los buenos resultados de la refactorización y las optimizaciones de SQL.

Answer 4

Si hay una necesidad de refactorizar, el código hablará por sí mismo. La refactorización menor puede continuar durante el desarrollo. Si no puedes convencer al gerente, entonces probablemente deberías reconsiderar si es necesario.

Sin embargo, si es absolutamente necesario, la construcción de métricas de actividades de desarrollo y los beneficios deben convencer al gerente.

Answer 5

Creo que una de las opciones sería la de poner de relieve que el gestor de la forma de re-factorización la base de código ahora ahorrarán tiempo (es decir, dinero) en el largo plazo. Si se espera que el proyecto se ejecute a largo plazo, realizar los cambios ahora claramente le ahorrará tiempo a usted y a otros desarrolladores en el futuro.

Lo mejor es utilizar un ejemplo de una característica en la que ha trabajado para estimar cuánto tiempo le llevaría si tuviera que trabajar con el código del limpiador en primer lugar. ¡Buena suerte!

Answer 6

Un truco, recientemente he trabajado en una empresa así ... siempre estaban presionando por cosas nuevas, una vez más sabían que era malo, pero no importa cuánto lo empujara, incluso conseguí consultores externos para verifico mis hallazgos, lo vieron como una pérdida de tiempo.

Eventualmente vieron la luz ... solo tardaron varios bloqueos en el servidor y en un momento casi completo 8 días sin sitio web para convencerlos.

Incluso en eso insistieron que 'debe' ser el servicio de alojamiento.

La clave es intentar cuantificar cuánto tiempo durará su sitio antes de que se contraiga, y obtener alguna verificación externa que lo respalde: "ellos" siempre confían en personas externas que no saben nada de su aplicación. Además, intente, si puede, dar un plan que implique un reemplazo gradual en el peor, y un plan de cuánto tiempo tomaría hacerlo de esa manera. También hay un plan para 1 o 2 cuerpos que están trabajando en una reescritura completa, pero puede ser muy realista, ¡o te morderá el trasero! Si sigue esa ruta (que es lo que hicimos), puede tener algo de trabajo en el sitio existente siempre que lo incorpore al nuevo.

Answer 7

Le sugiero que se concentre en las cosas que pueden ver por sí mismas, es decir, seguramente notarán que la aplicación es lenta en algunas funcionalidades, por lo que tome una de ellas y diga algo como "Puedo reducir el tiempo de espera aquí, ¿puedo tomarme un tiempo para mejorar esta cosa específica? " (Más bien dicho, pero entendiste el punto: P).

Además, ten en cuenta que 10 desarrolladores antes no redefinieron la base de código, esto puede significar que es una tarea monstruosa, que empeora la situación, en esta situación si algo va a salir mal después de la refactorización será tu falla si el programa ya no funciona correctamente. Solo un pensamiento, pero vale la pena considerarlo.

Answer 8

Estoy en la misma posición ahora, pero con un acuerdo con el administrador de que, cuando la nueva característica se debe implementar en algún módulo existente para volver a factorizar el módulo también (si es necesario volver a factorizar), estamos luchando ahora con el código creado hace 4-5 años y definitivamente descubro que el factorizar el código de otra persona no es trivial ni divertido de hacer, pero es muy útil para la futura reutilización.

Answer 9

Todo el mundo le falta un punto aquí:

Refactoring es parte del ciclo de vida del software de desarrollo.

esto no es solo un RoR o cualquier proyecto específico, sino cualquier otro proyecto de desarrollo de software.

Si de alguna manera puede convencer a su PM why it is important to refactor la base de código existente antes de agregar cualquier característica nueva, ya está. Debería decirle claramente a su MP que cualquier nueva adición de características nuevas sin refactorización llevará más tiempo del requerido. E incluso si se agrega la función, de alguna manera, las sesiones de resolución de errores tomarán incluso más tiempo ya que el código es muy abultado y no se puede mantener.

Realmente no entiendo por qué las personas olvidan el principio de optimizar más tarde. La optimización posterior también incluye refactor más tarde en mi humilde opinión.

Una cosa más, al tomar decisiones de diseño, debe decirle las consecuencias, buenas o malas, a su PM muy muy claramente.

Puede crear una rama diferente (supongo que está utilizando git) para refactorizar y comenzar a agregar una nueva función en alguna otra rama si su PM insiste en agregar una nueva función junto con la refactorización.

Answer 10

El código de refactorización que es parte de la codificación, por lo que no necesita obtener la aprobación de nadie a menos que su gerente esté observando MUY de cerca su código u horas. El tiempo que guardo la refacturación hoy es el momento en que no tengo que facturar haciendo trucos locas para que el código normal funcione mañana (así que funciona, al final).

Combinar los métodos en métodos más pequeños y eliminar los métodos que no se utilizan es parte de su trabajo. También es necesario reducir las llamadas a DB, en el código que usted llama, para que su código no sea una mierda. Una vez más, en realidad no se está refabricando, solo se trata de una codificación normal.

Convencer a su gerente depende de otros factores, que incluyen (pero no se limitan a) su disposición a convencerse y su capacidad para convencer.

De todos modos, ¿qué es la refactorización masiva en RoR? Incluso si la "arquitectura central es simplemente incorrecta", por lo general se puede enderezar un poco a la vez. Asegúrate de dividirlo en fragmentos/usar ramas para no romper nada mientras estás ocupado arreglando.

Si esto es imposible, entonces vuelve a la cuestión social de cómo convencer a su gerente. Esa es una simple cuestión de averiguar cuáles son sus botones y empujarlos sin que los despidan ni arresten.Avergonzar, retener alimentos, dar premios, ser un amigo, amenazas de secuestro anónimas en las que intervenir y salvar el día ... Es muy simple, realmente: ¡la creatividad es la clave!