¿Cómo superas tus propios sesgos de codificación cuando te entregan código heredado? [cerrado]

Como programadores, a menudo nos sentimos muy orgullosos de nuestras habilidades y tenemos opiniones muy fuertes sobre lo que es el código "bueno" y el código "malo".

En cualquier momento de nuestras carreras, probablemente hemos tenido algún sistema heredado en nuestras vueltas, y pensamos '¡Dios mío, este código apesta!' porque no encajaba en nuestra noción de qué buen código debería ser, a pesar del hecho de que pudo haber sido un código perfectamente funcional y mantenible.

¿Cómo te preparas mentalmente cuando tratas de entender el trabajo de otro programador?

Para cualquier base de código heredada, la forma correcta de prepararse mentalmente para lidiar con ella es comenzar escribiendo pruebas unitarias para ella .

Ya sea que apesta o no, ¡primero debes tener la confianza para poder cambiarlo sin romper cosas!

No puedo decirte cuántas veces he dicho "Oh, esto está totalmente mal", lo reescribí y luego descubrí de la manera difícil por qué ese código se escribió de esa manera. Por lo general, es un requisito no obvio no escrito / no documentado. Al menos, eso es cierto en el código heredado en el que estoy trabajando actualmente.

Espera hasta que haya estado lo suficiente como para encontrarse con su propio código heredado. Es una experiencia humillante y parte del proceso de aprendizaje. Añoro el momento en que lo sabía todo.

Creo que Fosco tenía un gran punto para poder ponerlo en el contexto de posibles restricciones de tiempo y funcionalidad. A veces te ves obligado a hacer que algo funcione.

Y por último, comprenda que es por eso que tiene un trabajo.

Ríete de él, trata de no juzgarlo demasiado, y acaba de superarlo. No es bueno ser un verdadero nazi de código ... Definitivamente existe algo como "lo suficientemente bueno" o incluso "lo suficientemente bueno en ese momento". Hay muchas veces en que se desarrolla o se venda algo para solucionar una crisis, y nunca se vuelve a visitar.

Si es realmente malo, vea si puede hacer un caso para reescribirlo ... si no es importante, solo entre y salga.

Escoge tus batallas. Conozca la diferencia entre "No lo escribiría de esta manera" y "esto crea un serio desafío de mantenimiento o soporte"

A menudo me resulta útil tener una idea de lo que los desarrolladores originales pensaban que era bueno.

Busque patrones y temas para lo que hicieron y muchas veces descubre que hubo razones para algunas de las decisiones extrañas en primer lugar.

A veces descubres que el desarrollador original era realmente malo, pero tienes una idea de qué tipo de malo estaban vendiendo en ese momento.

De cualquier manera, después de hacer esto, debería tener una mejor idea de dónde podría comenzar una reescritura o cómo sería una solución rápida sin tener que refactorizar todo.

Lo más importante, no asuma de inmediato que solo porque es feo, es malo. Nada te hace ver más tonto que pasar tiempo modernizando algo solo para descubrir que es menos capaz que el original.

Si tengo tiempo lo ataco y mato el código mal escrito.

Es guerra.

Siempre razono que el código feo es un código que ha visto muchas depuraciones, con muchas sutilezas que no son aparentes con una inspección superficial. Si lo reemplazo, o lo rediseño profundamente, necesito asegurarme de que entiendo absolutamente todos los aspectos de lo que hace el código. Si no tengo tiempo para llegar al fondo, debo adoptar un enfoque de riesgo mínimo, haciendo el menor cambio posible para lograr mis objetivos.

Por lo general, haré una pequeña corrección / cambio, y propondré una característica para el desarrollo posterior que excusaría llegar al fondo de las cosas y refactorizar todo. Luego hago todo lo posible para ignorar el código hasta que la característica termine en la hoja de ruta.

Cuando el código heredado tiene más de un par de años, puede haberse escrito de esa manera debido a las limitaciones en el idioma o los sistemas operativos, etc., que existían en el momento en que se escribió el código. Oye, se ve mal ahora, pero ¿fue malo entonces? Intento asumir que el desarrollador tenía una razón por lo que hizo. Es posible que esa razón ya no se aplique, pero suponiendo que haya una en lugar de solo incompetencia general (los jóvenes programadores pensarán lo mismo sobre su código en 5 años, tal vez incluso menos) lo enojan menos. Si funciona y no hay problemas asociados, conserve ese código heredado, no importa cuán feo sea, ya que le permitirá resolver problemas más emocionantes.

