¿Cómo argumentar en contra de reducir los estándares de calidad para la base de código heredada? [cerrado]

28

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?

code-quality static-analysis legacy-code

— keiki
fuente

2

Cuál es la discusión sobre la reducción de los umbrales de la herramienta? ... o lo entendí mal. Está escrito de manera confusa.

— Dagnelies

13

¿Cómo le explico $ {something} a $ {alguien}?

— mosquito

44

La pregunta tiene algunas partes muy poco claras. "reducir esas infracciones": ¿quiere decir reducir la cantidad real de infracciones (reescribiendo el código anterior), la cantidad de reglas probadas por Sonar en la base de código heredada o la cantidad de reglas de su estándar de codificación que desea seguir? al cambiar algo en el código heredado?

— Doc Brown

44

También tenemos un producto heredado de terrible calidad de código. Como será reemplazado por el nuevo producto, casi no tiene valor limpiar ese viejo código. Eso significa: aceptamos un estándar más bajo en la base del código heredado.

— Bernhard Hiller

44

@keiki: todavía no está claro: ¿la nueva base de código está lo suficientemente separada como para tener diferentes reglas de validación para el código antiguo y el nuevo? ¿Qué pasa con las partes que cambia en la base de código heredado? ¿Su problema es que elevar las partes cambiadas al estándar más alto causa demasiado esfuerzo, o es que no puede separar esas partes en la validación de Sonar, para hacer posible validar solo esas partes cambiadas en su totalidad?

— Doc Brown

73

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.

— Brendan
fuente

15

Creo que hay otra dimensión en esta discusión que es el profesionalismo, en muchas profesiones, si su jefe le pide que corte atajos, puede negarse a hacerlo en base a una base moral (a veces incluso la ley lo respalda), no lo hago. entender por qué los desarrolladores de software deberían comportarse de manera diferente.

— Alessandro Teruzzi

21

@AlessandroTeruzzi Puede negarse a hacer cualquier cosa por motivos morales (personales) en cualquier lugar sin importar su profesionalismo. Sin embargo, no garantiza que seguirá trabajando en ese lugar.

— Kromster dice que apoya a Mónica el

Además, las bases de código a menudo son extremadamente complicadas, sería difícil probar cualquiera de las cosas mencionadas a pesar de que un desarrollador experimentado podría saber por experiencia que cortar las esquinas será costoso a largo plazo.

— mkataja

17

No hay nada malo en esta respuesta, pero sin embargo, en mi humilde opinión, no es útil para la mayoría de las situaciones del mundo real. Mejorar la calidad de una base de código a menudo reducirá el costo de mantenimiento, especialmente a largo plazo, pero estos efectos rara vez son cuantificables. Por lo tanto, a menudo es una decisión estratégica.

— Doc Brown

2

@DocBrown Estoy de acuerdo tentativamente, pero creo que el desarrollo impulsado por el número de anidados, a la OP, no es un enfoque efectivo para mejorar una base de código heredada.

— brian_o

44

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.

— John Forkosh
fuente

2

Esto responde a una pregunta "¿Debería reescribirse el legado?". Pero OP no pregunta cómo solucionar las advertencias o si debería reescribirse. La pregunta era sobre el estándar de calidad, básicamente un requisito para que cada cambio no aumente el conteo de advertencias de validación.

— Basilevs

9

Esto aborda directamente la pregunta, que no se trata de reescribir. El OP quiere argumentar a favor de "tratar el mantenimiento del código heredado de la misma manera que lo haría con un nuevo desarrollo". Esta respuesta dice "¡WOAH! ¡No deberías hacer eso!" Puede que no sea la respuesta del OP o que quisiste escuchar, pero responde completamente a la pregunta.

— Jonathan Eunice

1

@Basilevs (y @ JonathanEunice). Lo que dijo Jonathan. Y tenga en cuenta que comencé diciendo directamente "olvide la herramienta, no es aplicable a la situación", que aborda directamente la pregunta, aunque de manera negativa. Pero como dice el dicho, si vas a criticar, ofrece una crítica constructiva. Así que no podía simplemente decir "no hagas eso". También tuve que sugerir qué hacer en su lugar (y eso se volvió un poco más largo de lo que esperaba cuando comencé a escribirlo).

— John Forkosh el

1

Cuando trabajo con proyectos de código heredado, a veces me gusta diseñar una capa de interfaz que se encuentre entre el código antiguo y el nuevo. Eso permite una división limpia entre las partes viejas y nuevas, y hace que sea más fácil solucionar los problemas de las nuevas partes que si estuvieran engomados con un montón de código que no entiendo.

— supercat

