[SOLUCIONADO] Devs, ¿Cómo comienzan un proyecto?

Iniciado por _lautimorales, Junio 26, 2024, 10:24:20 AM

Tema anterior - Siguiente tema

0 Miembros y 1 Visitante están viendo este tema.

Junio 26, 2024, 10:24:20 AM Ultima modificación: Junio 28, 2024, 10:41:45 PM por AXCESS
Quiero saber qué maneras utilizan para iniciar un proyecto y poder guiarme mejor en el futuro.
Cuando hablo de iniciar, me refiero desde el momento en el que se tiene la idea.

Buenas, no soy experto pero partamos de la idea.....

- Ver las necesidades a cubrir para esa idea.
- Ver los requerimientos en cuanto a infraestructura, recursos, etc.
- Diseñar la aplicación.
- Comenzar la programación de la misma, codeando codeando y codeando.
- Probarla para ver si funciona como se espera. En caso contrario, volver al diseño xD
- Distribuirla y realizar capacitación a usuarios finales en caso de ser necesario.
- Realizar mantenimiento.

Lo principal es hacer un MVP. Te sugiero leer o estudiar sobre ese concepto


Lo mencionaré desde una perspectiva individual, pero en un equipo lo que cambian más que nada son las responsabilidades y quienes toman una u otra decisión. Además, lo haré con un ejemplo bastante sencillo.

1.- Analizar el problema a resolver: sumar, restar, multiplicar y dividir es lento para la mayoría de humanos, lo cual se vuelve más importante en una tienda o negocio donde hay que calcular rápidamente para satisfacer a la mayor cantidad de clientes.
2.- Dividir el problema en más problemas pero pequeños: sumar, restar, multiplicar y dividir serían los subproblemas.
3.- Requerimientos: ¿Se debe usar notación polaca o notación de infijo?.
4.- Dependencias:
    1.- Librerías de terceros o creadas por nosotros mismos: si hay que crearla, pues es un proyecto del propio proyecto y se puede entrar en un bucle hasta que no haya que desarrollar más librerías.
    2.- Infraestructura: ¿El proyecto depende de un servidor, servicio, API, etc. para poder funcionar?
    3.- Entorno: ¿Dependerá de un determinado sistema operativo o determinado entorno de usuario / espacio de trabajo?
5.- Diseñar: Crear la arquitectura de la aplicación y analizar como estará dividido todo, así como analizar la responsabilidad de cada librería o módulo.
6.- Escribir el código poco a poco, módulo por módulo, función por función, clase por clase: Escribir las cosaa poco a poco es mejor que escribir todo de una vez sin haber probado nada antes. Es mucho más rápido, sencillo y productivo saber que el error está en la última función que acabas de escribir hacer dos minutos que indagar sobre los 17 errores que tienes en tu aplicación que llevas escribiendo hacer 3 días. No necesariamente esto implica que seas lento, sino todo lo contrario.
7.- Probar cada parte (módulo, función, clase, etc.) individualmente al finalizar la escritura de los mismos y probar la aplicación como un todo (si en este punto es posible).
8.- Documentación: Tener una aplicación sin documentación es como no tener aplicación. No solo la documentación es importante para el usuario, sino también para ti y los futuros mantenedores. También es importante tener actualizada la documentación acorde a los cambios en el proyecto.
9.- Analizar la aplicación en busca de fallos y limitaciones: asume de antemano que toda aplicación tiene fallos, tanto inicialmente como por cada nuevo cambio que hagas. Aquí entra el testing. Esto también plantea las limitaciones de tu aplicación, y siguiendo el ejemplo de la calculadora, saber el mínimo y máximo con el que se pueden realizar operaciones antes de fallar o que puedan proporcionar resultados inesperados o erróneos.
10.- Desplegar: En este punto ya todos los puntos anteriores deben estar hechos, aunque recuerda que esto es un trabajo constante, pero ya habiendo llegado a un nivel de estabilización más que usable, es posible desplegar tu aplicación al entorno productivo.

Esto es realmente básico y demasiado simple, pero se puede extrapolar hasta muchos puntos más.
PGP :: <D82F366940155CB043147178C4E075FC4403BDDC>

~ DtxdF

Sumando a lo aportado: Crear bosquejos de la mecánica de la idea. El esquema te abre el panorama del cómo sería la ejecución. Después se abren los caminos de las herramientas a usar