¿Cómo se diseñan y desarrollan los programas? Antes de programar un programa, el flujo de datos, la salida y la lógica para llegar allí están diseñados. ¿Cómo comienzas este proceso?

Answer 1

Diseño mis programas de arriba hacia abajo y de atrás hacia adelante (o de extremo a centro).

Comienzo con la salida deseada. ¿En qué formato está? Si se va a presentar visualmente, probablemente tendré que diseñarlo primero. Luego miro las entradas. ¿Qué partes de la entrada van a influir en qué partes de la salida?

Ahora diseño tipos de datos (clases) para contener los datos de salida, cada uno con un método para generar sus datos o una clase correspondiente de “escritor” que convierte los datos de salida en su forma de salida visual u otra forma de salida deseada.

A continuación, ¿cómo llego de la entrada a la salida? Esto generalmente se parece a esto:

Tipo (s) de entrada: un lector para cada fuente de entrada y una o más clases para contener los datos de entrada una vez que se han leído (o ingresado a través de una GUI o lectura detectada desde sensores externos).

Así que ahora tengo los tipos de entrada y salida. Por lo general, solo necesito algunas clases adicionales para transformar la entrada en salida. A veces el trabajo es más complicado y utilizo el patrón de diseño del Adaptador o Puente para hacer la conversión. Algunas veces tuve que construir dos puentes: desde el formato de entrada a algún formato intermedio, luego desde el formato intermedio hasta el formato de salida.

Esto último es más común cuando los requisitos dicen que se supone que debe mantener los datos de entrada para su uso futuro. Tomará los datos de entrada, los convertirá en filas de la base de datos y usará una clase de interfaz DBMS para escribirlos en el RDBMS. Luego, un segundo convertidor para convertir las filas RDBMS al formato de salida. Usé esto mucho cuando era parte de un equipo que mantenía el sitio web orientado al cliente para un fabricante de automóviles.

Aprenda el patrón MVC – modelo-vista-controlador para sistemas GUI, y el patrón correspondiente de “tres niveles” para sistemas que tienen una base de datos y una GUI o interfaz orientada a caracteres. Vea model-view-controller y arquitectura multinivel en Wikipedia.

Entonces, ¿cómo comienzas el proceso? Mire sus salidas deseadas y sus entradas, y piense cómo puede derivar una de la otra.

NOTA: algunos problemas son más difíciles que otros. El último lugar donde trabajé a tiempo completo tenía su propio sistema de comercio electrónico. Había un diagrama de clase para ese sistema. Cubría 16 pies de pared, tamaño estándar impreso (tipo 11pt) en papel 8–1 / 2 × 11. Eso probablemente tomó un tiempo solo para diseñar. Pero apuesto a que comenzaron de la misma manera: cuáles son las entradas [del vendedor y del comprador] y las salidas [nuevamente para ambos, más la auditoría y otras salidas para nosotros, las personas que proporcionaron el sistema de comercio electrónico a los vendedores] . Entonces, ¿cómo almacenamos estos en una base de datos? ¿Cómo llegamos de A a B a C?

Answer 2

Hay muchas formas de comenzar. Una forma es enumerar todos los requisitos del programa. Luego, generalmente dedica una buena cantidad de tiempo a delinear las estructuras de datos. Muy a menudo, estos son más fudamentales, y los algoritmos surgirán una vez que tenga las estructuras de datos correctas.

Después de haber hecho todo eso, a veces es útil diseñar los algoritmos reales escribiendo “código psuedo” … escribiendo todas las acciones y el flujo de control del programa en un resumen organizado y sucinto, pero haciéndolo en un lenguaje más cercano a un lenguaje humano

Después de eso, escribir el código del programa generalmente es solo una cuestión de comprender la sintaxis del programa y qué capacidades admite el lenguaje.

Answer 3

Averigua qué se supone que debe hacer la aplicación. Cada una de las cosas que se supone que debe hacer (pantalla de inicio de sesión, entrada del usuario, pantallas de resultados, etc.) son “características”.

Luego, descubra aproximadamente cómo crearía cada característica (no entre en demasiados detalles, pero necesita una idea general).

¿Sus características necesitan datos o necesitarán almacenar o cambiar datos? Ese es su diseño de base de datos de back-end.

¿Cómo verán e interactuarán los usuarios con sus características? Ese es su diseño frontal.

Hay muchos otros problemas, pero estos son los más importantes para comenzar.

Answer 4

Solo puedo describir cómo diseño y desarrollo software:

Definitivamente no diseño todo el flujo de datos, salida y lógica antes de comenzar a codificar.

Comenzaré con una idea, tal vez un gran concepto. Abriré un editor y hackearé un código que implementa una parte del concepto, solo para ver si puedo obtener algo que funcione.

Después de eso, escribo algunos casos de prueba alrededor de mi truco, pensando en cómo debería funcionar en el programa completado. Entonces podría descubrir que para ser eficiente o para hacer el siguiente bit, necesito otro conjunto de funciones, clases, etc. Luego escribiré casos de prueba para ese nuevo código, luego escribiré el nuevo código y continuaré hasta que todo de mis casos de prueba pasan. Ejecuto mis casos de prueba regularmente.

Como idea, estoy trabajando en un marco de aplicación (como un proyecto de pasatiempo), comenzó como un hack de alrededor de 100 líneas en un archivo, se ha transformado gradualmente en un proyecto con más de 40 códigos fuente con más de 10,000 líneas de código y casi 1000 casos de prueba, y el marco aún no está terminado.

Esto es (en efecto) Desarrollo impulsado por pruebas.

Answer 5

Voy a puntuar un poco y solo darles un par de cosas para leer, dos estrategias de desarrollo diferentes. el modelo de cascada es aproximadamente lo que supone su pregunta, por lo que el modelo iterativo puede ser de su interés. ambos tienen sus usos, pero el modelo iterativo parece ser más popular en estos días.

Modelo de cascada – Wikipedia
Desarrollo iterativo e incremental – Wikipedia

Answer 6

Comienzo reuniendo primero los requisitos para lo que el programa necesita hacer. Luego determino cuánto diseño es apropiado para el problema que estoy tratando de resolver.

Los scripts de desarrollo generalmente no están diseñados, así como los algoritmos de representación, por ejemplo. A veces creo diagramas de flujo. Otras veces sigo Test Driven Development.

Siempre empiezo pequeño y escribo el código más simple que funcionará. Pruebo a menudo e implemento características cuando son necesarias. Llego a un estado de ejecución y mantengo mi programa en ese estado durante el desarrollo. Siempre planeo cómo probar mi código.

En mi experiencia, la respuesta a cuánto diseño y qué metodología de diseño depende del contexto. Depende de la programación y el presupuesto y de dónde se usará el código.