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!

Facebook
Twitter
LinkedIn
WhatsApp

Deja una respuesta

EnglishPortugueseSpanish