Este octubre os propongo lanzar una aplicación que va a funcionar solamente en nuestras mentes, en nuestros corazones y sobre el papel (digital). Vamos a reclamar como trabajo una parte que a veces se nos olvida clasificar como tal: la planificación.
Vamos directos al problema
Particularmente en programación hay como una urgencia por empezar tareas nuevas, una necesidad de lanzarse sobre teclado y editor, y darle duro al código.
Podemos echarle la culpa a varios factores como este entorno de inmediatez en el que vivimos, las prisas de "arriba", igual la falta de experiencia y así... el resultado es que acabamos sintiendo que no tenemos espacio para pensar o que directamente es tiempo mal invertido.
Esto es un problema porque raramente una solución de código permanece inalterable desde que empezamos a aplicarla hasta que terminamos la tarea. En medio está la vida y el mismo proceso hace que debamos variar el camino o que tengamos que elegir entre varias opciones.
Me gustaría hablar de esto con un pequeño ejemplo de una aplicación que hice durante unas vacaciones.
Dar forma a la idea
Las decisiones que más me cuestan son las que no tienen presión ni urgencia ni casi necesidad y como contaba con unos días libres me dije "pues hazte algo que decida por ti".
Dando por sentado que es un proyecto chiquitico y modesto no quiero ni pensar que me hubiese lanzado a picar sin haberlo definido algo más.
De primeras me surgen varias preguntas:
- ¿Qué necesito?
- ¿Cómo va a decidir?
- ¿Entre cuántas opciones?
- ¿Cómo añado las opciones?
- ¿Cuántas necesito de base?
- Tras la decisión, ¿qué pasa?
- ¿Va a hacer algo más?
Suelo preferir empezar con papel porque permite iterar más rápido y yo elijo cómo trabajo; no dependo de una forma concreta de "hacer", como pasaría en una aplicación. Eso no quita para que luego lo pase a limpio.
En este caso empecé con una serie de ideas sobre el funcionamiento general, separando lo troncal de lo opcional.
El papel con estas notas lo perdí y solo tengo el esquema en limpio:
Me he decidido por una lista pequeña de 3 opciones, quiero que sea rápido y fácil de usar así que me tendré que centrar en evitar todo lo que no vaya en esa línea.
No quiero que haya hasta 3 opciones, quiero 3 porque con menos me es fácil elegir pero si tengo muchas creo que me va a costar diferenciar las "importantes" de las de relleno. Como luego va a ser una elección aleatoria no quiero acabar haciendo algo que he puesto por poner.
Como extras he añadido ideas que me resultan interesantes pero para nada son el objetivo principal.
Una vez acotado qué quiero ya puedo moverme a cómo va a suceder.
Siempre intento ir al código cuando ya está el problema solucionado; que funcione primero en papel y ya solo hay que escribirlo.
Esto además limita bastante las distracciones, que van a estar pero mucho menos porque ya se ha definido un camino claro y tenido en cuenta un número de imprevistos.
El funcionamiento
Hecho esto, vamos a definir cómo va a funcionar nuestra aplicación.
No si voy a usar un array, un objeto, o si voy a necesitar un for o dos. Seguimos sin tocar el editor de código.
Lo que quiero es saber cómo voy a ordenar las ideas anteriores para que mi aplicación haga lo que quiero que haga. Aquí va mi propuesta:
Un esquema ya me deja mucho más claro por qué camino voy a tirar y me va a marcar las prioridades sobre aquella primera lista de ideas.
Y claro que lo podemos pasar a limpio. Ver las cosas más ordenadas nos hace sentir mejor y da cuerpo a nuestro trabajo; o quizás queramos enseñarlo.
En limpio tiene este aspecto:
Es lo mismo pero de otra manera. Si me hubiese metido con un programa de flujos a pintar esto directamente, incluso siendo tan pequeño, habría invertido más tiempo distraído con cómo tiene que quedar además de qué quiero que pase.
Una vez ordenado en mi cabeza ya puedo ir a tiro hecho.
Además, esto es como una primera vuelta, todavía tengo que afinar más cómo va a ser la interacción, si me hubiese metido a escribir código desde cero en algún momento tendría que lidiar con la propia planificación y el código que vaya generando.
Esto añade una capa de complejidad totalmente gratis y un poco abre la puerta a ese impulso por mantener el código actual.
¿Qué necesidad hay?
Segunda vuelta
Con este primer esquema tenemos una dirección pero es muy genérico. Habría que ver cómo va a ser ese paso entre tareas, qué pasa cuando todas estén rellenas, se va a poder usar solo con teclado, sin usar el ratón?, lo típico...
Partiendo del primer esquema intenté concretar un poco más cómo iba a ser este flujo de trabajo siempre teniendo en cuenta aquel primer listado de ideas.
Aquí tenemos ya el proceso mucho más acotado, tras escribir la primera tarea con un simple enter pasaremos a la siguiente sin rellenar y cuando todas estén rellenas haremos foco al botón para que baste otro enter para activar la selección.
El paso del primer esquema al segundo, en bonito, quedaría así:
Podemos ver cómo ha evolucionado un poco el primer planteamiento. Y además, lo he pasado a limpio que siempre es más agradable.
Teniendo la aplicación encaminada ya habrá que ir acercando el teclado. Aunque antes de meterme con el código me gustaría tener una lista de los diferentes estados de los elementos que voy a necesitar según ese guión; una visión más en detalle donde ya estructuro un poco más todo lo que envuelve a mi esquema.
Tampoco voy a necesitar mucho:
- Páginas o vistas
- Campos
- Botones
Quedaría algo así:
Conclusiones
Personalmente, este enfoque me ayuda a concentrarme, entender el proyecto, a poder repartir mejor la carga de trabajo, y con eso gestionar la presión. En definitiva, allana el camino, que se dice pronto.
Aquí lo estoy contando con un poco de detalle pero todo este proceso igual lleva una horita de trabajo.
Y ahora estamos en una posición muy diferente a la hora de enfrentar el código.
Como extra, también me ayuda, por qué no, a disfrutar más del proyecto. Que no somos escopetas.
Bonus
Al final escribí el código e hice la aplicación 😉
