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

Nuestro código es malo. Puede que no siempre se haya considerado malo, pero es malo y solo va cuesta abajo. Empecé recién salido de la universidad hace menos de un año, y muchas de las cosas en nuestro código me desconciertan. Al principio pensé que, como el nuevo chico, debía mantener la boca cerrada hasta que aprendiera un poco más sobre nuestra base de códigos, pero he visto muchas cosas para saber que es malo.

Algunos de los aspectos más destacados:

• Todavía usamos marcos (intente sacar algo de una cadena de consulta, casi imposible)
• VBScript
• Fuente segura
• 'Usamos' .NET; con eso quiero decir que tenemos envoltorios .NET que llaman a COM DLL, por lo que es casi imposible depurar fácilmente
• Todo es básicamente una función gigante.
• El código no es mantenible. Cada página tiene varios archivos que se crean cada vez que se crea una nueva página. Básicamente, la página principal hace Response.Write () varias veces para representar el HTML (runat = "server"? De ninguna manera). Después de eso, puede haber mucha lógica en el lado del cliente (VBScript), y finalmente la página se envía a sí misma (a menudo almacena muchas cosas en campos ocultos) donde luego se publica en una página de procesamiento que puede hacer cosas como guardar el datos a la base de datos.
• Las especificaciones que obtenemos son ridículas. Muchas veces requieren cosas como "rellenar automáticamente el campo X con el campo Y o el campo Z" sin indicación de cuándo elegir el campo Y o el campo Z.

Estoy seguro de que parte de esto es el resultado de no estar empleado en una compañía de software, pero siento que las personas que escriben software deberían al menos preocuparse por la calidad de su código. Ni siquiera puedo imaginar que si mencionara algo, cualquier cosa se haría pronto, ya que se acerca un gran plazo, pero seguimos escribiendo códigos incorrectos y usando malas prácticas.

¿Que puedo hacer? ¿Cómo puedo plantear estos problemas? El 75% de mi equipo está de acuerdo conmigo y ha mencionado estos problemas en el pasado, pero nada cambia.

Asegúrate de no estar exagerando. Usted es fresco, probablemente no ha trabajado en muchos otros lugares (y ¿no?), Por lo que no está preparado para el mundo del "código de la vida real". El código de la vida real es algo horrible. Es como su código de escuela agradable y su código de proyecto personal obsesivamente ajustado 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 tenga razón, y que el código es tan malo como usted dice (es decir, peor que el código típicamente malo), entonces tiene razón en preocuparse. Hable con su equipo y determine si todos los demás están de acuerdo. 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 junior, probablemente no estés en condiciones de liderar. Si va a la administración usted mismo, como nuevo empleado que también es un junior, su opinión probablemente será ignorada. Consiga a su desarrollador principal o uno de los más importantes involucrados. Nuevamente, si ninguna de las personas mayores está interesada, entonces está perdiendo el tiempo.

Suponiendo que pueda interesar a algunas personas técnicas de alto nivel, trabajaría para identificar las áreas problemáticas y las posibles soluciones. Por ejemplo, si "todo es básicamente una función gigante", entonces la próxima vez que trabaje en esa 'función gigante' tal vez debería refactorizar un poco. Una vez más, necesitas poner a todos de pie. Si elimina pequeños pedazos de su problema y mejora pieza por pieza, eventualmente se volverán mucho menos problemáticos. Cada vez que toque un fragmento de código, considere si se puede mejorar.

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

Reescribir por completo? 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únes tu experiencia y pasas al siguiente lugar.

Lea Joel On Software : cosas que nunca debe hacer. Comprenda su razonamiento, luego lea algunos otros artículos sobre software defectuoso y cómo solucionarlo, escritos por gerentes, no por programadores. Armado con esta información, podrá presentar un caso para solucionarlo, en términos que los gerentes entiendan y se preocupen. Sugerencia: 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 ser reescrito" sin duda va a ser devuelto a usted, incluso si es técnicamente correcto.

"Podemos quitarnos meses del cronograma actual del proyecto, costar menos y hacerlo más confiable". llamará su atención (observe la falta de mención de CÓMO piensa hacer esto en su etapa).