@supercat Si eso se puede hacer, sin duda es un buen enfoque. Pero recordando varios de mis proyectos de remediación de y2k, solo tenía que "sumergirse" en el medio del código existente y jugar con él. No es posible (re) factorizar en viejo / nuevo posible (sin >> masivo << reescribir). Por ejemplo, en lugar de agregar dos bytes a los campos de fecha para un año con formato ccyy de cuatro bytes, que requiere actualizaciones al por mayor para bases de datos masivas, simplemente interprete yy> 50 como 19yy e yy <= 50 como 20yy. Pero la única implementación sensata para eso implica muchos pequeños cambios en cada lugar yy se utiliza.

— John Forkosh

13

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.

— gnasher729
fuente

2

Una vez llegué a un proyecto que se realizó rápidamente (se ignoraron las advertencias del compilador, etc.). El proyecto fue un desastre, hubo un error. Un número se desbordaba. El equipo estuvo buscando durante 2 semanas. Configuré el entorno del compilador con todos los indicadores de advertencia (el recuento pasó de 500 a varios miles de advertencias). Revisé todas las advertencias. Después de solo 3h, tuve 0 advertencias. Por alguna razón, el código funcionó. Pero no sabíamos por qué. Cometí el código en cada cambio en mi sucursal. Después de un poco de búsqueda lo encontré. Una función declarada implícitamente, que hizo que C sea ilegible el valor de retorno.

— CodeMonkey

7

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 ..."

— nigel222
fuente

2

¿Te refieres a Western Digital ? ¿Fue este retiro ? ¿Puedes proporcionar alguna fuente para respaldar tu historia?

— Lightness compite con Monica el

3

Estoy bastante seguro de que se refiere a Digital Equipment Corp, cuya tenue luz aún puede vivir en el corazón negro de Hewlett Packard.

— John Hascall

1

Sí, digital también conocido como DEC.

— nigel222

5

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.

— Basilevs
fuente

Podría hacer una excepción con la palabra siempre al final de su primer párrafo. Si, por ejemplo, se necesitan unas pocas docenas de líneas de cambios en el medio de una función de varios cientos de líneas cuyo estilo genera advertencias, todavía intentaré seguir el estilo existente, siempre y cuando no tenga fallas grado de ilegibilidad. Quiero hacer la vida lo más fácil posible para el próximo pobre hombre que se presente y tenga que lidiar con las cosas. Mezclar estilos sin otro motivo que satisfacer los estándares de algunas herramientas es en sí mismo un mal estilo. En cambio, siga los estándares / estilo originales tanto como sea posible.

— John Forkosh

He dicho cometer, no línea o función. Supuestamente, usted limpia lo suficiente en su edición para tener un presupuesto para un lugar problemático.

— Basilevs

3

Control de riesgo….

El código en la base de código heredada grande se ha probado al menos mediante el uso real del software.
Es muy poco probable que el código en la base de código heredada grande esté cubierto por pruebas unitarias automatizadas.
Por lo tanto, cualquier cambio en frío en la gran base de código heredada es de alto riesgo.

Costo….

Hacer que el código pase un verificador de código mientras está escribiendo el código es barato
Hacerlo en un estado posterior es mucho más costoso

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.
El código simple es más claro y tiende a ser más fácil de entender, a menos que el código complejo se divida en métodos cortos por alguien que no lo entienda ...

Recomendación….

Si se muestra que una sección de código tiene muchos errores, o necesita muchos cambios para agregar funciones adicionales, entonces dedique el tiempo al 100% a comprender lo que hace.
También pase el tiempo agregando una buena prueba de unidad a esa sección de código, ya que tiene una necesidad comprobada de ellos.
Entonces podría considerar refactorizar el código (ahora lo comprende) para que también pase la nueva verificación del código.

Experiencia personal ...

En otros 20 años de trabajo como programador, nunca he visto un caso en el que el cambio ciego de edad para eliminar toda la producción de un nuevo verificador estándar de codificación tuviera algún beneficio además de aumentar los ingresos de los contratistas que se les indicó que lo hicieran.
Del mismo modo, cuando se debe hacer que el código anterior pase las revisiones de código (TickIt / ISO 9001 se hizo mal) que requirieron que el código antiguo se pareciera al nuevo estándar de codificación.
He visto muchos casos en los que el uso de herramientas de verificación estándar de codificación en código nuevo ha tenido grandes beneficios al reducir los costos continuos.
Nunca he visto a una empresa fallar en los costos de mantener el código antiguo que se usa en un producto con muchos clientes.
He visto fracasar a la compañía por no obtener los ingresos de los clientes por ser demasiado lenta para comercializar ...

— Ian
fuente

0

¿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.

— dagnelies
fuente

0

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.

— MrSmith42
fuente