Los malos hábitos son difíciles de romper y aún más si no te das cuenta de que lo que estás haciendo está minando tu trabajo. Si lo sabes pero no te importa, eso sería lo peor. Pero estás aquí, ¿no?
Como programador, he visto un montón de malas prácticas, no sólo en torno al código, sino también en torno a las habilidades de trabajo en equipo. Yo mismo he sido culpable de practicar muchos de estos malos hábitos. Aquí están mis 35 principales malos hábitos de programación, organizados en cuatro categorías: la organización del código, el trabajo en equipo, la escritura de código, y las pruebas y el mantenimiento.
Organización del código
1. Decir, «Lo arreglaré más tarde»
El hábito de posponer las correcciones de código no es simplemente un problema de prioridades. Organizar el rastreador de problemas puede generar algún progreso, pero también es necesario tener una forma de rastrear los problemas más pequeños que surgen. Añadir comentarios «TODO» es una forma rápida de asegurarse de que no se pierde nada.
2. Insistir en una solución de una sola línea
Ser obsesivo con la escritura de piezas de código eficientes y elegantes es un rasgo común de los programadores. Es como resolver un rompecabezas: encuentras una combinación de funciones y expresiones regulares que convierten 20 líneas de código en 2 o 3. Desafortunadamente, no siempre resulta en un código legible, y ese es generalmente el resultado más importante. Haz que tu código sea accesible primero, y luego inteligente.
3. Hacer optimizaciones sin sentido
Otro lugar en el que a menudo malgastamos nuestros esfuerzos son las optimizaciones. Suena muy bien reducir el tamaño de tu sitio web unos pocos bytes, pero ¿el gzip no lo compensará de todos modos? ¿Y no son más importantes las peticiones? Aborde las optimizaciones al final de un proyecto, porque la mayoría de las veces, los requisitos cambiarán, y su tiempo se habrá perdido.
«La optimización prematura es la raíz de todos los males»
-Donald Knuth
4. Convencerse de que las cuestiones de estilo no son tan importantes
Si he aprendido algo a lo largo de años de mirar el código de otras personas, es que ocuparse de las cuestiones de estilo de codificación es lo que los desarrolladores son más propensos a posponer. Tal vez es difícil para los codificadores inexpertos ver qué bien saldrá de abordar las cuestiones de estilo, pero con el tiempo se hará evidente que una vez que la calidad del código descarrila, un efecto de bola de nieve convertirá cualquier proyecto en un completo desastre. Sé estricto con las mejores prácticas aunque parezcan insignificantes. Establezca herramientas de comprobación de código y linting para tener espacio para preocuparse de las cosas más importantes.
5. Barrer las cosas debajo de la alfombra
Ya sea atrapando e ignorando las excepciones, o utilizando bibliotecas que no informan de los errores (como jQuery), hay muchas maneras de barrer las cosas debajo de la alfombra. Pero cuando uno de esos errores se convierte en una prioridad, el reto de arreglarlo será mucho mayor, teniendo en cuenta que no tendrás ni idea de por dónde empezar. Una manera fácil de evitar esto es registrando esos errores ignorados para poder estudiarlos más tarde.
6. Usar nombres que no añaden información
Nombrar es difícil, pero hay una manera fácil de asegurarse de que los nombres de sus variables y funciones son al menos de calidad decente. Mientras los nombres añadan algún tipo de información que el resto del código no transmite, otros desarrolladores tendrán más facilidad para leer tu código. La razón por la que los nombres son tan importantes es que pueden dar una idea general de lo que hace el código. Lleva más tiempo si tienes que escarbar en los cálculos para averiguar lo que hace un trozo de código, pero un buen nombre puede ayudarte a entender lo que hace el código en cuestión de segundos.
7. Ignorar las mejores prácticas probadas
Las revisiones de código, el desarrollo dirigido por pruebas, el aseguramiento de la calidad, la automatización del despliegue: estas prácticas, y varias otras, han demostrado su valor en innumerables proyectos, por lo que los desarrolladores bloguean sobre ellas constantemente. Una gran referencia para estas mejores prácticas es el libro Making Software: What Really Works, and Why We Believe It. Tómese el tiempo para aprender a hacerlas correctamente, y su proceso de desarrollo mejorará en todos sus proyectos de una manera que le sorprenderá.
Trabajo en equipo
8. Abandonar los planes demasiado pronto
Una forma segura de hacer que su sistema sea inescrutable es no comprometerse con un plan. Siempre puedes decir, cuando se critique tu código, que el plan no está completo. Sin embargo, tener módulos a medio hacer conducirá a un código estrechamente acoplado en cuanto intentes hacer que esos módulos inacabados funcionen entre sí. Este tipo de complicación también surge cuando los roles de liderazgo de un proyecto cambian y los nuevos líderes deciden que tenerlo a su manera es más importante que la consistencia arquitectónica.
9. Insistir en un plan que tiene pocas probabilidades de funcionar
Así como abandonar tus planes puede causar problemas, también lo puede hacer apegarse a un plan que no funciona. Por eso debes compartir tus ideas con tu equipo para recibir comentarios y consejos cuando las cosas se pongan difíciles. A veces una perspectiva diferente puede marcar la diferencia.
10. Trabajar por tu cuenta todo el tiempo
Debes esforzarte por compartir tus progresos e ideas con el equipo. A veces crees que estás construyendo algo de la manera correcta, pero no es así, por lo que la comunicación constante es muy valiosa. También es beneficioso para los demás cuando trabajas con ellos. Su trabajo suele mejorar cuando discutes ideas con ellos y sirves de mentor a los miembros menos experimentados de tu equipo, que son más propensos a atascarse.
11. Negarse a escribir código malo
Llega un momento en la vida de todo desarrollador en el que los plazos te obligarán a escribir un código terrible, y eso está bien. Has intentado advertir a tu cliente o a tu jefe sobre las consecuencias, pero insisten en cumplir el plazo, así que ahora toca codificar. O tal vez hay un error urgente que no puede esperar a que le des una solución limpia. Por eso es importante ser versátil como programador y ser capaz de escribir rápidamente tanto código malo como código bueno. Con suerte, podrás revisar el código y pagar la deuda técnica.
12. Culpar a los demás
No es ningún secreto que la arrogancia es un rasgo demasiado común entre los desarrolladores y otros profesionales técnicos. Asumir la responsabilidad de tus errores es una virtud que te hará brillar entre tus compañeros. No tengas miedo de admitir que has cometido un error. Una vez que estés de acuerdo con eso, serás libre de concentrarte en aprender por qué cometiste ese error y cómo evitarlo. Si no lo reconoces, el aprendizaje se vuelve imposible.
13. No compartir con tu equipo lo que has aprendido
Tu valor como desarrollador no sólo está puesto en el código que escribes, sino también en lo que aprendes al escribirlo. Comparte tus experiencias, escribe comentarios al respecto, haz que los demás sepan por qué las cosas son como son, y ayúdales a aprender cosas nuevas sobre el proyecto y sus entresijos.
14. Ser demasiado lento a la hora de dar retroalimentación a los gerentes/clientes
Uno de los rasgos de carácter más valiosos de cualquier artesano radica en asegurarse de que todos están en la misma página sobre el trabajo, en la medida de lo posible. La razón de esto no es para que su gerente pueda llenar hojas de cálculo. Es también para tu propio beneficio: Tendrás menos inseguridades y reducirás la incertidumbre sobre la vida y el futuro del proyecto.
15. No usar Google lo suficiente
La mejor manera de resolver un problema complejo rápidamente es no tener que resolverlo. Cuando tengas dudas, búscalo en Google. Por supuesto, puedes molestar al ingeniero que tienes al lado en su lugar, pero rara vez podrá dar una respuesta tan detallada como la de Stack Overflow, por no mencionar que también estarás interrumpiendo su trabajo.
16. Sobrevalorar tu estilo personal
Apunta siempre a coordinar tu estilo de trabajo y la configuración del entorno con tu equipo. Lo ideal es que todos los miembros de tu equipo trabajen en condiciones similares y sigan el mismo estilo de codificación. Hacer las cosas a tu manera puede ser más divertido, pero los compañeros de trabajo podrían no estar acostumbrados a tu estilo de codificación, y si es inusual, será más difícil para el siguiente desarrollador trabajar en lo que has construido.
17. Tener un apego personal a tu código
Cuando alguien comenta tu código, no te lo tomes como algo personal. Tu código debe apoyarse en una base sólida; es decir, debes ser capaz de explicar por qué lo escribiste así. Si necesita mejoras, eso es sólo un reflejo de la corrección del código, no de ti mismo.
Escribir código
18. No saber cómo optimizar
Una buena estrategia de optimización requiere cierta experiencia para acertar. Requiere exploración, análisis y conocer cada sistema involucrado en un proceso. Infórmate sobre estas cosas. Aprenda sobre la complejidad de los algoritmos, la evaluación de las consultas en las bases de datos, los protocolos y cómo medir el rendimiento en general.
19. Usar la herramienta equivocada para el trabajo
Sólo se puede saber un poco, pero la razón por la que hay que seguir aprendiendo es que cada nuevo problema trae un contexto diferente y requiere una herramienta diferente-una más aplicable a la tarea en cuestión. Esté abierto a nuevas bibliotecas y lenguajes. No tome decisiones basadas estrictamente en lo que sabe.
20. No molestarse en dominar las herramientas y el IDE
Cada nueva tecla de acceso rápido, atajo o parámetro que aprendas mientras usas las herramientas con las que trabajas cada día tendrá un efecto más positivo en tu velocidad de codificación de lo que crees. No se trata de ahorrar unos segundos utilizando una tecla de acceso directo; se trata de reducir el cambio de contexto. Cuanto más tiempo dediques a cada pequeña acción, menos tiempo tendrás disponible para pensar en por qué lo estás haciendo y en lo que viene después. Dominar los atajos liberará tu mente.
21. Ignorar los mensajes de error
No asumas que sabes lo que está mal en tu código sin siquiera leer un mensaje de error, o que lo descubrirás lo suficientemente rápido. Tener más información sobre un problema siempre es mejor, y tomarse el tiempo para reunir esa información ahorrará más tiempo a largo plazo.
22. Romantizar su conjunto de herramientas para desarrolladores
A veces su editor preferido o herramienta de línea de comandos no es la mejor herramienta para el trabajo en cuestión. Visual Studio es genial para escribir IDEs, Sublime es genial para lenguajes dinámicos, Eclipse es genial para Java, etc. Puede que te guste vim o emacs, pero eso no significa que sea la herramienta adecuada para cada trabajo.
23. Codificar valores en lugar de hacerlos configurables
Piensa siempre en los cambios que pueden venir y en cómo afrontarlos. La deuda técnica crecerá a un ritmo monstruoso si no separas las piezas móviles del resto de tu trabajo. Utilice constantes y archivos de configuración cuando sea apropiado.
24. Reinventar la rueda todo el tiempo
No escribas código que no necesitas. Tal vez alguien más ha pasado una buena cantidad de tiempo en su problema ya, y él o ella podría tener una solución bien probada que puede reutilizar. Ahórrese algunos problemas.
25. Copiar/pegar código a ciegas
Entender el código antes de reutilizarlo. A veces no se nota inmediatamente todo lo que hace el código a primera vista. También aprenderás más sobre un problema cuando te tomes el tiempo de leer el código en detalle.
26. No tomarse el tiempo para aprender cómo funcionan realmente las cosas
Aproveche siempre la oportunidad de ampliar sus conocimientos pensando en cómo funcionan las cosas y leyendo sobre sus problemas subyacentes. Puede que ahorres tiempo si no te molestas ahora, pero lo que aprendas en un proyecto será más importante a largo plazo que conseguirlo realmente.
27. Tener excesiva confianza en tu propio código
Es peligroso asumir que sólo porque has escrito algo, debe ser genial. Aprendes más sobre la programación a medida que trabajas en cosas nuevas y ganas experiencia, así que echa un vistazo a tu antiguo código de vez en cuando y reflexiona sobre cómo has progresado.
28. No pensar en las ventajas y desventajas de cada diseño, solución o librería
Cada producto tiene sus puntos finos que sólo conocerás al usarlo y analizarlo. Ver unos cuantos ejemplos de uso de una librería no te convertirá en un maestro de la misma, ni significa que sea el ajuste perfecto para cada situación que se presente en tu proyecto. Sea continuamente crítico con todo lo que utiliza.
29. No pedir ayuda cuando estás atascado
Mantener un bucle de retroalimentación corto siempre será menos doloroso para ti. Pedir ayuda no significa que seas incompetente. Las personas adecuadas verán tu esfuerzo y la admisión de tu ignorancia como un impulso para aprender, y eso es una gran virtud a tener.
Pruebas y mantenimiento
30. Escribir pruebas para pasar
Escribir pruebas que sabes que van a pasar es necesario. Harán que refactorizar y reorganizar un proyecto sea mucho más seguro. Por otro lado, también hay que escribir pruebas que sabes que no van a pasar. Son necesarias para hacer avanzar el proyecto y hacer un seguimiento de los problemas.
31. Despreciar las pruebas de rendimiento para los casos críticos
Preparar una configuración de pruebas de rendimiento automatizadas más o menos en el punto medio del proceso de desarrollo de un proyecto para que puedas asegurarte de que no tienes problemas de rendimiento crecientes.
32. No comprobar que la compilación funciona
Es raro que una compilación pase pero no funcione realmente, pero puede ocurrir, y puede ser problemático arreglar el problema cuanto más se espere para investigarlo. Probar rápidamente cada compilación es un hábito importante a tener.
33. Empujar grandes cambios tarde, o irse después de hacer un gran empuje
Aquí es donde el exceso de confianza te llevará, y puede ser necesario quemarse varias veces para aprender por qué no debes hacer esto, así que toma mi consejo ahora y asegúrate de que siempre estás ahí cuando tu build eventualmente se rompe.
34. Renegar del código que escribiste
Estar dispuesto a apoyar el código que escribiste. Eres la persona más adecuada para ayudar a otros a entenderlo. Debes esforzarte para que tu código siga siendo legible para ti y para los demás dentro de muchos años.
35. Ignorar los requisitos no funcionales
Cuando está tratando de entregar algo, puede ser fácil olvidarse de algunas áreas importantes como el rendimiento y la seguridad. Mantenga una lista de control para esos. No querrá que le arruinen la fiesta porque elaboró sus plazos sin pensar en estas preocupaciones no funcionales.
¿Cuáles son sus peores hábitos de programación?
Como se suele decir, somos criaturas de hábitos. Mejorar la forma de trabajar a través de los hábitos es una gran manera de evitar tener que pensar demasiado en cada situación. Una vez que has asimilado una buena forma de hacer algo, se convierte en algo sin esfuerzo.