Entender… Algo que no todo el mundo tiene la cualidad de profundizar demasiado y me incluyo, cuando algo no te agrada y le sumas que hay que entenderlo, puede ser complicado.
Pero es parte del trabajo, parte del día a día, no siempre te van a tocar requerimientos simples y que te complazcan. Es parte del crecimiento profesional enfrentarse a problemas cada vez más grandes y con soluciones un poco más reducidas.
El porque debo entender un requerimiento antes de empezar a programar, es algo que me viene dando golpes en la cabeza desde hace tiempo, me llegó a pasar que me solicitan algo algo en el trabajo, digo que está claro, prendo mi computadora, ejecutó el ambiente de desarrollo, quiero empezar a programar y me quedo pasmado, diciendo: “que prosigue, que hay que hacer”.
Cuando te topas con eso es muy probable que no entiendas completamente el requerimiento de software y empieces a dar vueltas en un ciclo sin fin.
Así que te dejó mis recomendaciones para ser mejor programador y esclarecer los requerimientos que se vengan.
Analiza y cuestiona todo
Deberás analizar a profundidad el problema que tienes enfrente, por ejemplo te sueltan algún requerimiento como el siguiente:
“Se requiere que un formulario de contacto, tenga los siguientes campos: nombre, apellido, mensaje, teléfono, correo electrónico y se envíe a guardar a una base de datos que me permita descargar un excel cuando sea necesario”Deberían surgir preguntas como:
- ¿Dónde se debe visualizar el formulario?
- ¿Qué campos son requeridos?
- Se necesita enmascarar y/o formatear los campos ingresados por el usuario, si es así, ¿Qué formato?
- ¿Debe existir alguna longitud para los campos?
- ¿Se debería registrar alguna fecha de submit?
- ¿Se necesita validar el email o el teléfono?
- ¿Quién va a descargar los archivos excel y cuanta disponibilidad debe tener?
- ¿Se debería incluir un captcha?
- ¿Será una base de datos externa o tendrá alguna clase de integración con algo ya existente?
Entre otras…
Realmente las cuestiones que surjan harán que el requerimiento se haga un poco más claro y se despeguen las lagunas, así que siempre cuestiona lo que veas.
Diagramar todo lo necesario
A veces suele ser tedioso, pero si vas bajando todo a documentación realmente clara, como diagramas de clase si andas con programación orientada a objetos, diagramas de componentes si andas con lógica de componentes o simplemente diagramas de flujo que indiquen los escenarios principales y alternos que surjan.
Lo repito, puede ser algo que no disfrutemos hacer, lo entiendo, para la costumbre solo necesitas dar ese primer paso, verás que como pasa el tiempo se hará algo cotidiano y la documentación que generes al final, será menor el esfuerzo.
Por más sencillo que sea el diagrama, también te ayudará a externar ese requerimiento a alguien más del equipo, muchas veces las ideas se tienen en la cabeza y si tu memoria como la mía, no es la más pegajosa, te recomiendo pasarlo a una pequeña nota mental y después estructurarse en un flujo, cuando te toque ejecutar el requerimiento, verás como el código se escribe casi solo, si seguimos las mejores prácticas y los mandamientos del programador, nuestros desarrollos se llevarán un 10.