¿Cómo debo planificar y comenzar un proyecto?

Cada vez que comienzo un proyecto, decido en momentos cruciales cambiar completamente las clases principales y quedar atrapado en oscuros errores. Intento planificar con anticipación y, por lo general, empiezo con buen pie, pero luego lo hago otro día y decido que me gustaría hacerlo "de otra manera".

¿Existe algún tipo de estándar al comenzar un proyecto, como mapear clases y comenzar con pruebas unitarias? ¿Qué es una buena convención al planificar y comenzar un proyecto mediano?

El último proyecto e inicio fue un simulador de movimiento de proyectiles. Lo sé, predecible.

Cuando planifique, no planifique de antemano todo lo posible sobre la aplicación. Planifica en pequeños pasos. ¿Cuál es la funcionalidad mínima absoluta que necesita para comenzar a usar la aplicación? Comience por ahí.

Cuando comience su proyecto, solo codifique la funcionalidad mínima absoluta. Cuando lo codifique, asegúrese de escribir un código bueno y limpio con encapsulación inteligente . Esto minimizará los errores que surjan de realizar cambios más tarde.

Repite esa funcionalidad mínima hasta que estés satisfecho con ella. Luego comience a agregar nuevas funcionalidades y mejoras, una a la vez. Nuevamente, enfóquese en escribir código bueno y limpio con encapsulación inteligente.

Si planifica en pasos pequeños y escribe un código limpio, minimizará la cantidad de cambios que realmente necesita hacer. Cuando haya terminado de escribir esa primera característica, debería haber adoptado los patrones en los que se basará la base de su aplicación. Si hay problemas con esa base, sus siguientes características deberían revelar rápidamente el problema. Será más fácil ver cómo se integran las piezas. Los cambios que realice deben, en este punto, causar interrupciones mínimas.

Parece que su planificación no está ayudando. Eso no es sorprendente porque no tienes suficiente experiencia para hacer un plan factible. La solución es simple. Deja de planear tanto. Simplemente acepte que va a escribir y reescribir el código a medida que avanza. Eso está bien, porque el código es gratis, excepto por su tiempo. Si está escribiendo una aplicación de interfaz de usuario, simplemente comience con una ventana en blanco y agregue un poco a la vez hasta que haya terminado. Cuando tenga más experiencia, sus proyectos irán más rápido. Preocuparse porque está cambiando el código es como un estudiante de música preocupado por todas las notas desperdiciadas en la práctica.

Nadie sabe realmente cuál será el mejor diseño hasta que hayan codificado una cierta cantidad. Por lo tanto, el secreto del buen diseño es reconocer que su primer borrador es inevitablemente subóptimo y planear reescribir porciones más pequeñas antes y con mayor frecuencia . En lugar de desechar un programa casi completo, reescriba líneas o funciones o clases tan pronto como reconozca sus deficiencias.

Los buenos programadores experimentados tampoco suelen acertar en el primer borrador. Lo que viene con la experiencia es la capacidad de reconocer un mal diseño antes y la capacidad de reescribir más rápidamente.

En mi experiencia, este problema desaparece cuando tienes más experiencia: tienes una idea de lo que funciona y lo que no. Además, una buena encapsulación puede reducir los costos de cambiar el diseño. Cuanto más encapsulados estén sus módulos, más barato será cambiarlos más tarde. Considérelo una excelente motivación para mantener sus clases separadas.

http://nathanmarz.com/blog/suffering-oriented-programming.html

Esto aborda su problema. Comenzó simplemente asegurándose de que el software fuera posible, creando prototipos y creándolo. Luego, comienza a tomar el código y lo separa. Entonces, lo optimiza.

Hay dos aspectos para diseñar una aplicación. El primero es decidir qué puede hacer su aplicación. El segundo es diseñar cómo hacerlo. Los cambios en lo que hace son bastante significativos y, dependiendo de la madurez de la aplicación (y el cambio en la dirección de la aplicación), es mejor enfocarlos como una reescritura en lugar de volver a trabajar.

El segundo aspecto es el cómo. Usando pruebas unitarias y prácticas de desarrollo ágiles, puede minimizar el impacto de cambiar cómo se logra una función específica mediante la refactorización. Parte de aprender a aprovechar esas técnicas es practicar la práctica.

Daré el consejo que he dado una y otra vez. Elige un proyecto para mascotas. Escríbelo lo mejor que puedas. Aprenda algo nuevo y aplique lo que ha aprendido para mejorar la forma en que aborda el desarrollo de ese proyecto.

Por ejemplo, comience con una lista de Todo. Hazlo simple ... ni siquiera te preocupes por el almacenamiento de la base de datos al principio. Solo haz que funcione. Ahora comience a construir sobre esa base. Tal vez quiera aprender MVVM y WPF ... ya sabe cómo implementar la lista de tareas pendientes de la memoria, por lo que tiene un problema menos que resolver. Ahora desea que sea donde varios usuarios puedan cargar sus listas de tareas desde una base de datos. Lo resolvió en la memoria y la presentación separada, por lo que puede concentrarse en aprender el acceso a los datos. Desde allí, puede expandir la aplicación para tener un modelo de dominio más complejo (por ejemplo, cambiar de una lista de Todo a una solución de gestión de proyectos), una interfaz web o incluso hacer que se ejecute en un dispositivo móvil. La clave para hacer que esto funcione es elegir algo que usted pueda lograr con el que pueda marcar el progreso y que pueda crecer con el tiempo.

En mi experiencia, el diseño del sistema a menudo lleva tanto o más tiempo que la codificación real. Cuando dices "planificación anticipada", ¿qué es lo que realmente planeas? Tal vez vaya a la vieja escuela y use una de las metodologías de diseño probadas. O vaya a la vieja escuela y escriba el pseudocódigo antes de escribir el código real.

