¿La mejor manera de planificar una tarea?

Question

Como soy muy nuevo en la programación, tengo mucha curiosidad por aprender las mejores formas/prácticas de programación.

Cuando quiera escribir cualquier programa, empiezo directamente con la codificación, mientras que algunos dicen que primero debe planificar su programa antes de iniciar el código.

Pero no entiendo el valor real de crear diagramas de clase y todo ese tipo de cosas porque creo que en última instancia tengo que escribir el código.

¿Pueden compartir sus experiencias sobre cómo están haciendo su programación? Quiero decir, ¿cuál es tu primer paso cuando comienzas una aplicación?

Answer 1

A veces una gran tarea es desalentadora, lo que incluso puede hacer que "simplemente se codifique" sin planificación imposible, ya que simplemente no se sabe por dónde empezar. Recuerdo que hace años solía quedar atrapado durante años tratando de trabajar en algo nuevo, porque me habían criado en una posición en la que mi trabajo principal consistía en hacer mejoras: no tenía experiencia de trabajar con un lienzo en blanco. Era paralizante, incapaz de comprometerse con un enfoque porque podría ser una opción de diseño subóptimo.

Pero de todos modos, en estos días tiendo a sentarme con papel y repetir el diseño.

Si es grande, comenzaré a esbozar cómo las partes funcionarán por separado y, finalmente, estas piezas se unirán. Intento convertirlo en clases o módulos y luego descubriré que hay redundancias en el diseño, o hay algo allí que simplemente no funciona. Así que empiezo de nuevo, lo apunto con un mejor enfoque ... y descubro más problemas. Continúo iterando, obteniendo una mejor comprensión del problema en cada barrido. (Las pizarras digitales pueden ser buenas para levantarte, siendo físicas y resolviendo problemas espinosos)

Cuando tengo un diseño de diagrama de flujo/psuedo bastante detallado que no tiene problemas obvios, es cuando comienzo la codificación.En un entorno formal, el boceto de diseño final es lo que convertiría en una especificación y distribuiría a los usuarios/desarrolladores para su revisión.

A menudo, con un diseño complicado, voy a transformar este bosquejo del diseño en los comentarios que me guía como el código I, que es más rápido y más preciso que tener que consultar mis notas cada 2 segundos:

// open file 
// read header line 
// check header is right (watch for int problem) 
// select right config object 
// loop over lines, read each line into config object 

Y Yo convierto cada comentario en código.

Esto es mucho más eficiente que codificarse en un callejón sin salida y tener que escribir y reescribir simplemente porque no tenía un control sobre el problema desde el principio. Esto no significa que el diseño ya no cambiará, todavía encontrará problemas, pero algunos errores importantes del diseño pueden ser eliminados antes de llegar al IDE.

Hay muchos enfoques para el diseño, esto es lo que funciona para mí. Lo mejor puede variar según el tipo de proyecto y el tamaño del equipo.

Answer 2

Soy fan de CRC Cards.

CRC significa Clase, Responsabilidad, Colaboración. Utiliza un conjunto de tarjetas postales, donde cada tarjeta representa una clase, y enumera de qué es responsable y cómo colabora con otras clases.

Dada una lista de características, y/o un conjunto de casos de uso, las tarjetas CRC facilitan "representar" las diversas funciones del software, asegurando que existan clases para realizar las acciones necesarias, y que las relaciones entre esas clases existen para permitirles trabajar juntos de manera adecuada.

Answer 3

Estoy usando algo así como tarjetas CRC "reallife" - Solo tomo unas hojas de papel y un bolígrafo y empiezo a dibujar las clases y sus métodos y todas sus dependencias. Los otros documentos se utilizan para obtener información más detallada sobre la funcionalidad.

Answer 4

Si es la primera vez que programa, empiece con lo básico: Aprender a programar. Escriba algunos pequeños "hello world" programs y amplíe su conocimiento a sitios web o aplicaciones de Windows. Aprenda a escribir programas que cumplan con sus requisitos. Si no tiene ningún requisito, escríbalo antes de comenzar, de lo contrario su programa no tendrá línea de llegada.

Cuando se sienta listo para emprender proyectos más grandes, puede tomar clases y diseño de objetos usando UML y aprender test-driven development para escribir un código más sólido. Obtenga más información sobre las diferentes metodologías de desarrollo, como Agile y Scrum. Los proyectos más grandes requieren planificación y buenos diseños, por lo que debe conocer sus teorías.

Answer 5

No se quede atrapado en los diagramas de clases, etc., el objetivo principal de tomarse un tiempo para pensar en lo que quiere hacer es poder organizar su aplicación en un producto robusto. Cuando te sientas y pienses de antemano como si estuvieras haciendo algunos casos de uso sobre lo que tu programa debería hacerte mirando efectivamente desde otro ángulo, puedes encontrar cosas que no son tan obvias. Una cuestión de abstracción

Si comienza a codificar directamente, a menudo se ve atrapado en los detalles de la implementación y puede olvidarse del objetivo creando una solución muy estrecha y frágil.

Un poco como abrirse camino a través de la jungla de la A a la B y exhausto tirarse al suelo cuando llegas allí, entonces has creado un camino de A a B pero lo que realmente querías era una carretera bien establecida de a a B.

Answer 6

dos puntos con la planificación y la preparación son:

• para asegurarse de que usted y la cuota de clientes de la misma visión del problema.
• Para exponer posibles problemas con su idea sobre cómo resolver el problema.

La forma de hacerlo depende de la situación, pero el punto es llevar a cabo los dos puntos por encima de lo más barato posible. Dibuje bocetos, discuta, haga un prototipo de baja fidelidad, create a pilot system.

Answer 7

Si desea escribir un buen programa, especialmente uno que desee cambiar y mejorar más adelante, entonces valdrá la pena hacer algún diseño antes de meterse en el código de escritura.

"Crear diagramas de clase y todo ese tipo de cosas" es en realidad una forma de escribir en papel lo que ya estás pensando: qué clases necesitas, qué datos almacenan y cómo se relacionan las clases con El uno al otro. No tiene que seguir ningún proceso formal: creo que las cajas y flechas crudas funcionan bien para organizar mis pensamientos.

A medida que paso más tiempo con un programa, generalmente encuentro que descubro algunas formas mejores de organizar los datos o mejorar las relaciones entre las clases. Cuando esto sucede, el punto crucial es que es mucho más fácil y rápido garabatear y volver a dibujar algunas cajas de lo que es tirar un archivo de 200 líneas escrito en C++ cuidadosamente depurado y comenzar de nuevo.