¿Cómo Empezar?
Si eras desarrollador en un equipo Ágil, tu único objetivo es cumplir los objetivos de sprint. Si es así, en el 80% de los casos, lo hará bien al comenzar a desarrollar la interfaz de usuario. Porque le da a todo el equipo algo de validación y sentido de progreso.
Sin embargo, tu proyecto paralelo en solitario no tiene que depender de la metodología Ágil. No debes responder a nadie excepto a ti mismo. Deberías intentar hacer la parte más difícil primero. Estoy hablando de abrazar verdaderamente a la bestia.
Para hacer un producto increíble, invariablemente necesitaría 1024 cosas además de resolver el problema central. Debe ser extremadamente consciente de la administración de dependencias.
Usted debe hacer el usuario de la gestión, porque ese es el punto de entrada para los datos. Los datos de usuario son y serán su producto más valioso hasta el día en que decida vender su empresa a Facebook o Google.
Con eso viene la creación de redes. ¿Recuerdas manejar cargas útiles? Tendrás que almacenar datos sin conexión y suministrarlos a través de una integración de aplicación móvil/Dropbox, en caso de que tu consumidor más valioso se transfiera a Groenlandia o el Congo.
Y con eso, ¿cómo podría olvidarse del costo que conlleva la transferencia de datos? Debe definir el protocolo que transporta su carga útil de manera rentable entre las partes: HTTP, Websockets, TCP (Protobuffers) u otra cosa.
La seguridad de datos es la dependencia final de la cadena una vez que haya definido todas las demás dependencias (a menos que su oferta principal sea resolver un problema de seguridad).
¿Cómo encripta sus datos de extremo a extremo? ¿SHA? ¿MD5? ¿Cómo implementará el apretón de manos de clave pública y privada?
Si conoces estos términos relevantes, es fácil buscar en GitHub o pedir opiniones en los foros. Un buen punto de partida es buscar cualquiera de esos términos en Wikipedia y avanzar a partir de ahí.
Aprenda sobre ellos, aprenda sobre sus alternativas y en poco tiempo será un juez experto en cada tecnología que elija para su proyecto.
Siguiente: Impleméntelos todos. Sin escribir una sola línea de lógica de negocio, es decir.
Asegúrese de leer bien.
En pocas palabras: Manténgalo lo más desconectado posible de la lógica de su negocio. Escribir con interfaces, escribir con clases/estructuras abstractas. Haga talones de prueba de concreto para probarlos.
Sí, para probar todo esto con la interfaz de usuario de primate, debe escribir algunos casos de prueba. El consejo popular en software es comenzar con casos de prueba, antes de escribir una línea de código.
TDD proporciona información sobre su base de código que un revisor experto no puede obtener. Te darás cuenta de su enorme valor una vez que implementes el siguiente paso.
Recuerda siempre: Aquí podrías equivocarte de mil maneras. Pero este paso es mucho más que una lección.
El trabajo realizado aquí nunca se pierde. Es reutilizable, porque es agnóstico de la lógica de negocios. Cuando deseches este proyecto, recuerda que siempre puedes reutilizar esta bestia para acelerar todos tus proyectos futuros. Su tiempo para desarrollarse disminuirá exponencialmente.