Diseño y amp; Codificación: ¿de arriba a abajo o de abajo hacia arriba? [cerrado]

Question

Al codificar, ¿cuál es, en su experiencia, un mejor enfoque?

1. Divida el problema en piezas lo suficientemente pequeñas y luego implemente cada pieza.
2. Analice el problema, pero luego implemente usando un enfoque de arriba hacia abajo.
3. ¿Algún otro?

Answer 1

Esto es lo que hago:

Comprenda el dominio primero. Comprende el problema a resolver. Asegúrese de que usted y el cliente (¡incluso si ese cliente es usted!) Estén en la misma página en cuanto a qué problema se debe resolver.

Luego se propone una solución de alto nivel al problema y, a partir de eso, el diseño se convertirá en burbujas o viñetas en una página o lo que sea, pero el punto es que se sacudirá en componentes que se pueden diseñar.

En ese momento, escribo pruebas para las clases aún por escribir y luego realizo las clases para aprobar esas pruebas.

Utilizo un enfoque de prueba primero y construyo componentes probados que funcionan. Eso es lo que funciona para mí. Cuando se conocen las interfaces de los componentes y se conocen las 'reglas' por la forma en que se comunican entre sí y se prestan servicios, entonces generalmente se convierte en un sencillo ejercicio de 'enganchar todo'.

Así es como lo hago, y me ha funcionado bien.

Answer 2

Tiendo a diseñar de arriba hacia abajo e implementar de abajo hacia arriba.

Para la implementación, construir las piezas funcionales más pequeñas y ensamblarlas en las estructuras de nivel superior parece ser lo que mejor me funciona. Pero, para el diseño, necesito comenzar desde la imagen general y desglosarlo para determinar cuáles serán esas piezas.

Answer 3

Es posible que desee consultar el Manifiesto ágil . De arriba hacia abajo y de abajo hacia arriba se basan en el diseño y construcción de Built It All At Once.

El "Software de trabajo sobre documentación completa" significa que lo primero que construyes es la cosa útil más pequeña que puedes ejecutar. ¿Parte superior? ¿Fondo? Ninguno.

---

Cuando era más joven, trabajaba en proyectos que eran, por contrato, estrictamente de arriba hacia abajo. Esto no funciona De hecho, no puede funcionar. Como resultado, obtienes montañas de código y diseño redundantes. No era un enfoque sólido cuando se aplicaba sin pensar.

Lo que he notado es que el enfoque ágil, piezas pequeñas que funcionan, tiende a dividir el problema en partes que se pueden comprender de una vez. El top-down / bottom-up ya no importa tanto. De hecho, puede que no importe en absoluto.

Qué leads hacen: "¿Cómo se descomponen para el desarrollo ágil?" El truco es evitar crear Una gran cosa que luego debe descomponer. Si analiza un problema, encuentra actores que intentan lograr casos de uso y fallan porque no tienen toda la información, o no la tienen a tiempo, o no pueden ejecutar sus decisiones, o algo así.

A menudo, estas no son grandes cosas que necesitan descomposición. Cuando lo están, debe resolver el problema en la dirección Objetivos hacia atrás . Desde objetivos a cosas que le permiten alcanzar ese objetivo a cosas que permiten a los habilitadores, etc. Dado que los objetivos son a menudo grandes cosas, esto tiende a ser de arriba hacia abajo, desde el objetivo comercial general hasta el proceso comercial detallado y el paso.

En algún momento, presentamos una visión general de estos diversos pasos que conducen a los objetivos. Hemos hecho la parte de análisis (desglosar las cosas). Ahora viene la parte de síntesis: reensamblamos lo que tenemos en cosas que realmente podemos construir. La síntesis es de abajo hacia arriba. Sin embargo, no nos dejemos llevar. Tenemos varios puntos de vista, cada uno de los cuales es diferente.

Tenemos un modelo. Esto a menudo se construye a partir de detalles en un modelo conceptual más amplio. Luego, a veces se descompone nuevamente en un modelo normalizado para OLTP. O descompuesto en un esquema de estrella normalizado para OLAP. Luego trabajamos de nuevo para crear una asignación ORM a partir del modelo normalizado. Arriba - Abajo - Arriba.

Tenemos procesamiento. Esto a menudo se construye a partir de resúmenes de los procesos comerciales hasta los detalles de los pasos de procesamiento. Entonces el software está diseñado en torno a los pasos. Entonces el software se divide en clases y métodos. Abajo - Arriba - Abajo.

[ Digresión . Con usuarios ilustrados, esta descomposición define nuevos títulos de trabajo y formas de trabajo. Con usuarios no iluminados, los trabajos antiguos permanecen y escribimos montañas de documentación para mapear los trabajos antiguos en el nuevo software.]

Tenemos componentes. A menudo miramos las piezas, vemos lo que sabemos sobre los componentes disponibles y hacemos una especie de coincidencia. Este es el proceso más aleatorio; es similar a la forma en que se forman los cristales: hay centros de nucleación y el tipo de diseño se solidifica alrededor de esos centros. Servicios web. Base de datos. Gestión de transacciones. Actuación. Volumen. Diferentes características que de alguna manera nos ayudan a elegir componentes que implementan parte o toda nuestra solución. A menudo se siente de abajo hacia arriba (desde la característica hasta el producto), pero a veces de arriba hacia abajo (`` estoy sosteniendo un martillo, llamo todo un clavo '' == uso el RDBMS para todo).

