5 principios para aplicaciones JavaScript ‘estúpidamente brillantes’

Los desarrolladores enfrentan problemas complejos todo el día, todos los días. Vivimos en un mundo complicado y es tentador creer que cada problema complicado requiere una solución bizantina y multifacética. En realidad, aunque el mundo es problemático, se rige por leyes simples como causa y efecto, gravedad, energía y cantidad de movimiento.

Te puede interesar 👉 Libros Para Aprender HTML5, PHP5, Javascript, CSS3 Y Jquery

Podemos tomar lecciones de la naturaleza y aplicarlas al código. La mayoría de las veces, la simplicidad conduce a los resultados más bellos e intrincados.

El código ‘inteligente’ es la solución incorrecta

Es fácil demostrar habilidad técnica agregando cientos de líneas de código hasta que resuelve todos los problemas, sigue la lógica booleana en cada madriguera de conejo concebible e inevitablemente se convierte en un desastre.

Cuanto más «inteligente» sea el código, más propenso a errores, más difícil de depurar y más difícil de extender y mantener. Trabajar de esta manera también hace que sea casi imposible estimar el tiempo que lleva construir y administrar el código.

Además, la vida útil de un código demasiado complejo tiende a ser muy corta. Lidiar con los errores y la incertidumbre que conlleva este tipo de código es frustrante, por lo que los desarrolladores terminan desechando la solución por completo y creando otra cosa. Esto es una pérdida de tiempo y dinero que podría gastarse en otros proyectos.

Síntomas de un código demasiado complejo

¿Cómo puede saber si su código necesita ser simplificado? Además de los problemas generales mencionados anteriormente, existen cinco formas de identificar un código demasiado complejo.

1. Las funciones toman muchos parámetros

