¿Eres Un Programador De Cargo Cult?

¿Qué es un culto de carga?

Se remonta a la Segunda Guerra Mundial. Como parte del esfuerzo bélico, las fuerzas aliadas tuvieron que construir bases de suministro en lugares estratégicos. Algunos de estos lugares eran islas remotas que nunca se habían topado con las innovaciones tecnológicas del siglo XX. Eso significa que los aviones, los jeeps y especialmente las cajas de carga que se lanzaban en paracaídas desde los aviones parecían magia.

Naturalmente, las tribus indígenas que vivían en esas islas estaban extasiadas. ¿A quién no le gusta la magia y la comida gratis?

El problema comenzó cuando terminó la Segunda Guerra Mundial (no es una frase que escuche todos los días).

Las tropas se fueron y la comida dejó de llover del cielo. Los líderes de la tribu deben haberse reunido para descubrir cómo recuperar la magia. ¿Su solución?

Recrea el escenario que acompañó a los sucesos mágicos antes mencionados. Después de todo, hay causa y efecto en el mundo.

Lamentablemente, eso no funcionó. Aparentemente, construir aviones de bambú no hace que la comida caiga del cielo.

El concepto se resume muy bien en esta excelente cita de Feynman:

“En los Mares del Sur , hay un culto de carga de personas. Durante la guerra, vieron aterrizar aviones con muchos buenos materiales, y querían que sucediera lo mismo ahora. Así que hicieron arreglos para imitar cosas como pistas de aterrizaje, poner fuegos a lo largo de los lados de las pistas, hacer una cabaña de madera para que se sentara un hombre, con dos piezas de madera en la cabeza como auriculares y barras de bambú que sobresalían como antenas. él es el controlador, y esperan a que aterricen los aviones.
Estaban haciendo todo bien. La forma es perfecta. Se ve exactamente como se veía antes. Pero no funciona. No aterrizan aviones. Entonces, llamo a estas cosas ciencia de culto de carga, porque siguen todos los preceptos aparentes y formas de investigación científica, pero les falta algo esencial, porque los aviones no aterrizan”. —Richard Feynman

Programación de culto de carga

Entonces, hemos terminado con la lección de historia. El único problema es que la historia tiende a repetirse. Espero como el infierno que no estemos al borde de la Tercera Guerra Mundial, pero Cargo Cults se ha extendido por todas partes, incluso en los reinos de la ingeniería de software.

¿Qué es la programación de culto Cargo?

En pocas palabras, significa hacer cosas sin entender realmente por qué.
Estoy seguro de que te has topado con estos casos e incluso has participado en ellos tú mismo. Analicemos algunos ejemplos comunes.

El temido copiar y pegar

En algún momento de tu carrera, probablemente copiaste y pegaste el código de otra persona. Sé que lo hice. No voy a discutir el plagio, así que supongamos que el código está destinado a compartirse libremente.

Y, de hecho, en cierto sentido, cada vez que usa una biblioteca, "copia y pega" su código y lo usa como parte de su base de código. Eso aún podría generar problemas , pero eso se considera legítimo. Las bibliotecas están destinadas a ser utilizadas por otras personas. Los ingenieros que lo diseñaron trabajaron arduamente para hacerlo accesible y lo más libre de errores posible.

Los problemas surgen cuando copia y pega desde alguna respuesta de desbordamiento de pila, o desde otras partes en su base de código, sin tener la menor idea de lo que realmente está haciendo ese código. Funcionó para esa persona, así que ¿por qué no iba a funcionar para ti?

Bueno, eso es pensamiento Cargo-Cult. Estás lidiando con el escenario (el código parece similar) sin comprender realmente la causa raíz (cómo se usa en ese contexto particular).

Digamos que logras terminar la tarea. El código funciona, obtuviste el premio (carga), pero luego las circunstancias cambian. Aparece una nueva solicitud, por lo que debe modificar ese código que realmente no entendió. Y entonces te das cuenta: el avión está hecho de bambú. Su código no es el verdadero negocio.

Abusar de la herencia en programación orientada a objetos

La primera vez que aprendes sobre la herencia, parece mágico.

