¿Cuál es el / hay una forma correcta de decirle a la administración que nuestro código apesta?

Asegúrate de que no estás exagerando. Usted es nuevo, probablemente no haya trabajado en muchos (¿otros?) Otros lugares, y por eso no está preparado para el mundo del "código de la vida real". El código de la vida real es una cosa horrible. Es como su buen código escolar y su código de proyecto personal, obsesivamente modificado, tuvo relaciones sexuales en el sótano de un reactor nuclear y el bebé creció en una alcantarilla de desechos tóxicos; Es un mutante horrible.

Pero suponiendo que tienes razón, y el código es tan malo como dices (es decir, peor que el código generalmente malo), entonces tienes razón en preocuparte. Hable con su equipo y determine si todos los demás están de su lado. Se necesitará trabajo para mejorar la situación: si el resto del equipo reconoce el problema pero no le importa, está perdiendo el tiempo.

Siendo un junior, probablemente no estés en posición de liderar. Si usted mismo va a la gerencia, como nuevo empleado que también es un junior, su opinión probablemente no se tendrá en cuenta. Consigue tu desarrollador líder o uno de los tipos más altos involucrados. Nuevamente, si ninguna de las personas mayores está interesada, estás perdiendo el tiempo.

Suponiendo que pueda interesar a algunos técnicos superiores, trabajaría para identificar áreas problemáticas y posibles soluciones. Por ejemplo, si "todo es básicamente una función gigante", la próxima vez que esté trabajando en esa "función gigante" tal vez debería refactorizar un poco. Una vez más, necesitas que todos se pongan de lado. Si quitas pequeñas piezas de tu problema y amp; mejorar pieza por pieza con el tiempo se volverán un problema mucho menor. Cada vez que toque un fragmento de código, considere si se puede mejorar.

No se sentará con la gerencia y dirá 'todo está mal y necesita ser reescrito'. Eso no tiene sentido para ellos: cuesta mucho y es potencialmente muy arriesgado. En su lugar, se les debe informar que hay problemas y que hay un plan para mejorar lentamente a medida que se realizan los cambios. Deben ser educados sobre los beneficios del código mantenible. Esto debe provenir de una persona senior en la que confíe técnica y profesionalmente, no de usted.

¿Completa reescribir? Casi siempre es una mala idea.

En última instancia, no hay mucho que puedas hacer porque eres nuevo. Si nadie quiere mejorar las cosas, entonces reúne tu experiencia y pasas al siguiente lugar.

Lea Joel On Software : cosas que nunca debe hacer. Comprenda su razonamiento, luego lea otro artículo sobre software malo y cómo solucionarlo, escrito por gerentes, no por programadores. Con esta información, podrá presentar un caso para solucionarlo, en términos que los gerentes entiendan y se preocupen por ellos. Consejo: los buenos gerentes no gastan tiempo y dinero basándose únicamente en las opiniones y sentimientos de los programadores sobre lo que se debe hacer.

"Este código es una mierda y necesita reescritura" sin duda se te devolverá, incluso si eres técnicamente correcto.