Muchas partes móviles son malas en las máquinas físicas y son igual de problemáticas en el código. Las funciones con más de dos parámetros (una palabra clave importante en C#) son una señal de alerta de que su código es más complejo de lo que debe ser.

2. La lógica condicional es la característica dominante

Las declaraciones «If», las declaraciones de cambio, la lógica booleana, las declaraciones ternarias y los operadores lógicos son oportunidades para que el código falle cuando se enfrenta a un caso extremo. Demasiada de esta lógica condicional a menudo causará problemas.

3. Comentarios que explican el código

Un buen código es como una buena broma. Si necesita explicar lo que está pasando, no está funcionando.

4. Código frágil

El código que se rompe con frecuencia es una fuente de frustración más que una herramienta útil. Si las pruebas detectan fallas que no ha visto, su código es demasiado complicado.

5. Difícil de seguir

No hay nada más irritante que trabajar en un parche de código duro y ser interrumpido en el medio, solo para volver a su escritorio y darse cuenta de que ha perdido por completo su lugar. Si tarda 30 minutos en descubrir en qué estaba trabajando, o si no puede explicar rápidamente su código a los desarrolladores junior, eso es un síntoma de que su código está tratando de ser demasiado inteligente en lugar de estúpidamente brillante.

5 principios para crear código estúpido en su lugar

Hay una solución para todos estos problemas. Escribir código simplificado o simple y eficiente permite que su aplicación sea inteligente y versátil. Cuanto más elegante la solución, más pulido el producto final.

El código complicado que se agrega cada vez que surge un problema comienza a parecerse a algo diseñado por un comité. Es difícil de usar y difícil de cambiar. En su lugar, use los siguientes cinco principios cada vez que comience un nuevo proyecto y creará un código simple que hará el trabajo en todo momento.

1. Comprender el problema

¿Cuál es el propósito del código que estás escribiendo? Comprender verdaderamente los objetivos principales requiere tiempo y energía, pero puede ahorrarle horas en la creación de su aplicación y dará como resultado un producto final mucho mejor.

Para ilustrar este punto, considere un problema simple: dadas las coordenadas de dos rectángulos que se cruzan, escriba un algoritmo para calcular el área de intersección. Hay una miríada de formas de resolver esta pregunta y crear una aplicación que la responda, pero hay una trampa. Los rectángulos pueden ser de cualquier tamaño y en casi cualquier posición, por lo que los casos extremos pueden alejarse rápidamente.

Sin embargo, si retrocede y piensa realmente en el problema, se dará cuenta de una verdad fundamental: entre las ocho coordenadas, solo hay cuatro valores distintos de X, porque los lados siempre están alineados. Solo los del medio son importantes para encontrar el área del rectángulo de intersección. No importa de qué rectángulo formen parte, solo que estén en el medio.

Entonces, si su código puede ordenar los valores de X, tome los dos del medio y encuentre la distancia entre esos dos, tiene la longitud. Aplica el mismo principio a los valores de Y y tendrás tu respuesta. De esa manera, el código pasa de una página completa en letra pequeña a menos de una docena de líneas (con una función de ayuda), sin una sola declaración «si».

Comprender y simplificar el problema es probablemente el paso más importante para crear un código estúpidamente brillante, así que no se salte ni escatime en esta pieza del rompecabezas.

2. Ideas de desacoplamiento

Cualquiera que haya estudiado informática o TI conoce el principio de responsabilidad única. Las funciones funcionan mejor cuando están diseñadas para hacer una sola cosa.

Aplique esta idea de manera más amplia a todo en su código. Separa cada resultado del siguiente. La interfaz de usuario, la lógica de la interfaz de usuario, los estilos, los conjuntos de datos, la traducción de datos, la lógica comercial y las integraciones de terceros son preocupaciones diferentes y deben mantenerse separadas entre sí.

Hay una variedad de patrones arquitectónicos que analizan esto y se pueden usar para crear el tipo de código simple y desacoplado que funciona siempre. Producto mínimo viable, controlador de vista de modelo, vista del modelo vista del modelo y otras arquitecturas y herramientas resuelven este problema cuando se usan correctamente.

3. Pasar la cosa en lugar de las partes para construir la cosa

Hay formas más técnicas de describir esto, pero la frase «Pasa la cosa sobre las partes para construir la cosa» mantiene el espíritu de ser estúpidamente simple.

En resumen, significa que en lugar de usar múltiples accesorios y etiquetas que luego se agrupan en un solo paquete, transmite el resultado final: una imagen, un enlace o lo que sea. Esto facilita la personalización más adelante, ya que se puede cargar el elemento en sí mismo en lugar de tratar de describir sus partes en complicadas líneas de código.

4. Refactorizar

Los escritores editan su trabajo varias veces antes de hacer clic en publicar. Los fotógrafos toman docenas de fotografías antes de aterrizar en la perfecta. Los atletas experimentan con diferentes técnicas y entrenadores para refinar su estilo característico. ¿Por qué la codificación debería ser diferente?

El primer borrador del código rara vez encaja perfectamente. Está bien enviarlo si hace el trabajo. Pero cuando se presenta la oportunidad, retroceder y refactorizar le permite simplificar el código y hacerlo mejor que antes.

Reconocer que la refactorización es una inversión. Le quita tiempo a otras cosas y debe tenerse en cuenta en el presupuesto. Sin embargo, la recompensa siempre vale la pena al final.

5. Desarrollo basado en pruebas

Muchas personas inteligentes se han acercado al desarrollo basado en pruebas (TDD). Roberto C. Martín escribió un libro llamado El codificador limpio esto le dirá todo lo que necesita saber, pero para los fines de este artículo, le daré la versión estúpidamente simple.

Escriba una (y solo una) prueba fallida antes de escribir cualquier código de producción. Escriba el código suficiente para pasar la prueba, refactorice, escriba otra parte y siga adelante. Bien hecho, TTD produce un código «tonto», ya que te obliga a seguir los otros cuatro principios.

No puede escribir un buen código basado en pruebas si no comprende el problema. Tienes que separar el código, porque no puedes probar una función que hace 50 cosas diferentes. Esto fomenta la aprobación y lo obliga a refactorizar cada paso del camino.

Sigue tu estúpido viaje

Estos no son los únicos principios que te ayudan a escribir aplicaciones estúpidamente brillantes, pero son un excelente punto de partida. ¡Ahora ve y escribe un código estúpido!