Creo que debe preguntarse por qué está cambiando las cosas en momentos cruciales en lugar de seguir con el plan original. ¿Era defectuoso el plan original? ¿O tuvo un momento perspicaz que mostró una mejor manera de hacer las cosas? ¿Fue realmente mejor o simplemente diferente?

A medida que gane exp necesitará reescribir / scratch y comenzar de nuevo, con menos frecuencia. Escribe el problema que intentas resolver. Escriba descripciones vagas de clases que cree que necesitará, escriba cómo necesitarán interactuar. Obtenga una idea de cómo va a funcionar todo y luego codifique. No pierdas toneladas de tiempo escribiendo cada propiedad, método de tus clases. En esta etapa, estás tratando de obtener una vista de 50K pies de lo que se supone que debes hacer. Una vez que comience a codificar, si necesita escribir más detalles, hágalo. Si no, simplemente comienza a codificar.

La razón por la que te resulta tan difícil es que tienes una idea, pero realmente no tienes una idea completa de lo que quieres que haga. Si está haciendo su propio proyecto y no tiene un cliente que le diga lo que quiere, entonces depende de usted ser su propio cliente. Ponte en el lugar del cliente y comienza a crear una lista de deseos imposible.

En otras palabras, cuando comienzas ¡¡No diseñes NADA !! .

Una vez que tenga una gran lista de cosas que desea que haga el sistema, priorice todo y decida cuál será la funcionalidad mínima para tener un sistema básico en funcionamiento. Esta podría ser una única función básica, o una pantalla completa, pero debe ser algo que sienta, ya que el cliente será lo suficientemente útil como para probar.

Entonces, Lista de características de deseos + prioridades básicas = Requisitos .

Una vez que tenga todo eso, haga un diseño de muy alto nivel. Simplemente siéntese y piense qué necesitará su sistema para poner en funcionamiento las primeras prioridades. Cambie de opinión si lo desea, pero aquí es donde es posible que desee agregar algún código o una configuración del sistema para obtener más información sobre lo que es posible. Vaya solo lo suficientemente lejos como para validar su idea básica de un diseño.

Es decir: AHORA puedes complacer los impulsos de tus diseñadores .

Una vez hecho esto, comienza a implementar sus funciones. Cree para cada característica una especificación funcional básica. Esto podría ser tan simple como una colección de declaraciones de características. Cartas de historia si quieres. Esto le permite desarrollar un poco su idea en su mente y crear un conjunto de declaraciones que se convertirán en la especificación con la que probará y desarrollará su implementación.

¡Llora estragos, deja escapar a los perros de ... Código!

A partir de ahí, implemente sus pruebas para que coincidan con sus especificaciones, luego, para cada prueba, escriba su código. Cree, "libere", luego repita con la siguiente característica hasta que decida que el proyecto está lo suficientemente completo.

Realmente se reduce a la experiencia, pero este enfoque que he encontrado es una fórmula simple para ayudarlo a enfocar su mente en lo que debe hacerse, en lugar de quedar encerrado en un ciclo interminable de procrastinación debido a tratar de hacer demasiado. una vez.

Una vez que haya hecho lo básico, como establecer los objetivos del proyecto, obtener su lista de requisitos y bloquear las interfaces a los sistemas externos.

Luego debe hacer un caso de uso o "historia" para cada interacción del usuario. Se han escrito volúmenes sobre lo que hace un "buen" caso de uso o historia y hay muchas variaciones. Los casos de uso son la herramienta de diseño más efectiva que he encontrado. Ayudan a recoger la funcionalidad faltante al mismo tiempo que eliminan requisitos innecesarios y reducen su diseño a lo esencial. Como dije, las metodologías varían, pero la mayoría de los practicantes están de acuerdo en:

• Texto conciso y sencillo en inglés.
• "Goal Driven" funciona mejor, es decir, "Monkey obtiene una uva" es mejor que "Monkey Pushes red button".
• Prohibir la terminología técnica. No hay "menús desplegables", "cuadros de texto". Un buen caso de uso debe ser independiente de cualquier tecnología de interfaz. Debería poder tomar un caso de uso para un sistema basado en HTML y usarlo para un sistema activado por voz sin ningún cambio en el caso de uso mismo. (¡Esto es muy difícil de hacer pero vale la pena!).
• Trata de reducir el conteo de palabras de tu primer borrador en un 50%, elimina los pasos innecesarios y la palabrería.

Entonces estás listo para especificar tus clases principales:

UML- Lenguaje de modelado universal. Es la herramienta estándar para diseñar clases. Usted especifica los miembros públicos y los métodos de cada clase y los vincula en un modelo gráfico claro y conciso.

En conjunción con diagramas de secuencia, modelos de datos, puede verificar y mejorar su diseño antes de que tenga lugar la codificación.

Cambie su enfoque en el resultado que desea obtener y evalúe las ganancias potenciales de aprender / probar nuevas implementaciones con el riesgo de ir por un camino que lo lleva de vuelta al punto de partida.

En el caso de que termines de nuevo en el punto de partida, no todo está perdido porque ganaste experiencia.

Si tienes una fecha límite (parece que tal vez estás programando para divertirte), entonces esto es realmente complicado. Si continuamente va por un camino, corre el riesgo de usar métodos obsoletos a medida que pasa el tiempo. Si continuamente va por el otro lado, corre el riesgo de las consecuencias de producir resultados a un ritmo más lento (un ritmo variable más lento dependiendo de los resultados de sus aventuras de aprendizaje).

Solía ​​trabajar mucho, hacer las cosas rápidamente año tras año, y luego un día me di cuenta de que me estaba volviendo no actual en mi conjunto de habilidades.