Lo que usted diga, asegúrese de estar en lo correcto. Si dices que es malo, tu reescritura tiene que ser muy buena. Si dices que tomará una semana, será mejor que te asegures de que será una semana, y sé bueno. Cualquier defecto en el código reelaborado le costará, personalmente, caro, independientemente de lo que podría haber sucedido si no hubiera realizado la reelaboración. Si alguien ha estado allí antes que usted y ha jodido o sobrevendido una reescritura, ríndase, a los gerentes no les gusta que los engañen y no dejarán que suceda dos veces. Por ese motivo, no lo arruines para los chicos que siguen, solo tienes una oportunidad en esto ...

Encuentre maneras de distribuir el costo durante un período de tiempo o número de proyectos. Los gerentes odian el riesgo, la inversión especulativa y el flujo de caja negativo: trabaje dentro de las tolerancias de sus gerentes con respecto a estos. Comience con una sugerencia pequeña, de bajo riesgo y bajo costo. Una vez que tenga la razón, puede ir por el pez más grande.

En primer lugar, encontrará cosas heredadas tontas en cualquier lugar donde trabaje como programador, a menos que trabaje desde el inicio y sea usted quien cree el código heredado original tonto. Tienes que poder rodar con estos golpes si planeas tener una carrera en programación.

En segundo lugar, a menudo hay consideraciones de costos para mejorar los sistemas antiguos. Por ejemplo, he visto a más de una compañía que todavía tenía en funcionamiento VB6 de 10 años y aplicaciones ASP clásicas. En algunos casos, esto se debió a que un gran proyecto para mover .NET falló gravemente. En otros, la razón fue "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 tu currículum y comienza 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 carrera profesional satisfactoria y creciente. Si está roto y parece que está en su caso, es cuando tiene 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 último y mejor, por ejemplo, saltar de un sistema VB6 / Classic ASP / COM + a un sistema MVC / Entity Framework.

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

(parcialmente parafraseado del comentario de Azkar sobre la pregunta)

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

Lo PRIMERO que haría es realizar una Prueba de Joel .

Esto le 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é tiene de malo su código y no usted personalmente.

A medida que lea más sobre Prácticas pragmáticas , mejorará e implementará cosas como rojo / verde / refactor y esto a su vez le permitirá limpiar la base del código para que sea mantenible. (a través del tiempo)

¡Espero que ayude! Bienvenido a la programación (el código de ayer suele ser una mierda) ;-)

Consejo rápido: si propone una gestión con una lista de razones por las que debe 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 escribirá más contenido y mantendrá código limpio que este desastre 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. Elabora un plan para implementarlo de forma incremental . Entonces hacerlo.
• ¿La administración dicta las herramientas de desarrollo que utiliza? A menos que haya un costo de tiempo para cambiar una herramienta de 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 hacerlo.
• ¿La administración dicta los idiomas que usa? Sea proactivo y decida como grupo qué usar en lugar de VBScript. Elabora un plan para implementarlo gradualmente y hazlo. Si necesita una compra, muéstreles el plan. Entonces hacerlo.
• No tengo nada para las especificaciones. Eso suele depender en gran medida de las personas y los procesos en su trabajo. Identificar lo que está roto y los cambios mínimos necesarios para arreglar el proceso requiere tiempo, análisis y comprensión de cómo funcionan las cosas actualmente y cómo deberían funcionar. Si sabe que puede llegar a un plan e intentar convencer a la gerencia.

Obtendrá más cambios y respeto si propone formas de cambio que no impliquen grandes cantidades de tiempo dedicado sin valor comercial (o suave) para demostrarlo.

Hablando por experiencia: no es fácil. Es casi imposible A la gerencia no le importa que el código apesta y es más que probable que sean completamente ignorantes y / o no tengan idea de los problemas que se enfrentan, o lo habrían solucionado hace mucho tiempo y no se quedaría atrapado con él hoy. Lo mejor que puede 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 comercial real al refactorizarlo / reescribirlo.

Un ejemplo podría ser para "El código no es mantenible":