Eventualmente tenemos que codificar. Esto es de abajo hacia arriba. Mas o menos. Tienes que definir una estructura de paquete. Tienes que definir las clases como un todo. Esa parte era de arriba abajo. Tienes que escribir métodos dentro de las clases. A menudo hago esto de abajo hacia arriba: desglosar el método, escribir una prueba unitaria, terminar el método. Elimine el siguiente método, escriba una prueba unitaria, termine el método.

El principio de conducción es ágil: cree algo que funcione. Los detalles están en todo el mapa: arriba, abajo, adelante, atrás, datos, proceso, actor, área temática, valor comercial.

Answer 4

Sí Haz todas esas cosas.

Puede parecer sarcástico (lo siento, vuelvo a la forma), pero este es realmente un caso en el que no hay una respuesta correcta.

Answer 5

¡También de forma ágil, escriba primero su (s) prueba (s)!

Entonces todo el software es un ciclo continuo de

• Rojo: el código no pasa la prueba
• Verde: el código pasa la prueba
• Refactor: mejoras de código que preservan la intención.

defectos, nuevas características, cambios. Todo sigue el mismo patrón.

Answer 6

Su segunda opción es un camino razonable. Si divide el problema en fragmentos entendibles, el enfoque de arriba hacia abajo revelará los principales defectos de diseño antes de implementar todos los pequeños detalles. Puede escribir talones para la funcionalidad de nivel inferior para mantener todo colgado.

Answer 7

Creo que hay más que considerar que el diseño de arriba hacia abajo de abajo hacia arriba. Obviamente, debe dividir el diseño en unidades de trabajo manejables, pero también debe considerar la priorización, etc. Y en un proyecto de desarrollo iterativo, a menudo redefinirá el problema para la próxima iteración una vez que haya entregado la solución para la anterior. .

Answer 8

Cuando diseño, me gusta hacer medio. Me gusta modelar el dominio, luego diseñar las clases, pasar a la base de datos y la interfaz de usuario desde allí. Si hay características específicas que están basadas en la interfaz de usuario o en la base de datos, también puedo diseñarlas por adelantado.

Al codificar, generalmente me gusta hacer de abajo hacia arriba (primero la base de datos, luego las entidades comerciales, luego la interfaz de usuario) si es posible. Creo que es mucho más fácil mantener las cosas claras con este método.

Answer 9

Creo que con buenos diseñadores de software (y en mi opinión, todos los desarrolladores de software también deberían ser diseñadores de software en algún nivel), la magia está en poder hacer de arriba hacia abajo y de abajo hacia arriba simultáneamente.

Lo que fui "educado" lo que deben hacer mis mentores es comenzar de arriba abajo muy breve para comprender las entidades involucradas, luego pasar de abajo hacia arriba para descubrir los elementos básicos que quiero crear, luego retroceder y ver cómo puedo ir un nivel hacia abajo, sabiendo lo que sé sobre los resultados de mi abajo hacia arriba, y así sucesivamente hasta que "se encuentren en el medio".

Espero que ayude.

Answer 10

Diseño de afuera hacia adentro.

Empiezas con lo que estás tratando de lograr en el extremo superior y sabes con qué tienes que trabajar en el extremo inferior. Sigue trabajando ambos extremos hasta que se encuentren en el medio.

Answer 11

Estoy de acuerdo con todas las personas que dicen "ninguno", pero todos caen en algún lugar del espectro.

Soy más del tipo de arriba hacia abajo. Elijo una característica / punto / nivel de alto nivel y lo implemento como un programa completo. Esto me permite esbozar un plan básico y una estructura dentro de los límites del dominio del problema.

Luego empiezo con otra función y refactorizo ??todo, desde el original que puede ser usado por el segundo en entidades nuevas y compartidas. Enjabonar, enjuagar, repetir hasta completar la aplicación.

Sin embargo, conozco a muchas personas que son personas de abajo hacia arriba, que escuchan un problema y comienzan a pensar en todos los subsistemas de soporte que podrían necesitar para construir la aplicación sobre él.

No creo que ningún enfoque sea incorrecto o correcto. Ambos pueden lograr resultados. Incluso trato de encontrar personas de abajo hacia arriba para trabajar, ya que podemos atacar el problema desde dos perspectivas diferentes.

Answer 12

Ambos son enfoques válidos. A veces uno simplemente "siente" más natural que el otro Sin embargo, hay un gran problema: algunos lenguajes convencionales y especialmente sus frameworks y bibliotecas realmente fuertemente en soporte IDE, como resaltado de sintaxis, verificación de tipo de fondo, compilación de fondo, finalización de código inteligente, IntelliSense, etc. .

Sin embargo, ¡esto no funciona con la codificación de arriba hacia abajo! En la codificación de arriba hacia abajo, usa constantemente variables, campos, constantes, funciones, procedimientos, métodos, clases, módulos, rasgos, mixins, aspectos, paquetes y tipos que aún no ha implementado! Por lo tanto, el IDE le gritará constantemente debido a errores de compilación, habrá líneas rojas onduladas en todas partes, no obtendrá la finalización del código y así. Entonces, el IDE prácticamente le prohíbe realizar codificaciones de arriba hacia abajo.

Answer 13

Hago una variante de arriba hacia abajo. Tiendo a intentar hacer la interfaz primero, luego la uso como mi lista de características. Lo bueno de esta versión es que todavía funciona con IDE que de otro modo se quejaría. Simplemente comente la llamada de una función a lo que aún no se ha implementado.