Industria del software: ¿cómo trato el código heredado y el código limpio de manera efectiva?

El código heredado es parte del ciclo de vida del desarrollo de software. Trabajamos en un entorno que cambia rápidamente. Esta hermosa clase que estás escribiendo hoy podría considerarse fea y obsoleta en solo unos años. Así que mi primer consejo sería: no hagas juicios si no sabes con seguridad por qué exactamente se decidió en ese momento ir de esta manera en particular. Tal vez, no se conocían todas las opciones, y se ha elegido "la peor" no intencionalmente. Y ahora, como mencionaste, todos conocen mejores prácticas, pero prefieren apegarse a ese estilo por razones de consistencia. Y siendo pragmático, tiene sentido mantener todo de la misma manera, ¿no?

Dicho esto, recomendaría expresar sus ideas de mejora. Tal vez, nadie permitirá volver a escribir todo el asunto. Pero los estándares de codificación son objeto de mejoras continuas, y un equipo saludable lo entiende. ¿Qué tal hacer una presentación sobre por qué los vectores son mejores que las matrices? ¿O iniciar una discusión en un chat o correo electrónico del equipo sobre la idoneidad de las implementaciones personalizadas para objetos estándar? Por supuesto, sería bueno compartir un par de enlaces, digamos, a publicaciones de blogs de grandes nombres de la industria, para fortalecer su posición. Y cuando tenga algún tipo de consenso después de estas discusiones, sea proactivo y cree una encuesta sobre la aceptación de esta idea como estándar a partir de ahora. Aunque no sea aceptado, aprenderás algo que te es desconocido en este momento.

Pero si lo es, verá cuánto puede hacer incluso si el código base es viejo y grande y parece imposible arreglarlo todo. Comience con pequeños pasos: haga que esta regla funcione solo para un nuevo código, incluso si para implementar una nueva función necesita tocar partes antiguas del sistema donde muchos métodos todavía son "feos". A continuación, aplica la regla de los boy scouts.: si ve "el estilo antiguo" en algún lugar del camino y no lleva más de una hora arreglarlo, reescriba. Luego, si corresponde, una verificación automática podría ayudar a detectar todos los lugares que necesitan atención y estimar el esfuerzo real para deshacerse de esto por completo (por cierto, podría ser sorprendentemente pequeño). Y si agrega esta verificación a una canalización, obligará a todos a arreglar esas cosas incluso si su tarea no estaba relacionada con ese método en particular con un "estilo antiguo". Con todo esto algún día desaparecerá, lo prometo.

Y una situación más para demostrar que los cambios son más posibles de lo que piensas. En el mundo de los negocios, necesitamos hablar en términos comerciales. La refactorización por el hecho de refactorizar en sí agrega valor cero, pero cuando pueda demostrar cómo este cambio afectará los resultados, es probable que obtenga luz verde para cualquier solicitud. A veces, el mantenimiento de una parte particular del código es doloroso, mientras que el esfuerzo razonable de reelaboración lo acelerará drásticamente. Te animo a que hables en lugar de luchar con eso. Obtenga algunos números, haga estimaciones aproximadas sobre cuánto tiempo llevará la mejora de funciones con y sin refactorización. Venda este trabajo a su jefe de tecnología/gerente de producto/otra persona influyente relevante según sea necesario, y la elección les parecerá obvia. Después de este éxito, "de repente", tú' Te encontrarás liderando un proyecto para hacer de esta parte de la base de código un lugar donde los estándares de codificación modernos entren en juego. ¡A por ello! ¡Solo asegúrese de tener pruebas para todas las funciones críticas incluso antes de comenzar! ;)

Buena suerte, Miguel.

C++ es algo así como un lenguaje inusual. Las bibliotecas tienden a no verificar errores o límites. Muchos asumen ciertas condiciones para funcionar y depende del desarrollador verificar esas condiciones antes de pasar a la función. Un buen ejemplo es la función strlen que puede causar un desbordamiento de búfer ya que asume un terminador nulo.

Esto provoca un comportamiento inesperado. He visto casos en los que un desbordamiento de búfer provocó la eliminación de un archivo aleatorio en la máquina. Ocurre aparentemente al azar y en momentos y condiciones extraños nunca consistentes. La depuración se volvió casi imposible ya que parece que funcionó. Fue solo después de un accidente que se encontró el error y las condiciones nunca volvieron a ocurrir.

Luego está toda la recolección de basura, punteros colgantes, etc. Existen muchas cosas peligrosas en C++. Su biblioteca puede verificar esas condiciones o realizar un seguimiento de un puntero automático incorporado/recolección de basura.

El punto es que su compañero de trabajo puede haber escrito bibliotecas que verifican las condiciones y los límites. Primero preguntaría directamente por qué no usar la función de biblioteca X en lugar de los métodos internos. Mira lo que dicen.

Además de la excelente respuesta de vladimino, podría sugerirle a su jefe que haga algunas evaluaciones (tal vez medio día por semana).

Las métricas pueden ser:

• rendimiento (tiempo) con implementación propia y con contenedores STL para algunos ejemplos
• Tiempo dedicado a corregir errores relacionados con matrices, etc., por ejemplo, errores fuera de los límites (a menudo difíciles de encontrar)

Entonces, podría construir un caso con números si una refactorización agregaría valor comercial. O tal vez no.

Otra idea sería extender los propios contenedores para hacerlos funcionar con algoritmos STL, es decir, dotarlos de los métodos necesarios.