El código actual no se puede mantener debido a X , Y y Z (enumere los motivos por los que no se puede mantener ). Esto hace que las solicitudes de cambio y las nuevas características sean muy difíciles de hacer, porque X , Y , Z (razones por las que hacer cambios es difícil). 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 demasiado estúpidos para comprender qué ramificaciones 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 serán en vano . Hablando de la experiencia pasada, es muy probable que no vean nada malo en el código, y / o sus compañeros de trabajo sean demasiado despiadados para llevar sus preocupaciones a la gerencia.

Buena suerte. Lo necesitarás.

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

La gerencia probablemente sabe que el código es subóptimo. La mayoría del código es a menos que haya contratado a Ray Gosling, Guido Van Rossum u otra persona realmente buena y costosa para escribirlo.

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

Quieren que mantenga el código "funcionando" a un costo mínimo. No quieren una propuesta de proyecto costoso para volver a escribir todo.

El caso comercial es casi imposible porque su entregable es un software que funciona (lo que ya tienen) y no un código elegante.

Agregue el hecho de que en el software hay un gran costo de oportunidad de llegar al mercado con características primero. Si realmente lo piensa, no se garantiza la recuperación a largo plazo de la inversión de tiempo.

Dicho esto, sigue siendo un buen plan 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 administrativo. Simplemente haga lo que debe hacerse mientras sigue cumpliendo lo que promete y estará bien. La administración probablemente no estará interesada en los detalles esenciales de la calidad del código, incluso si presenta un argumento sólido.

Simplemente vete tan pronto como puedas (tal vez no te vayas demasiado pronto ya que no quieres parecer una tolva de trabajo). El hecho de que codifiquen es un desastre y la gente se queda allí significa que probablemente estés trabajando con desarrolladores pobres. Cualquier desarrollador decente que se preocupe por su trabajo no se quedaría mucho tiempo trabajando en esa basura.

La posibilidad de que se produzca una reescritura es bastante baja, a menos que pueda demostrar claramente que valdrá la pena la inversión.

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

Si el sistema heredado es muy, muy malo 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 codificó grandes partes o todo y lo sabe como la parte posterior de su mano) luego, acérquese a ellos y diga que le está costando dinero al negocio en tiempo de desarrollo, y tendrá un efecto positivo con la satisfacción del cliente.

Pero una vez más, todavía no les importa el código, se preocupan por un producto, por lo que si bien esa respuesta puede hacer que digan "Sí, hagámoslo", también podría ordenar el código sin obtener el permiso de un gerente. No se exceda, asegúrese de hablar primero con el equipo, a nadie le gusta venir e intentar usar esa función que le tomó 3 meses para escribir y ahora parece no funcionar porque ha sido pirateada.

Acérquese a 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 gustó la redacción de Emilio.

Es importante tener en cuenta que ese 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 tarde y el código "bueno" anterior parece terrible. Demasiados desarrolladores quedan atrapados constantemente tratando de mejorarlo y desperdiciar más dinero a largo plazo. Es un acto de equilibrio. Dicho esto, siempre es genial si puedes mejorarlo a medida que avanzas. Cuando vaya a modificar esa función gigante, ¡divídala! Eventualmente llegarás a algún lado.

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 es fácil decirles a los gerentes, especialmente a los gerentes de proyecto, sobre códigos incorrectos y refactorización. Primero, deben confiar en ti, incluso si eres un hombre mayor todavía necesitas tiempo para ser confiable. En segundo lugar, simplemente no entienden qué tan grave es el problema. Si hoy es el último día para lanzar una nueva compilación, y la compilación falla. Saben lo grave que es, pero nunca saben que la compilación simplemente falló debido a muchos problemas, como código incorrecto, 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 otros apesta, son completamente códigos de espagueti.

Estábamos planeando una nueva versión y pedí encarecidamente que se refactorizara, solo agregue un registro detallado al código de inicio de sesión / autenticación donde a menudo ocurren errores. Los gerentes estuvieron de acuerdo, pero luego se incluyó en una lista agradable y no sé si se hará ya que ya teníamos 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 comprender el software serán hostiles para usted. Los que no, simplemente están molestos por ti.

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

Mi punto es que si dices que el software está desactualizado, lo tomarán como una excusa. No les importa