yo estaba viendo/escuchando esta gran charla de Simon Brown Modular de Monolitos de IR a 2018.
En esto menciona un término llamado Programación de Culto de Carga y realmente me tocó la fibra sensible.
Recientemente me uní a una nueva empresa con un nuevo lenguaje de programación, nuevas herramientas, nuevos procesos y un nuevo equipo. En realidad, es casi todo «nuevo».
Esto me ha hecho aprender mucho en los últimos meses. Al ser relativamente experimentado, me gusta mirar los «porqués» en lugar de los «cómo» al aprender cosas nuevas. De lo que me he dado cuenta es de que este no es el enfoque más común.
Cuando un usuario tiene la tarea de agregar a una base de código existente, extender la solución actual, lo más probable es que compruebe cómo se ha hecho esto anteriormente, copiando el enfoque para su solución. Pueden / seguirán ciegamente este patrón, ya que es como se ha hecho antes. Se agregan bloques adicionales en la parte superior de la torre, sin cuestionar si es lo correcto. Si todo el mundo hace esto, eventualmente sucederá.
aquí es donde el término «Carga de Culto de la Programación» viene de.
Wikipedia lo explica así:
La programación de culto de carga es un estilo de programación de computadoras caracterizado por la inclusión ritual de código o estructuras de programas que no sirven para ningún propósito real. La programación de culto de carga es típicamente sintomática de que un programador no entiende un error que estaba intentando resolver o la solución aparente (comparar depuración de escopetas, magia profunda). El término programador de culto de carga puede aplicarse cuando un programador informático inexperto o inexperto (o uno sin experiencia con el problema en cuestión) copia algún código de programa de un lugar a otro con poca o ninguna comprensión de cómo funciona o si se requiere en su nueva posición.
La programación de culto de carga también puede referirse a la práctica de aplicar un patrón de diseño o estilo de codificación a ciegas sin comprender las razones detrás de ese principio de diseño. Algunos ejemplos son agregar comentarios innecesarios al código que se explica por sí mismo, adherirse excesivamente a las convenciones de un paradigma de programación específico o agregar código de eliminación para objetos que la recolección de basura habría recopilado automáticamente.
Imagine un escenario en el que esté trabajando en un error, encontrando el código que está causando el error. No estás muy seguro de lo que está pasando, así que;
- Google el error.
- Encuentra una pregunta de StackOverflow.
- Busca la respuesta más actualizada.
- Copie y pegue la solución en su código.
- Intente depurar para ver si eso solucionó su problema.
Lo tiene, así que lo registras y sigues adelante.
¿Te suena familiar?
¿Por qué hacemos eso? ¿Por qué tomamos ciegamente este fragmento y lo usamos tal cual, en nuestra implementación?
El caso de uso probablemente no sea el mismo, así que me sorprendería que las soluciones lo fueran. Dejando de lado ejemplos simples, entender el razonamiento detrás de la solución es más importante que la solución en sí. Hay muchas cosas que no puedes hacer con algo que no entiendes. No se puede modificar, mejorar o probar. No puedes documentarlo y no puedes poseerlo.
A todos nos encanta lo nuevo, y a la gerencia especialmente parece gustarle seguir las tendencias populares, mantenerse al día con los avances tecnológicos.
La mayoría de los equipos ahora seguirán un enfoque ágil. El TDD y las pruebas automatizadas pueden ser muy útiles en ciertos escenarios, la Integración continua elimina gran parte de la sobrecarga del equipo de infraestructura, el Big Data y la IA pueden mejorar enormemente la satisfacción del usuario y la Contenedorización y, más recientemente, los microservicios cambian nuestra antigua arquitectura monolítica a servicios autónomos más pequeños.
Cada uno de estos avances es brillante por derecho propio, y no apruebo ninguno de ellos. Mi problema es si necesitamos adoptarlas todas en todos nuestros procesos y código. Vemos publicaciones de blog de Netflix, Facebook y Twitter que muestran cómo su uso ha transformado su funcionamiento. Si las grandes empresas lo consideran necesario, ¿no deberíamos hacerlo nosotros también? Aquí es donde la programación de culto de carga levanta su fea cabeza de nuevo.
Necesitamos entender los problemas con nuestros diseños actuales, por qué ocurrieron y cómo se pueden desechar en el futuro. Sí, estos nuevos procesos pueden ayudarnos con nuestros problemas, pero seguirlos ciegamente con la débil esperanza de que lo hagan no es el camino a seguir, ni tiene ningún sentido lógico.
Menciono los microservicios específicamente, ya que muchas empresas parecen estar haciendo la transición, citando beneficios como:
- Tiempo de desarrollo más rápido
- Alta escalabilidad
- Fácil de mejorar
- Facilidad de implementación
- Equipos autónomos con la libertad de elegir tecnología
Con una lista como esa, ¿en qué pensar? ¡Subamos todos al carro!
Espera un segundo… ¿hay alguna desventaja de este enfoque?
- Complejidad arquitectónica
En arquitecturas monolíticas, la complejidad y el número de dependencias residen dentro de la base de código, mientras que en arquitecturas de microservicios la complejidad se traslada a las interacciones de los servicios individuales que implementan un dominio específico
- Complejidad operativa
- Cómo aprovisionar recursos de una manera escalable y rentable
- Cómo operar docenas o cientos de componentes de microservicios de manera efectiva sin multiplicar los esfuerzos
- Cómo lidiar con la falta de estándares y la heterogeneidad entornos que incluyen diferentes tecnologías y personas con diferentes conjuntos de habilidades
- Cómo lidiar con el control de versiones
- Cómo rastrear y depurar interacciones en todo el sistema
- Cómo realizar un seguimiento de cientos de canalizaciones de implementaciones de código y sus interdependencias
Estos datos se extraen del propio documento técnico «Desafío de Microservicios» de Amazon. Ahora no se sobre ti, pero los inconvenientes me parecen mucho más aterradores que los beneficios. Una vez más, no estoy diciendo que este no sea el enfoque correcto para bajar, pero a menos que estos beneficios superen los inconvenientes, ¿qué está ganando al seguir este enfoque?
El problema «público».
Es muy simple, Deja de usar la palabra clave Pública, deja de crear clases públicas automáticamente. ¿Por qué lo hacemos?
El problema con el uso de la palabra clave pública es que se está perdiendo los beneficios relacionados con la encapsulación. ¿Por qué lo usamos tanto? Es prácticamente la palabra predeterminada que usamos al crear clases, todos los ejemplos usarán clases públicas, asistentes y fragmentos implementarán clases públicas. Es hora de parar. ¿Cuántas personas tienen una cuenta pública de Facebook? La mayoría de las cosas en este mundo son privadas, como deberían ser nuestras clases. Hágalos privados de forma predeterminada, y luego, si necesita que sean públicos, cámbielos entonces.
Con una gran experiencia viene una gran aprehensión.
Cuanto más tiempo esté en un campo, menos ingenuo será para las mejoras percibidas que traerá una nueva herramienta o proceso. La mayoría de las ideas de hoy en día provienen de décadas de investigación en el campo que finalmente se están adoptando. Una vez que algo ha ganado la adopción masiva, es más fácil sentirse cómodo abrazándolo completamente. Es decir, si es lo correcto.
«El buen juicio proviene de la experiencia, y la experiencia proviene del mal juicio»
– Rita Mae Brown
Así que siéntase libre de seguir buscando en las interwebs soluciones y tutoriales para sus problemas; siga explorando nuevos lenguajes, marcos e implementaciones. Solo tenga en cuenta por qué funcionan, en lugar de simplemente cómo. Todos aprendemos de nuestras propias experiencias y errores, por lo que comprender los fundamentos evitará que sigas por el mismo camino en el futuro.