Gracias por el A2A. Personalmente, me gustaría relatar algunos de los errores que he cometido en el pasado (y creo que aprendí de ellos).
- Uso excesivo de cierres. Los cierres son un concepto poderoso. Le permiten realizar un seguimiento de los datos sin contaminar su alcance global. Sin embargo, en mis primeros días de javascript, acabo de convertir mi cierre en un nuevo alcance global. También entraría en el hábito de nunca pasar variables a funciones, simplemente las anidaría dentro de mis funciones existentes para que usaran las variables existentes. Esto obviamente es muy malo. Cuando tiene una sola función que tiene 30,000 líneas de largo, el código huele. Si bien nunca he tenido uno tan malo, tengo un compañero de trabajo que sí, y pasé 2 meses desglosándome quirúrgicamente.
- Demasiados globales. Por supuesto, no podemos hablar de cierres que ayuden con la contaminación global sin hablar de por qué eso es malo. Los primeros JavaScript no le daban muchas herramientas para administrar su espacio de nombres global, por lo que los desarrolladores novatos (incluso los bien educados) tenderían a rellenar todas sus variables en el ámbito global. Esto condujo a algunos comportamientos interesantes en momentos en que sacamos alguna biblioteca que tenía nombres globales similares.
- Funciones largas y locas . Fuera del problema de cierre anterior, solía tratar de agrupar toda la lógica de algo en una función, no importaba cuánta lógica hubiera. Aprendí por las malas que las funciones más pequeñas son mejores. Prueban mejor y son más fáciles de depurar en fragmentos más pequeños. Cuando tiene una función de más de 50 líneas, es MUY largo. Por lo general, apunto ahora a alrededor de 25 líneas sin incluir comentarios (que si se hacen correctamente podrían duplicar eso a 50 o más).
- No hay suficientes comentarios. Hablando de comentarios, sé juicioso. Si tuvo que pensar para escribir ese código, coméntelo. Claro, tengo funciones sin comentarios. No necesitan comentarios. Realmente se auto documentan. Estas son funciones que hacen cosas como instanciar los diversos campos de un objeto, o copiar cosas de un objeto a otro. Eso es solo un código de tipo repetitivo que es muy legible para casi cualquier persona sin comentarios. Casi todo lo demás que escribo ahora tiene comentarios (¡es absolutamente necesario!) A veces he pasado más tiempo escribiendo comentarios que código, pero quería asegurarme de que mi código fuera legible.
- Demasiados comentarios Hablando de eso, es posible tener tantos comentarios que el código se vuelve menos legible. Una vez escribí tantos comentarios en una función que cuando volví a ello más tarde, tuve que eliminar 3 líneas para cada línea que todavía estaba en la función solo para LEER realmente la función. Un problema raro para estar seguro, pero lo he tenido.
- Falta de uso del prototipo. Muchos desarrolladores de JavaScript simplemente no pueden comprender qué es la herencia de prototipos. Creo que ES2015 hará mucho para frenar eso, ya que oculta la herencia prototípica bajo la apariencia de palabras clave más conocidas de “clase” y “extensión”. La realidad en ese punto es que no necesitas REALMENTE entenderlo, aunque es una abstracción permeable.
- Dependencia excesiva de la comparación estricta o laxa. En pocas palabras, ==! == ===. Doble igual (o comparación suelta) es muy útil cuando se trata de la entrada del usuario que siempre viene como una cadena. También es útil cuando se trata de respuestas de API que, en la mayoría de los casos, no están en el tipo que está utilizando. No se debe confiar en ellos universalmente, pero tienen su lugar. Del mismo modo, triple igual (o comparación estricta) es más “seguro de tipo” y se asegurará de que esté utilizando entradas completamente válidas. Tenga en cuenta que hacer cosas como un <5 no es una comparación estricta, y a se convertirá en un número si puede ser (falso no obliga a 0, así que no se preocupe). El uso de triple igual sin motivo para preocuparse por la rigidez puede causar fallas cuando la coerción de tipo fue suficiente para que su lógica funcione. El uso de doble igual cuando no tiene al menos un lado "desinfectado" puede hacer que su lógica "tenga éxito" cuando debería haber fallado. Conozca su situación y elija en consecuencia. Esto fue difícil para mí cuando comencé con doble igual en todas partes, me quemé, cambié a triple igual en todas partes, y ahora he encontrado un equilibrio.
- Nuevo brillante. Es realmente fácil quedar atrapado en la última herramienta divertida. Sé que tengo Recuerdo cuando salió jQuery y no pude dejar de mirar con la boca ligeramente abierta. Entonces apareció KnockoutJS e hice lo mismo. Entonces angular. Luego meteorito. Entonces reacciona. Entonces GraphQL. Etc. Es importante mantenerse “actualizado”, pero también es importante elegir porque hay un nuevo brillo cada 5 minutos. Si te sumerges en el bombo, te perderás el resto.
Estoy seguro de que hay muchas más cosas que he sucumbido a lo largo de los años, y que no. Quién sabe, probablemente encontraré más pronto. Diré que cada uno de los que he enumerado aquí lo he visto en mí mismo en el pasado, así como en la actualidad en compañeros de trabajo o personas que he ayudado a entrevistar.
- Desarrollo web front-end: ¿Qué preprocesador CSS debo elegir como el primero?
- Cómo crear un hipervínculo para mi sitio web en Django
- ¿Cómo puedo desarrollar un servicio web de descanso si ya tengo el cliente de ejemplo en JavaScript?
- ¿Cuál es la ventaja de usar Windows para el desarrollo cuando las implementaciones son para Linux?
- ¿Cómo convertirse en un buen desarrollador web en 2017 (y 2018)? ¿Qué lenguajes y habilidades de programación debo saber?