"Podemos tomar meses del calendario actual del proyecto, costando menos y hacerlo más confiable". llamará su atención (note la falta de mención del CÓMO pretende hacer esto en su etapa.

Lo que digas, asegúrate de que tienes razón. Si dices que es malo, tu reescritura debe ser muy buena. Si dices que tomará una semana, es mejor que estés seguro de que será una semana y que sea bueno. Cualquier defecto en el código reelaborado le costará, personalmente, caro, independientemente de lo que pueda haber ocurrido si no hubiera hecho el retrabajo. Si alguien ha estado allí antes que usted y ha arruinado o sobrevendido una reescritura, renuncie, a los gerentes no les gusta que los engañen y no lo dejarán pasar dos veces. Con ese token, no lo arruines para los que lo siguen, solo tienes una oportunidad con esto ...

Encuentre formas de distribuir el costo en un período de tiempo o en la cantidad de proyectos. Los gerentes odian el riesgo, la inversión especulativa y el flujo de efectivo negativo: trabaje dentro de las tolerancias de estos gerentes. Comience con una sugerencia pequeña, de bajo riesgo y bajo costo. Una vez que tengas la razón, puedes ir por el pez más grande.

En primer lugar, encontrará cosas divertidas de legado en cualquier lugar donde trabaje como programador, a menos que trabaje en una empresa de nueva creación y usted sea el que cree el código original de legado. Tienes que ser capaz de rodar con estos golpes si planeas tener una carrera en la programación.

En segundo lugar, a menudo existen consideraciones de costo para mejorar los sistemas antiguos. Por ejemplo, he visto más de una compañía que tenía aplicaciones VB6 y ASP clásicas de 10 años todavía en funcionamiento. En algunos casos, esto se debió a que un gran proyecto para mover .NET falló mal. En otros, la razón era "si no está roto, no lo arregles". Pero, en otros, el costo de la mudanza es justificable ya que los problemas causados por el sistema heredado son demasiado grandes para ignorarlos.

En situaciones donde ha habido un gran fracaso en el pasado, es casi imposible lograr un cambio. En ese caso, pule su currículum y comience a buscar un nuevo trabajo. Si no está roto, es probable que no tenga motivos para quejarse del código en sí, pero que no estaba en una trayectoria profesional satisfactoria y en crecimiento. Si está roto, y parece que está en tu caso, es cuando tienes la oportunidad de cambiar.

El mejor enfoque que he visto es no morder demasiado sino comenzar con cambios incrementales que tendrán el impacto más positivo. Según su descripción, una mejor gestión de las solicitudes de cambio sería un lugar para comenzar. Una vez que esté bajo control, puede comenzar a buscar la creación de un marco de servicio u otras mejoras incrementales de diseño / código.

El peor enfoque que he visto es tratar de dar un gran salto directamente desde un sistema heredado al más reciente y mejor, por ejemplo, saltando de un sistema VB6 / Classic ASP / COM + en funcionamiento a un MVC / Entity Sistema marco.

"Hey Boss, después de Big Project, a mí y al equipo nos gustaría algún tiempo, idealmente X meses, para organizar nuestro código. Las cosas que deberían poder hacerse en minutos llevan horas porque todo está muy desorganizado. Si no lo está posible hacerlo justo después de Big Project, nos gustaría planificar un calendario realista ".

(parcialmente parafraseado del comentario de Azkar sobre la pregunta)

Comience a leer Joel on Software (Joel Spolsky / Fundador de Stack Exchange) ...

Lo PRIMERO que haría es realizar una Joel Test .

Esto te permitirá presentarlo como "Mientras buscaba formas de mejorar como desarrollador ... Me topé con esta prueba de 12 preguntas sobre entornos de desarrollo, así que por diversión les respondí sobre dónde trabajo". ... Esto, a su vez, lo convierte en un tercero que describe qué está mal con su código y no con usted personalmente.

A medida que lea más sobre Pragmatic Practices , se estará mejorando e implementando cosas como red / green / refactor y esto a su vez, le permitirá limpiar el código base para que se pueda mantener. (con el tiempo)

Espero que ayude! Bienvenido a Programación (el código de ayer por lo general apesta) ;-)

Sugerencia rápida: si propone una gestión con una lista de razones por qué debería codificar de manera diferente, incluya como argumento "Mejora de la moral / condiciones de trabajo para los programadores".

Deje en claro que el equipo técnico estará más contento escribiendo y manteniendo un código limpio que este desorden actual, y esto ciertamente puede mejorar su actitud hacia el trabajo. Podría ser un argumento útil.

