Tenemos aquí una gran base de código heredado con código incorrecto que no puede imaginar.
Definimos ahora algunos estándares de calidad y queremos cumplirlos en una base de código completamente nueva, pero también si toca el código heredado.
Y aplicamos aquellos con Sonar (herramienta de análisis de código), que ya tiene algunas miles de violaciones.
Ahora surgió la discusión para reducir esas violaciones del legado. Porque es legado.
La discusión trata sobre las reglas de legibilidad. Como cuántos ifs / for anidados ... puede tener.
Ahora, ¿cómo puedo argumentar en contra de reducir nuestra calidad de codificación en código heredado?
Respuestas:
El código es solo un medio para un fin. Lo que puede ser ese fin varía, pero generalmente es el beneficio.
Si es ganancia; luego, para argumentar con éxito cualquier cosa que desee demostrar que mejorará las ganancias, por ejemplo, aumentando las ventas, reduciendo los costos de mantenimiento, reduciendo los costos de desarrollo, reduciendo los salarios, reduciendo los costos de reentrenamiento, etc. Si no puede / no demuestra que lo hará mejorar las ganancias; entonces estás diciendo que sería una forma divertida de tirar el dinero al inodoro.
fuente
Yo, yo y yo, hemos sido productores y mantenedores de código heredado. Si su herramienta está generando "miles de violaciones" (o incluso cientos para el caso), olvide la herramienta, no es aplicable a la situación ...
Supongo que los desarrolladores originales se han ido y no están disponibles para discusión. Así que no hay nadie que comprenda los por qué y los por qué del diseño y el estilo de codificación. Corregir cientos o miles de violaciones no será cuestión de reescribir algunas líneas de código aquí y allá. En cambio, indudablemente requiere refactorización / descomposición funcional. Intenta hacerlo en cualquier base de código existente grande, sin comprender íntimamente su diseño actual, y está obligado a introducir un conjunto completamente nuevo de errores / problemas / etc. Solo una nueva lata de gusanos aún peor que la que tienes ahora (o peor que tu herramienta >> piensa << que tienes ahora).
El único enfoque sensato para abordar "miles de violaciones" sería reescribir desde cero. Un esfuerzo largo y costoso, y casi imposible de vender a la gerencia. Y en este caso probablemente tengan razón ...
El código heredado generalmente solo requiere ajustes. Como para y2k, o cuando las acciones pasaron de 256 a decimales. Hice un montón de ambos que cr * p. Y muchas otras cosas similares. Por lo general, es bastante "preciso" en el sentido de que puede "leer" el estilo a veces malo, la descomposición funcional mala, mala, etc., y localizar la colección de lugares que deben modificarse. Y luego, lo que sucede "entre esos lugares", es decir, cuál es el flujo de más alto nivel, puede seguir siendo un misterio para usted. Solo asegúrese de comprender la funcionalidad localizada que está cambiando, y luego pruebe, pruebe, pruebe cualquier efecto secundario, etc., su conocimiento localizado no podrá anticipar.
Si no puede ver el código de esa manera, es posible que no sea la mejor persona para mantener el código heredado. Algunas personas pueden comenzar con una pantalla en blanco y escribir programas hermosos, pero no pueden comenzar con una gran base de código del código de otras personas y mantenerlo. Otras personas pueden mantener el código, pero no pueden comenzar desde cero. Algunos pueden hacer ambas cosas. Asegúrese de que las personas adecuadas mantengan su código heredado.
En ocasiones, es posible que desee rediseñar y reescribir su base de código heredada desde cero cuando los requisitos comerciales (u otros) cambian a tal punto que los "ajustes" del asiento del pantalón simplemente ya no pueden adaptarse a los requisitos modificados. . Y en ese punto, también podría comenzar escribiendo un nuevo documento de requisitos funcionales en primer lugar, asegurándose de que todos los interesados estén a bordo. Básicamente es un juego de pelota completamente nuevo.
Lo único >> incorrecto >> que hacer es tratar el mantenimiento del código heredado de la misma manera que lo haría con un nuevo desarrollo. Y esa cosa equivocada parece ser exactamente el camino que le gustaría seguir :) Tome mi palabra, eso no es lo que quiere hacer.
fuente
La pregunta no es qué tan bueno o malo es ese código. La pregunta es cuántos beneficios obtiene de cuánta inversión.
Entonces tienes una herramienta que encuentra miles de cosas que no le gustan. Tiene la opción de ignorar los resultados de la herramienta o invertir trabajo para cambiar miles de cosas. Eso es un montón de cosas. Las personas no estarán enfocadas, no mientras hagan los cambios, no mientras las revisen, y esto no se probará adecuadamente porque lleva años descubrir cómo probar (o simplemente probar) cada cambio, por lo que habrá errores. Por lo tanto, hasta que encontró y corrigió esos errores, invirtió mucho tiempo y dinero con un resultado negativo general.
Por otro lado, las herramientas pueden encontrar cosas que no solo "no les gustan", sino que son errores o errores potenciales. Si el código heredado todavía se usa ampliamente, entonces la herramienta adecuada puede encontrar errores. Por lo tanto, activar las advertencias del compilador una por una, verificar si son útiles (no todas son útiles) y corregir esas advertencias puede valer la pena.
fuente
Si no está roto, no lo arregles
Esto prácticamente debería estar tatuado en todos los desarrolladores y gerentes de software para que nunca lo olviden.
Sí, rompe todas las convenciones modernas de codificación. Sí, está escrito en FORTRAN-77 con un contenedor en C para que se pueda invocar desde Python. Sí, esos son GOTO no estructurados. Sí, hay una subrutina de tres mil líneas de largo. Sí, los nombres de las variables solo tienen sentido para un croata. etcétera etcétera.
Pero si se ha probado con ira durante una década o más y ha pasado, ¡déjalo en paz! Si la modificación necesaria es pequeña, manténgala lo más pequeña y local posible. Cualquier otra cosa corre el mayor riesgo de romper algo que no necesitaba ser reparado.
Por supuesto, a veces te das cuenta de que realmente es un problema imposible de mantener y que la única forma de adaptarse a la modificación "pequeña" es reescribir desde cero. En cuyo caso, debe volver a quien solicite el cambio y decirle lo que costará (tanto en dólares como en horas-hombre para la reescritura, y en sudor de sangre y lágrimas por los inevitables nuevos errores).
Hace mucho tiempo hubo una serie de fallas en una de las unidades de disco de Digital. Terminaron recordando y reemplazándolos a todos a buen precio. Aparentemente había una gota de pegamento sosteniendo un filtro dentro del HDA. El manifiesto de ingeniería decía del pegamento "No especificado paramétricamente, NO SUSTITUTOS ACEPTABLES". Un contador de frijoles "guardado" por debajo de un centavo por unidad de disco al obtener algún otro pegamento. Emitió un vapor dentro del HDA que mató el disco después de un par de años en servicio. No estaba roto hasta que lo arregló. Sin duda "fue solo un pequeño cambio ..."
fuente
Definitivamente no tiene sentido reducir el nivel de calidad del código heredado. Tampoco es necesario corregir las advertencias de inmediato. Solo asegúrese de que todos sus "nuevos" cambios en cada componente de su proyecto sigan un estándar de alta calidad. Es decir, no commit debería aumentar el conteo de advertencias nunca
Es un enfoque uniforme y totalmente simple.
Permite que el antiguo código heredado funcione tal como está (porque no se le realizan modificaciones innecesarias). Asegura que el nuevo código sea de alta calidad. No hay costos adicionales involucrados.
fuente
Control de riesgo….
Costo….
Beneficio
Espera que mantener un estándar de codificación conduzca a un mejor diseño del código.
Pero es muy poco probable que tener a alguien que pase muchas semanas cambiando el código solo para eliminar las advertencias de una herramienta de verificación estándar de codificación, dará como resultado una mejora en el diseño del código.
Recomendación….
Experiencia personal ...
fuente
¿Es la discusión acerca de bajar los umbrales de la herramienta? ... o lo entendí mal. Está escrito de manera confusa. Si no es así, descarte mi respuesta.
En mi humilde opinión, sería una buena idea reducir la sensibilidad de la herramienta. ¿Por qué? Porque destacaría las piezas de código más peludas. La alternativa es producir informes con miles de violaciones, que se vuelven inútiles por su gran tamaño.
... aparte de eso, solo háblalo con las personas involucradas y escucha sus razones también.
fuente
Intentaría separar el código heredado del nuevo código limpio. En, por ejemplo, Eclipse puede hacer esto colocándolos en diferentes proyectos que se utilizan entre sí. proyecto 'limpio' y proyecto 'legado' .
De esta forma puede analizar ambos proyectos en sonar con diferentes estándares de calidad. Los estándares solo deberían diferir en la importancia de las reglas. Las reglas en sí deberían ser las mismas. De esta manera, puede ver en el proyecto 'heredado' lo que necesita ser 'arreglado' para cumplir con los estándares del proyecto 'limpio' .
Siempre que logre elevar un código heredado a los estándares más altos, puede moverlo al proyecto 'limpio'.
En cada día de trabajo no puede lograr elevar cada clase que toca a los estándares del proyecto 'limpio' debido al retraso del tiempo. Pero debe intentar llegar en pequeños pasos intentando mejorar un poco el código heredado cada vez que lo toque.
fuente