En el pasado, cuando no tenía tiempo para mear en el código de otra persona y convertirlo en "mi" estilo, tuve que recurrir a estar muy motivado por las tareas:

¿Qué estoy tratando de agregar a este código / arreglar / hacer que funcione?

¿Lo que estoy haciendo es lograr ese objetivo? Si no, deja de hacerlo y vuelve a la última vez que estaba haciendo cambios orientados a tareas.

¿Ya terminé con esta tarea? Si es así, deja de jugar con el código, aunque parezca que fue escrito por un molde marciano no sensible.

A menos que esté preparado para poseer el código y las correcciones necesarias en el futuro, no lo toque. Superará la tendencia a querer arreglar algo cuando rompa algo que no escribió porque no lo estudió lo suficientemente bien antes de sumergirse, y le toma 2 días y un simulacro de incendio para que vuelva a funcionar .

No me malinterpreten ... hay razones legítimas para refactorizar el código, pero si una empresa exige que el código funcione y usted lo "arregla" sin saber las consecuencias antes de saltar, está pidiendo un mundo de dolor .

Refactorizar un poco a la vez puede ser útil, pero tenga mucho cuidado al cambiar cualquier pequeño aspecto de cómo se comporta realmente el código a menos que comprenda por qué ese comportamiento está allí y qué afecta. Desafortunadamente, el código que más lo necesita es a veces el más difícil de cambiar sin tocar el comportamiento, aunque generalmente puede enderezar partes de él, o al menos comentarlo.

Estoy trabajando casi exclusivamente en código heredado en estos días y siempre pienso "Oh sh% t, ¿qué estaban pensando?" . Luego empiezo a escribir pruebas unitarias para el código y ese es el punto en el que realmente tengo que analizar el flujo de control y las dependencias.

A veces no es posible escribir fácilmente pruebas unitarias. Pero mientras lo intento, obtengo información sobre el código y entenderé por qué se escribió de la manera en que está. A veces eso demostrará que el código es realmente un desastre, a veces puedo entender el proceso de pensamiento de los desarrolladores originales y puedo agregar documentación útil o reescribir un fragmento de código cuando quiero agregar una nueva funcionalidad.

Para mí, ayuda pensar que mi código se verá igual para mí cuando regrese en 12 meses .

Con la experiencia viene el juicio de saber cuándo el código es realmente malo y cuándo está escrito en un estilo diferente. Si es perfectamente funcional y mantenible y hay una buena cobertura de prueba automatizada , entonces no está mal y solo necesita abrir su mente. Probablemente aprenderás algo. El código incorrecto no es funcional y mantenible.

Aquí hay algunos marcadores de código verdaderamente malo:

• Grandes bloques de lógica han sido duplicados en lugar de refactorizados.
• Dependencias circulares entre clases o paquetes
• Alto acoplamiento; baja cohesión
• Variables no utilizadas, escribir en variables que nunca se leen, código inalcanzable.
• Reimplementación de funciones de biblioteca estándar, por ejemplo, formato de fecha.
• Lógica innecesariamente compleja; es decir, 50 líneas de código donde 10 funcionarían bien.
• No hay comentarios que describan el propósito de las clases o métodos.
• Comentarios engañosos.

La falta de pruebas automatizadas no significa que el código sea malo, pero significa que el proyecto es malo.

Estos no son una cuestión de gustos; Estas prácticas hacen que el mantenimiento del programa sea mucho más costoso.

¿Cómo te preparas?

Acepte el hecho de que lleva un tiempo poder trabajar con éxito en una nueva base de código. Si es "perfectamente mantenible" y hay una alta cobertura de prueba, lleva menos tiempo, pero aún así no sucederá de inmediato. Si el código es malo, lo primero que hago es advertir a los interesados ​​que está en mal estado y que el progreso inicial será lento. Si son escépticos, entonces respaldo mi reclamo mostrándoles una muestra de problemas en el código real y explicando cómo varía de las mejores prácticas de la industria.