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

22

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?

Bryan M.
fuente
2
wow ... esta pregunta es realmente relevante para mí en este momento.
WalterJ89
1
Si no está roto, no lo arregles. :-)
richard
Cosas que nunca debes hacer y Big Ball of Mud deberían ser lecturas obligatorias sobre este tema para todos los programadores.
Jan Hudec
posible duplicado de Trabajar en el código de otra persona
mosquito

Respuestas:

31

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!

Jeff Atwood
fuente
66
+1. Otros programas a menudo dependen de errores en el código existente, sin importar sus formas extrañas de hacer las cosas. Antes de ir a jugar con él, ¡entiéndelo!
Alex Feinman
Tuve este problema una vez. Solucioné un error en nuestras bibliotecas internas, pero resultó que una gran cantidad de código importante dependía de ese comportamiento incorrecto. Yikes
Jonathan Sterling
A veces escribir esas pruebas puede ser muy difícil. Pero luego, a veces puede encontrar un hilo suelto en alguna parte , realizar una prueba unitaria y luego extender aún más la infección de prueba. Por lo tanto, es posible que tenga que refactorizar y probar un montón de cosas antes de llegar a la pieza que realmente quería cambiar.
Frank Shearar el
55
Eso supone que su empresa utiliza, o incluso comprende, las pruebas unitarias. La mayoría de las veces no hay pruebas para el código, no hay documentación y una fecha límite ajustada para integrarlo / arreglarlo / modificarlo, por lo que no puede simplemente "comenzar a escribir pruebas unitarias" para él.
Wayne Molina
2
Para la base de código heredada, a menudo es más fácil comenzar con pruebas de regresión automatizadas. Las pruebas unitarias suponen que hay unidades aisladas en el código que se pueden probar de forma independiente; debe ser muy afortunado de encontrar este tipo de código heredado.
Doc Brown
30

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.

Frank Shearar
fuente
3
Me pasó algunas veces. A veces es mejor dejarlo solo
TheLQ
44
Y si lo descubres, ¡sé amable con el siguiente chico y escribe un comentario!
Frank Shearar
11

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.

JeffO
fuente
44
Me pasa todo el tiempo. Estoy constantemente mirando hacia atrás en el viejo código y pensando: "¿Quién escribió esta basura? Oh, sí ... lo hice". Creo que muestra que estás creciendo como programador si puedes admitir que algún código que escribiste en el pasado es malo. Si miras hacia atrás y dices "Sí, me parece bien", o es un código muy bueno o no estás progresando. : P
Jasarien
7

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.

Fosco
fuente
7

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"

AShelly
fuente
Robaré esta respuesta. :-)
encogerse
4

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.

Cuenta
fuente
3

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

Es guerra.


fuente
3

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.

Joeri Sebrechts
fuente
3

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.

HLGEM
fuente
Ah, la vieja pregunta de POR QUÉ ...
1

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.

Alex Feinman
fuente
1

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 .

CokoBWare
fuente
1

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.

David Thornley
fuente
0

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 .

encogerse
fuente
0

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.

Kevin Cline
fuente