Disclaimer: Este post no tiene nada que ver con religión. Respetamos todas las creencias y la fé que tienen nuestros amables lectores.
Leerás los requerimientos antes de empezar a codificar
Sabemos que nos encanta el código pero… trata de resistir la tentación de iniciar a codificar si antes haber leído tu lista de requerimientos, que esperemos que tu compañero Business Analyst haya preparado para ti. Si no hay una lista de requerimientos, créala, te aseguro que tu alter ego frustrado del futuro te lo agradecerá.
Diseñarás la arquitectura de tu aplicación antes de iniciar con el código
El mes pasado estuve leyendo el libro más reciente del Uncle Bob (a. k. a. Robert C. Martin): Clean Architecture: A Craftsman’s Guide to Software Structure and Design y en particular encontré muy buenas opiniones acerca de qué tan importante es sentarnos y pensar cómo vamos a construir nuestro sistema, no sólo se trata de la cuestión técnica de cuál framework usar, o si usaremos REST o GraphQL sino ir más allá, diseñar interacciones (inputs/outputs), prever casos dónde nuestro sistema pueda fallar, etc.
Una de las cosas que normalmente no hacemos es priorizar nuestras tareas. Y me gustó mucho esta frase:
I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.
– Dwight D. Eisenhower
Imagen de SafariBooksOnline.
Those things that are urgent are rarely of great importance, and those things that are important are seldom of great urgency.
Es decir, si algo es urgente casi nunca es importante y viceversa las cosas importantes rara vez son urgentes. La arquitectura de un sistema es algo IMPORTANTE.
No desearás el framework de tu prójimo
A todos nos encanta probar nuevos frameworks, la más reciente biblioteca para hacer tal cosa, lo más moderno, sin embargo, otra vez, trata de no desear lo que otros están usando y en su lugar pregúntate ¿realmente necesito migrar esta funcionalidad? ¿qué beneficios le traerá a mi cliente este cambio? ¿cuánto va a costar implementar tal o cual cosa? ¿qué tan importante es probar la nueva tecnología? ¿puedo re-usar partes de lo que tengo? ¿qué valor agregado me dará cambiarme ahora mismo? ¿estoy listo para dar el salto?
Te aseguro que después de responder las preguntas anteriores estarás más en paz con tu implementación y sabrás qué camino tomar.
Usarás un controlador de versiones
¿Verdad que no hay nada más triste que llegar a un proyecto y darte cuenta que nunca se guardó en un Version Control System (VCS)? Si puedes usar Git mejor; si no puedes por políticas internas no importa, pero por favor usa un controlador de versiones, te quitará muchos dolores de cabeza y reducirá drásticamente los errores en tu ciclo de desarrollo de software.
Crearás un conjunto de pruebas (si son automatizadas mejor)
Sí, estoy de acuerdo; crear pruebas para un sistema es una de las tareas más cansadas, largas y hasta tediosas, sin embargo son un excelente punto para asegurar la calidad de tu software y más aún, estarás creando un mecanismo para ayudarte a reducir la cantidad de errores cuando se agreguen nuevas características o se cambien las ya existentes.
Escucharás atentamente a tu equipo, ellos tienen mucho que aportar
Que no te gane el ego, todos tienen una opinión y una forma de ver las cosas. Nadie tiene la verdad absoluta; recuerda existen tres verdades:
- Tu verdad: lo que tu crees que es lo mejor y lo más correcto
- La verdad de tu prójimo: lo qué él cree que debería hacerse
- Y la verdad: lo que realmente es correcto (ésta suele ser una combinación de las dos anteriores).
Pensarás antes de criticar el código de tu prójimo
Antes de decir ¡que $#$%@ es esto! Investiga, lee, documéntate, quizá quien creó el sistema o aplicación, lo tuvo que hacer en un tiempo muy corto y por ello no tuvo los recursos para crear algo mejor.
Quizá el ingeniero anterior tenía muchas dudas pero no fueron resueltas en el tiempo apropiado y tuvo que salir a producción con lo que tenía.
Quizá el cliente cambió los requerimientos a última hora. Esto casi no pasa ¿verdad?
Estarás en comunicación con tu Project Manager
Los Project Managers no son dioses, no son intocables, diles cuando no te sientas cómodo con los tiempos que te dieron para hacer tus tareas, que sepan que te están causando conflicto en tu vida porque ahora tendrás que desvelarte durante 4 meses para poder salir en el tiempo previsto.
Ellos son tus compañeros, son tus aliados y colegas, hazlos partícipes de tus preocupaciones. Qué sepan que vas a tener que hacer mucho más de lo que en su sistema de tracking de tareas dice.
Pedirás ayuda cuando lo necesites
Aceptémoslo, siempre hay alguien mejor que nosotros, y tu siempre sabrás algo más que otra persona. No cierres tus pensamientos a sólo lo que tu crees que es mejor, pregunta, lee y busca la opinión de quienes ya han recorrido por más tiempo este apasionante pero complicado mundo de la creación de software.
Encuentra a quien admirar, síguelo, busca su código, lee sus ideas, escríbele. Te aseguro que hay mucha sabiduría en esas personas que llevan muchos más años en estos caminos.
Buscarás en Google o Stack Overflow antes de preguntar
Tu tiempo es valioso, así como el de tu prójimo también lo es. Busca por tu cuenta primero, lee, estudia y analiza; tenemos mucha información en internet y claro en nuestro amado Stack Overflow, trata de solucionar tus tareas, primero por ti mismo.
Sin embargo, tampoco dejes que pase mucho tiempo, si ya pasaste más de tres horas con un problema y no encuentras la solución, entonces pregunta a tu prójimo, tal vez pueda ayudarte.
Tu servidor,
Alex Arriaga
Spoiler alert!