Con menos de una línea de código, puede obtener casi todas las propiedades y funciones de la clase principal. Y no me hagan empezar con el polimorfismo, eso es mágico. Lo único que no te enseñan en la escuela es que la herencia introduce un acoplamiento muy estrecho.

Cada vez que heredas de una clase, creas una dependencia muy fuerte en su implementación concreta. Peor aún, cada usuario de su clase tiene una dependencia transitiva de la clase base. Eso significa que si alguien cambia la clase base, que incluso podría pertenecer a una biblioteca sobre la que no tiene control, su código puede romperse. Y eso significa que todas las clases que dependen de su clase también pueden romperse, eso no es fácil, especialmente si sucede al final de su semana laboral.

Por lo tanto, es necesario pensar detenidamente antes de introducir la herencia. Debe considerar tanto los pros como los contras de la herencia, y averiguar si su caso de uso específico realmente lo justifica. La mayoría de las veces, debería favorecer la composición . En este contexto, recomiendo leer esta discusión muy interesante, comenzando con una respuesta del propio tío Bob .

Seguir ciegamente las “mejores prácticas”

El último ejemplo que voy a dar es un poco más específico. Está relacionado con el código de copiar y pegar, pero es mucho más elusivo. Se trata de usar código/anotaciones que no entiende completamente, porque es la "mejor práctica".

Un buen ejemplo es el uso desordenado de la anotación transaccional en aplicaciones que usan Spring.

Parece que mágicamente resuelve algunos errores, por lo que la gente piensa (y algunos probablemente incluso afirman abiertamente) que es una buena práctica usarlo todo el tiempo.

Lo complicado de esto es que el 90% de las veces tendrán razón.
Los errores se resuelven y la carga sigue cayendo en paracaídas desde el aire.

Todo el mundo está contento hasta que algo cambia y surge un error de producción con toda su majestuosidad. Mira el siguiente ejemplo furtivo:

@Transactional
public void changeName(long id, String name) {
  User user = userRepository.getById(id);
  user.setName(name);
  if (StringUtils.isNotEmpty(name)) {
    userRepository.save(user);
  }
}// All rights reserved to this fantastic article

Un ingeniero con buen ojo puede ver que hay algo sospechoso aquí. ¿Por qué establecer el nombre antes de validar?

Sin embargo, un revisor de código apresurado puede pasar por alto esto, y si no está familiarizado con la anotación transaccional, podría pensar que no se hizo daño.

Y luego comienza a ver registros sobre registros de usuarios con nombres vacíos. Mierda, algo debe estar mal, ¿es esto un ataque cibernético?

No, es solo nuestra querida anotación transaccional haciendo su trabajo.

Verá, hay otro efecto secundario pasado por alto de esta anotación: cada entidad declarada en su alcance está en un estado administrado. Por lo tanto, cada cambio que realice en este ámbito se conserva automáticamente en la base de datos, incluso sin llamar explícitamente a "guardar".

En este caso, significa que está guardando los registros independientemente de si la validación tuvo éxito o no.

Cómo evitar la programación de Cargo Cult

Mira debajo del capó. Lleva tiempo y, a veces, puede parecer inútil, pero en el futuro, lo ayudará a ahorrar muchas semanas de lucha contra errores que desafían la razón.
Cuestionar las "mejores prácticas". La mayoría de ellos probablemente estén justificados. Pero al cuestionarlos, tienes la oportunidad de saber por qué surgieron en primer lugar, lo que te convierte en un ingeniero mucho mejor.
Trabaja en entender las cosas profundamente. Esto puede parecer trivial, pero a menudo nos conformamos con un conocimiento superficial. Confundimos saber algo con saber el nombre de algo.

Algo de esto puede parecer un conocimiento común trivial. Pero recuerde, el conocimiento común no siempre es una práctica común.

Sea consciente de su trabajo y pase más tiempo aprendiendo las complejidades de su oficio. Estaras contento de haberlo hecho.

Esta historia se publicó originalmente en https://betterprogramming.pub/are-you-a-cargo-cult-programmer-be361217c030

#cargo #programmers

What is GEEK

Buddha Community

Saul Alaniz

1655734042