A continuación comento las diez cosas que todo el que se dedique al desarrollo de software de una forma más o menos profesional debería saber (junto con una breve descripción):
- Análisis y diseño orientado a objetos. Para que tus sistemas consistan en grupos de objetos relacionados que interactúan entre sí en lugar de un remix de líneas de código en un estilo pseudo-procedural. Si además representan el negocio de la aplicación, mejor :). Por eso, hay que tener claro qué es el análisis y diseño orientado a objetos, principios SOLID, Domain Driven Design… Si algo de esto te suena a chino, deberías empezar por el principio. Créeme, desarrollarás más rápido, tus sistemas serán más mantenibles y podrás reutilizar muchos más componentes. Fundamental.
- Patrones de diseño. Porque hay que conocer las soluciones que ya existen para esos problemas que siempre se repiten.
- Refactorización. Porque nadie es perfecto y el software que hace uno menos, es necesario conocer las técnicas que te permiten arreglar ese pequeño lío que has formado (o que te han formado).
- Estructuras de datos y algoritmos. Porque a veces hay que hacer algo un poco más complicado que recorrer una lista y no todo se puede resolver con un algoritmo de fuerza brutal. ¿No te suena? Entonces deberías probar a hacer “divide y vencerás”, “programación dinámica”, crear estructuras de grafos para aplicarles algoritmos conocidos, etc.
- Notación UML. Porque nadie trabaja solo y, a veces, hay que entenderse con otros (o con uno mismo). Eso sí: nunca intentes generar código a partir de un diagrama UML (LOL).
- Fundamentos de sistemas operativos. Pocas cosas hay más tristes que sentarte con un desarrollador y que te diga que no sabe abrir una conexión SSH con el servidor o que no conoce el comando para listar los ficheros de un directorio en Linux porque “él trabaja con Windows”. Lamentable.
- Testing (automatizado). “Todo el software es culpable hasta que se demuestre lo contrario”. Así que, si quieres que alguien confíe en tu software, tendrás que demostrarlo. Haz pruebas que demuestren que funciona bien. ¡Y si son automatizadas, mejor!
- Gestión de dependencias. Al final, o desde el principio, mejor dicho, tienes que trabajar con librerías de otros. Asegúrate de que sabes controlarlas y no son ellas las que te controlan a ti.
- Sistemas de control de versiones. Si no quieres perder tu trabajo y además ser capaz de colaborar con otros desarrolladores, tienes que conocer las herramientas que te permiten compartir software. Si encima utilizas Git o Mercurial, podrás llamarte Desarrollador, así, con mayúsculas.
- Patrones arquitectónicos. Para organizar el software a gran escala, hay que tener una visión global del código y por dónde quieres que crezca. ¡Dale forma a tu código!
¿Qué añadirías tú a la lista? Se aceptan sugerencias.