• ¿La gerencia realmente dicta el diseño? Si tienes a la mayoría del equipo detrás de ti, ¿qué te detiene? Sea proactivo y decida en grupo. Cree un plan para implementarlo de manera incremental . Entonces hazlo.
• ¿La administración dicta las herramientas de desarrollo que utiliza? A menos que haya un costo de tiempo para cambiar una herramienta, la administración generalmente no le importa. Sea proactivo y decida en grupo qué herramientas de desarrollo desea utilizar. Si necesita comprar de la administración, muéstreles un plan de migración y un análisis de costo-beneficio. entonces hágalo.
• ¿La administración dicta los idiomas que usa? Sea proactivo y decida como grupo qué usar en lugar de VBScript. Cree un plan para implementarlo de manera incremental y hágalo. Si necesita que la gerencia compruebe, muéstreles el plan. Entonces hazlo.
• No tengo nada para las especificaciones. Por lo general, eso depende en gran medida de las personas y los procesos en su trabajo. Identificar qué está roto y los cambios mínimos requeridos para arreglar el proceso lleva tiempo, el análisis y la comprensión de cómo funcionan las cosas actualmente y cómo deberían funcionar. Si sabe que puede idear un plan e intentar convencer a la administración.

Obtendrá más cambios y respeto si propone formas de cambio que no impliquen una gran cantidad de tiempo dedicado sin valor empresarial (o suave) para demostrarlo.

Hablando por experiencia: No es fácil. Es casi imposible. A la administración no le importa que el código apeste y es muy probable que sea completamente ignorante y / o que no tenga ni idea de los problemas que se enfrentan, o lo habrían solucionado hace mucho tiempo y usted no se quedaría con él hoy. Lo mejor que puedes hacer es hacer una lista de las razones por las que el código apesta, y luego el razonamiento detrás de por qué apesta para demostrar el valor real del negocio al refactorizarlo / reescribirlo.

Un ejemplo podría ser para "El código no se puede mantener":

El código actual no se puede mantener debido a X , Y y Z (enumere las razones por las que no se puede mantener). Esto hace que las solicitudes de cambio y las nuevas funciones sean muy difíciles de hacer, porque X , Y , Z (las razones por las que es difícil hacer cambios). Debido a que los cambios son difíciles, el equipo de desarrollo no puede responder fácilmente a las correcciones de errores y mejoras.

Su única esperanza es que su jefe y la alta gerencia no sean tan estúpidos como para entender las ramificaciones que tiene el código, y están dispuestos a dejar de presentar nuevas solicitudes de características para abordar los problemas; de lo contrario, sus esfuerzos van a ser en vano Hablando de experiencias pasadas, es muy probable que no vean nada incorrecto con el código y / o que sus compañeros de trabajo no estén tan contentos como para llevar sus inquietudes a la gerencia.

Buena suerte. Lo necesitarás.

"Empecé recién salido de la universidad": debería responder a tu pregunta.

La administración probablemente sepa que el código no es óptimo. La mayoría del código es a menos que hayas contratado a Ray Gosling, Guido Van Rossum u otra persona realmente buena y costosa para escribirlo.

La administración también sabe que funciona con cualquier definición de "obras" que se aplique a su empresa (no falla, vende, entrega los informes o lo que sea).

Quieren que mantengas el código "funcionando" a un costo mínimo. No quieren una propuesta para un proyecto costoso para reescribir todo.

El caso de negocios es casi imposible de hacer porque su entregable es un software funcional (lo que ya tienen) no es un código elegante.

Agregue el hecho de que, en el software, hay un gran costo de oportunidad de ingresar al mercado con características primero. Si realmente lo piensa, el reembolso a largo plazo del tiempo de inversión no está garantizado.

Dicho esto, sigue siendo un buen plan para refactorizar y arreglar las cosas pequeñas (como obtener un buen VSS) en el camino en bocados manejables. En última instancia, este es un problema técnico, no de gestión. Solo haga lo que se necesita hacer mientras sigue cumpliendo lo que promete y estará bien. Es probable que a la gerencia no le interesen los detalles esenciales de la calidad del código, incluso si usted tiene un caso sólido.

