design - para - tutorial django

¿Cuál es el flujo de trabajo que sigues para diseñar el software que estás a punto de escribir? (6)

Al trabajar en proyectos personales de tamaño mediano, ¿qué especifica antes de comenzar a codificar?

Especifico la especificación funcional :

Temía que podría ser demasiado fácil, si comencé a codificar (que es el "cómo"), a olvidar "por qué" y "qué" quería codificar (para un software "bastante complicado", durante los meses o años que podría llevar desarrollarse).
También quería entender, más o menos, el "alcance" de lo que estaría desarrollando: para evaluar aproximadamente (en un orden de magnitud):
- Qué tan grande será
- Si podría terminarlo
- Si valió la pena comenzar
- ¿Qué subconjunto puede desarrollarse primero?

En aras de la gestión de riesgos , añadiré que parte de lo que quería desarrollar implicaba el uso de algún software con el que no estaba familiarizado; para minimizar el riesgo asociado con eso, también hice un pequeño prototipo de descarte.

¿Cómo?

Esbocé una especificación funcional , usando un lápiz y un papel. Algo de lo que escribí fue de alto nivel (un documento de "visión" de nivel empresarial), y algunos eran de nivel inferior, más parecido al diseño (algunos de los detalles de la UI). A veces me detenía y desconcertaba sobre cómo organizarlo, pero luego proseguía, razonando que cada página es más o menos cohesiva sobre cada tema, y que luego puedo descifrar cómo organizar las páginas (al igual que tu wiki, tal vez )

Lo hice y no especifiqué la arquitectura del software por adelantado:

Comienzo el desarrollo con una arquitectura básica (algunos pequeños componentes) en mente y luego agrego el código; y, como agrego código, si algún componente se vuelve demasiado grande y complicado, entonces lo subdivide en varios componentes más pequeños ... es un proceso evolutivo ... como dice Systemantics , UN SISTEMA COMPLEJO QUE FUNCIONA SE ENCUENTRA INVARIABLEMENTE PARA HABER EVOLUCIONADO DE UN SISTEMA SIMPLE QUE FUNCIONÓ.
No estoy documentando la arquitectura; o, más bien, la única documentación de la arquitectura es el código en sí: por ejemplo, la forma en que el código fuente está organizado en directorios de origen, espacios de nombres y DLL.

Tengo una justificación teórica para la arquitectura tal como está ahora, pero no he documentado estas razones:

Soy el único desarrollador
La arquitectura real está documentada por el código
Los motivos de la arquitectura están en mi cabeza, y son [re] descubiertos por cosas como las convenciones de nomenclatura en el código fuente y las dependencias de los diversos componentes

Si (solo si) no fuera el único desarrollador, entonces podría pensar que vale la pena documentar la arquitectura y su fundamento.

Lo que dije antes sobre la arquitectura del software también es cierto para los datos que procesa el software.

En cuanto a las pruebas , código un poco y luego probarlo; o escribe una prueba y luego codifica la funcionalidad que pasará esa prueba. No estoy haciendo una "integración de Big Bang", es decir, meses de escritura sin ninguna prueba.

Una de las mayores debilidades en (o algo que falta en) mi proceso es estimar el esfuerzo por adelantado, y luego hacer un seguimiento de la implementación contra la estimación ... esta es una de las diferencias entre este proyecto ''personal'' versus un proyecto pagado que yo '' d hacer por alguien más comercialmente. Sin embargo, dudo si esto es bueno: si la estimación es una mejor práctica comercial, entonces tal vez debería "hacerlo" también en un proyecto personal.

Empecé a trabajar en un software bastante complicado. Es para un proyecto personal, pero aún así estoy poniendo mucho esfuerzo en ello. Ahora, estoy acostumbrado a trabajar en soluciones / diseños de otras personas o en proyectos que crecen de una manera muy controlable.

Esta vez, comencé dos veces a codificar los conceptos básicos y rápidamente me encontré atascado. Así que tomé un descanso y decidí escribir la solución completa antes de codificar una sola línea. Lo que hice (en orden) es:

escribir los casos de uso en forma de comandos CLI (esta es una aplicación de línea de comandos)
escribe algo de ayuda
diseñar las clases, la estructura de los archivos de datos y el flujo de trabajo funcional para las diversas partes.

Ahora, voy muy lento en esta parte. He creado una wiki personal y la estoy usando para escribir esas especificaciones, pero claramente siento mi falta de experiencia y una metodología clara.

Soy consciente de que el diseño de software es un tema muy complejo y que se han escrito muchos libros, pero me gustaría que compartas tu experiencia / consejos / metodología.

Al trabajar en proyectos personales de tamaño mediano, ¿qué especifica antes de comenzar a codificar? ¿Cómo?

Gracias por adelantado

Dibuja las pantallas
Dibuja las relaciones de datos (rdbms o en memoria)
Comience a codificar
Lather, Rinse, Repeat (o en el programador-lingo GOTO 1)

Comenzaría con una implementación mínima y agregaría más funciones en cada iteración.

Básicamente, las pantallas. Ellos son la interfaz entre el usuario y el software. Por lo tanto, trato de identificar cada caso de uso (el usuario buscará mi producto, el usuario agregará un producto a su caddie), el usuario verificará su caddie y yo crearé una cadena de pantallas para cada uno de ellos.

Los mejores deseos.

Encuentro una hoja de papel en blanco y un bolígrafo es el mejor punto de partida:

bosquejar unos pocos diagramas ásperos
Anote algunas ideas / notas
escribe un pseudo-código
pensar en los principales casos de uso
pensar en posibles problemas

No dedique más de media hora a esto, y no se empantane en demasiada documentación o diseño inicial. Comience a codificar tan pronto como tenga una vaga idea de cómo quiere hacerlo. A medida que continúe desarrollándose, tendrá una idea de si el código es lo suficientemente bueno o no. Si no estás contento, piensa en lo que no te gusta y comienza de nuevo con esas lecciones en mente. Refactorizar a menudo y pronto, cuanto antes mejor. Si algo no "se siente bien", probablemente no lo sea.

Hay muchas personas con mejor experiencia que yo que te pueden ayudar con detalles aquí, pero tengo un punto que creo que siempre vale la pena tener en cuenta.

No necesita obtenerlo 100% perfecto la primera vez. De hecho, si apunta a eso, probablemente nunca termine. La realidad es que no comprenderá el diseño por completo hasta que haya construido el sistema una vez.

Simplemente comience, continúe avanzando, manténgase al tanto de la cobertura de prueba de la unidad y, a medida que comprenda mejor el sistema y sus complejidades, reordene cada vez más para mejorarlo .

Escribe los casos de uso como lo hiciste.
Elija 1 del caso de usos e impleméntelo por completo, e implemente nada más. Esto incluye pruebas unitarias, ayuda y manejo de errores, todo. Llamar a esta versión 1.
Implementar el próximo caso de uso. Esto puede ser simplemente agregar código o puede requerir un rediseño completo. Está bien, sabes lo que estás haciendo ahora. Haga una nueva versión.
Repita el paso 3.