El culto a la carga es inevitable
Es indiscutible que los nuevos desarrolladores no pueden evitar el culto a la carga.Simplemente no han aprendido lo suficiente de la pila para entender realmente lo que está pasando debajo del capó y por qué las cosas deben hacerse de cierta manera.
Por ejemplo, en uno de mis primeros cursos de programación aprendimos que en Java el punto de entrada al programa es:
public static void main(String args)
Me llevó años llegar al punto en el que entiendo cada parte de la firma de ese método.Incluso si me lo hubieran explicado en ese momento, no lo habría entendido.Habría tenido que entender la visibilidad de los métodos, la clase frente a los métodos de instancia, los tipos de retorno, los tipos de parámetros, los arrays (en lugar de las listas/vectores), los argumentos de la línea de comandos (y cómo los analiza el shell) y varios detalles sobre la implementación de Java.
Y eso está bien.Resulta que apenas necesitas entender nada de eso para escribir programas de línea de comandos o incluso GUI en Java.
No esperamos que los nuevos desarrolladores conozcan los pormenores de cada decisión que toman.Simplemente no han estado programando el tiempo suficiente para entender cada detalle de cada parte de la pila.
Tampoco esperamos que sepan que git almacena confirmaciones en un gráfico acíclico dirigido y que cada rama es un puntero a un nodo en el graph.It es lo suficientemente bueno para que puedan hacer git checkout
y git commit
y continuar con su trabajo.Y es suficientemente bueno si siguen una regla como «nunca fusionar hacia adelante rápido»(o «siempre fusionar hacia adelante rápido»).
Pero incluso para los desarrolladores sénior es inevitable.¿Qué desarrollador senior realmente entiende todos los comandos de git que tiene que buscar en el Desbordamiento de pila?O el awk
y sed
parte de la línea levantó ayer en GitHub?¿O cada encabezado de la respuesta HTTP con el que responden sus API de aplicaciones web?¿O cuándo usar la URL HTTPS vs. la URL SSH de tu repositorio de GitHub?¿O cómo configurar mejor su instancia local de PostgreSQL?¿O tu caso de Neo4j?¿O cómo depurar su configuración de rvm/rbenv/chruby/virtualenv sin eliminarla y reconstruirla desde cero?
La única manera de no tener culto a la carga es saberlo todo.Y nadie lo sabe todo.
El culto a la carga es bueno
El culto a la carga es bueno cuando se usa responsibly.It nos salva de tener que saberlo todo.Cuando se usa bien, es el acto de aprovechar la experiencia ganada con esfuerzo de todos los demás en el campo.Podría decirse que, usando cualquier abstracción sin entender cómo funciona (¡que es el punto de la abstracción!) es un culto a la carga según la definición de Lippert.
Además, el culto a la carga es a menudo una buena opción.»Estas personas parecen saber lo que están haciendo, así que seguiré su ejemplo», es una estrategia perfectamente racional.
De hecho, la comunidad de programación fomenta activamente el culto a la carga.Cuando le decimos a la gente, «no uses el estado global», o «sigue a PEP8», les estamos diciendo que carguen cult.Por ejemplo, un desarrollador entendería idealmente las formas sutiles (a veces no tan sutiles) en que el estado global puede morderte, pero hasta que el entendimiento esté ahí, es mejor simplemente evitarlo.
Algunos otros grandes usos del culto a la carga:
- «Convención sobre configuración» como se ve en Rails (y sus innumerables clones), Django y Ember.guías de estilo js
- y sus herramientas, como Rubocop, JSLint y Auto PEP8
- Muchas herramientas de análisis estático, como CodeClimate, Reek, Flay y Flog
- Las directrices de la aplicación de 12 factores
- Code smells
Cómo realizar un culto de carga responsable
Obviamente, el culto de carga tiene algunas desventajas importantes, pero ahora también hemos visto algunas ventajas.Nos gustaría utilizar herramientas y técnicas que hagan el trabajo ahora, sin tener que entender siempre por qué funcionan.En lugar de evitar el culto a la carga por completo, ¿cómo podemos el culto a la carga de manera efectiva?
La única gran advertencia: el riesgo inherente del culto a la carga es que no podrá predecir lo que saldrá mal, o incluso la clase de problemas que puede encontrar, porque fundamentalmente no entiende las decisiones que está tomando.Dicho esto, he aquí algunos consejos.
Escribir pruebas
Puede escribir pruebas automatizadas para asegurarse de que su código funciona como se espera, incluso si no entiende por qué funciona el código.Un ejemplo sencillo sería si copias y pegas un algoritmo de ordenación del desbordamiento de pila, puedes escribir una prueba para que funcione.
Tenga cuidado, sin embargo, porque las pruebas no son tan buenas para demostrar que no hay efectos secundarios inesperados o borde cases.In el ejemplo del algoritmo de ordenación, no sabrá de qué casos de borde debe preocuparse.
Refactorizar sin piedad
Cuanto más limpio sea el código, más fácil será razonar sobre cuándo se debe cambiar una decisión de culto a la carga.Y recuerde, no puede refactorizar de manera efectiva sin pruebas.
Aísle el código de cultos de carga
Cuando sea posible, aísle el código de cultos de carga en una clase o módulo.Cuanto más puedas aislarlo, más limitarás su daño potencial.Además, cuanto más aislado esté, más fácil será reemplazarlo o reescribirlo una vez que lo entiendas mejor.
No cargue culto en partes críticas de su aplicación
Por ejemplo, si la alta concurrencia es una necesidad absoluta para su aplicación, probablemente no pueda salirse con la suya copiando algún código de subproceso del desbordamiento de pila.Incluso elegir un lenguaje que maneje bien la concurrencia inherentemente (como Elixir, Go o Clojure) no resolverá mágicamente su problema.Desafortunadamente (o afortunadamente), realmente tendrás que profundizar y aprender algo.
No carguen culto si el fracaso lleva a que sucedan cosas malas
Si la seguridad, privacidad, dinero, etc. de las personas. están en riesgo, no carguen culto.Como un ejemplo obvio, si el fabricante de ritmos de alguien ejecuta un determinado C one-liner que copió de Stack Overflow, es mejor que sepa por qué funciona su pequeño truco y cuáles son los casos de fallas y los efectos secundarios.
Evite el culto a la carga cuando se trate de entradas variables
Por ejemplo, si no conoce muy bien awk y la entrada de su awk de un solo revestimiento provendrá de la entrada del usuario, es probable que se rompa.Si puede predecir las diferentes formas que puede tomar su entrada, eso ayudará, pero debe tener en cuenta que es probable que se rompa en casos de entrada que no pudo prever.
Monitor en producción
Solo porque funciona en su máquina, no asuma que funcionará en producción donde el entorno es diferente y los usuarios hacen cosas que nunca consideró.El monitoreo de errores, excepciones, errores de aserción y rendimiento puede permitirle saber si algo está mal antes de que sus usuarios, clientes o jefes se den cuenta.
Revisión de código, programación de pares, herramientas de análisis estático, etc.
Consigue que otros ojos, virtuales o de otro tipo, miren tu código.La programación de pares y la revisión de código son ejemplos obvios, pero las herramientas de análisis estático (por ejemplo, CodeClimate) también pueden ser útiles.Además de detectar errores obvios, son especialmente útiles para señalar código que no siempre funciona como se espera.
Pasa a una comprensión más profunda
Al comenzar con el culto a la carga, cuando decidas profundizar en el tema, ya tendrás algo de contexto.El camino hacia una comprensión más profunda puede ser el estudio propio, la tutoría, la programación en pareja o simplemente hacerlo usted mismo por el bien del aprendizaje.
Esta es una noticia antigua
Los consejos enumerados anteriormente son probablemente todas las cosas que has escuchado antes.Eso es porque todos trabajamos con conocimientos limitados.Todos nos dedicamos al culto de la carga todo el tiempo y hemos desarrollado intuición, técnicas y directrices para poder avanzar con conocimiento parcial y limitar el daño que podemos hacer.En lugar de nunca culto de carga, los buenos desarrolladores aprenden a culto de carga de manera efectiva.