Solo váyase tan pronto como pueda (tal vez no se vaya demasiado pronto, ya que no quiere verse como un puesto de trabajo). El hecho de que el código sea un desastre y que la gente se quede allí significa que es probable que esté trabajando con desarrolladores pobres. Cualquier desarrollador decente que se preocupe por su trabajo no se quedaría mucho tiempo trabajando en esa mierda.

La posibilidad de que una reescritura sea bastante baja a menos que pueda demostrar claramente que valdrá la pena la inversión $$$ $.

A la gerencia no le importa el código. Se preocupan por tener un producto para vender.

Si el sistema heredado es realmente malo realmente y está agregando una cantidad ridícula de gastos generales para la mayoría del equipo (digo mayoría porque siempre hay un tipo que codifica grandes trozos o todo y lo conoce como la parte de atrás de su mano) luego acérquese a ellos y diga que le está costando dinero al negocio en tiempo de desarrollo, y tendrá repercusiones en la satisfacción del cliente.

Pero, una vez más, todavía no les importa el código, les importa un producto, por lo que si bien esa respuesta podría hacerlos decir "Sí, vamos a hacerlo", es mejor que ordenen el código sin pedir permiso a un manager. No exageres, asegúrate de hablar primero con el equipo, a nadie le gusta venir e intentar usar esa función que te tomó 3 meses para escribir y ahora parece que no funciona porque ha sido hackeado.

Enfoque la administración de tal manera que demuestre que comprende los impactos presupuestarios de realizar grandes cambios en el código y los impactos presupuestarios de NO realizar los cambios. Me gustaron las palabras de Emilio.

Es importante tener en cuenta que el código "antiguo" siempre será horrible. Con esto quiero decir, todos crecemos como desarrolladores constantemente. Escribimos un buen código, luego aprendemos a escribir un mejor código más adelante y el código "bueno" anterior parece terrible. Demasiados desarrolladores quedan atrapados en tratar constantemente de mejorar y desperdiciar más dinero a largo plazo. Es un acto de equilibrio. Dicho esto, siempre es bueno si puedes mejorarlo a medida que avanzas. Cuando vayas a modificar esa función gigante, ¡divídelo! Eventualmente llegarás a algún lugar.

No lo hagas.

Reescribir un proyecto grande desde cero es un gran error la mayoría de las veces de todos modos.

Nunca pensé que fuera fácil decirles a los gerentes, especialmente a los gerentes de proyecto, sobre el código incorrecto y la refactorización. Primero, deben confiar en usted, incluso si usted es un hombre de alto nivel, aún necesita tiempo para ser de confianza. En segundo lugar, simplemente no entienden lo grave que es el problema. Si hoy es el último día para lanzar una nueva compilación, y la compilación falla. Saben lo serio que es, pero nunca saben que la compilación simplemente falló debido a muchos problemas, como códigos incorrectos, pruebas inadecuadas, etc.

He realizado tareas de configuración e implementación en un proyecto web. A menudo lleva mucho tiempo solucionar problemas inesperados cada vez que implemento una nueva compilación. La mayoría de los problemas fueron la seguridad y la integración (entre varias aplicaciones web / Windows). Nuestro código apesta, el código de los demás apesta, son completamente códigos de espagueti.

Estábamos planeando una nueva versión y pedí encarecidamente una refactorización, simplemente agregue un registro detallado al código de inicio de sesión / autenticación donde a menudo ocurrían los errores. Los gerentes estuvieron de acuerdo, pero luego se colocó en una lista agradable y no sé si se hará ya que ya contábamos con una gran lista de características y un marco de tiempo ajustado.

Hay dos tipos de gerentes: los que pretenden entender lo que haces y los que no. Los que pretenden entender el software te serán hostiles. Los que no lo hacen simplemente están molestos por ti.

En cualquier caso, los administradores son todos mentirosos, por lo que tienen una fuerte disposición para asumir que todos los demás lo son.

Lo que quiero decir es que si dice que el software no está actualizado, lo tomarán como una excusa. A ellos no les importa.