Al codificar, ¿cuál es, en su experiencia, un mejor enfoque?Diseño y codificación: de arriba a abajo o de abajo hacia arriba?
Aquí es lo que hago:
Comprender el dominio primero. Comprenda 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 va a resolver.
Luego se propone una solución de alto nivel para el 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 los componentes que se pueden diseñar.
En ese momento, escribo pruebas para las clases aún por escribir y luego realizo las clases para pasar esas pruebas.
Utilizo un enfoque de prueba y desarrollo de componentes probados y en funcionamiento. Eso es lo que funciona para mí. Cuando se conocen las interfaces de los componentes y se conocen las "reglas" sobre cómo se comunican entre sí y se prestan servicios entre sí, entonces se convierte generalmente en un ejercicio sencillo de "conectar todo junto".
Así es como lo hago, y me ha funcionado bien.
Sí. Haz todas esas cosas.
Puede parecer sarcástico (lo siento, vuelvo a la forma), pero este es realmente un caso donde no hay una respuesta correcta.
Su segunda opción es una forma razonable de hacerlo. Si divide el problema en pedazos comprensibles, el enfoque descendente revelará los principales defectos de diseño antes de implementar todos los pequeños detalles. Puede escribir resguardos para la funcionalidad de nivel inferior para mantener todo junto.
Es posible que desee consultar el Agile Manifesto. Arriba hacia abajo y hacia abajo se basan en el diseño y la construcción Built It All All Once.
El "Software de trabajo sobre documentación completa" significa que lo primero que construye es lo más pequeño que puede ejecutar. ¿Parte superior? ¿Fondo? Ninguno.
Cuando era más joven, trabajé en proyectos que eran, por contrato, estrictamente de arriba hacia abajo. Esto no funciona De hecho, no puede funcionar. Obtiene montañas de diseño redundante y código como resultado. No fue un enfoque sensato cuando se aplicó sin pensar.
Lo que he notado es que el enfoque Agile (piezas pequeñas que funcionan) tiende a dividir el problema en partes que se pueden captar de una vez. El top-down/bottom-up ya no importa tanto. De hecho, puede no importar en absoluto.
Lo que lleva a hacer: "¿Cómo se descompone para el desarrollo Ágil?" El truco es evitar la creación de A Big Thing que luego debe descomponer. Si analizas un problema, encuentras 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 son, debe resolver el problema en la dirección Metas al revés. Desde Metas a cosas que le permiten hacer ese objetivo a cosas que habilitan los habilitadores, etc. Dado que los objetivos son a menudo Grandes Cosas, esto tiende a ser de Arriba hacia Arriba, desde el objetivo comercial general hasta el proceso y el paso de negocio detallados.
En algún momento, presentamos estos diversos pasos que conducen a los objetivos. Hemos hecho la parte de análisis (rompiendo las cosas). Ahora viene la parte de síntesis: reensamblamos lo que tenemos en cosas que realmente podemos construir. 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 los detalles en un modelo conceptual más amplio. Luego, a veces se descompone de nuevo en un modelo normalizado para OLTP. O descompuesto en un esquema en estrella normalizado para OLAP. Luego trabajamos nuevamente para crear un mapeo ORM a partir del modelo normalizado. Arriba - Abajo - Arriba.
Tenemos procesamiento.A menudo, esto se genera a partir de resúmenes de los procesos comerciales hasta los detalles de los pasos de procesamiento. Entonces el software está diseñado alrededor de los pasos. Entonces el software se divide en clases y métodos. Abajo - Arriba - Abajo.
[Digression. Con los usuarios informados, esta descomposición define nuevos títulos de trabajo y formas de trabajar. Con los usuarios poco informados, los trabajos anteriores se quedan y escribimos montañas de documentación para asignar trabajos antiguos a un nuevo software.]
Tenemos componentes. A menudo miramos las piezas, miramos 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 la totalidad de nuestra solución. A menudo se siente de abajo hacia arriba (de función a producto), pero a veces de arriba hacia abajo ("Estoy sosteniendo un martillo, llamo a todo un clavo" == use el RDBMS para todo).
Eventualmente tenemos que codificar. Esto es de abajo hacia arriba. Mas o menos. Tienes que definir una estructura de paquete. Debes definir las clases como un todo. Esa parte fue de arriba hacia abajo. Tienes que escribir métodos dentro de las clases. A menudo hago esto de abajo hacia arriba: redondeo el método, escribo una prueba unitaria, termino el método. Desarrolle el siguiente método, escriba una prueba unitaria, termine el método.
El principio de manejo es Agile: construya algo que funcione. Los detalles están en todo el mapa: arriba, abajo, frente, atrás, datos, proceso, actor, área temática, valor comercial.
Interpreté la pregunta como "el problema en cuestión" en lugar de "todo el software". Incluso cuando construyes la cosa útil más pequeña, tienes que abordar el problema desde cierta perspectiva. – KevDog
Lo siento, no puedo ver eso en la pregunta. Además, y más importante, el top-down/bottom-up a menudo se debe a la administración de proyectos de Big Design Up Front. Las personas ágiles rara vez parecen hacer esta pregunta. –
Creo que hay más que considerar que el diseño top-down de abajo hacia abajo. 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. .
Diseño externo.
Empiezas con lo que estás tratando de lograr en el extremo superior, y sabes con qué tienes que trabajar en la parte inferior. Sigue trabajando en ambos extremos hasta que se encuentren en el medio.
Al diseñar, me gusta hacer la mitad. Me gusta modelar el dominio, luego diseñar las clases, moverme a la base de datos y la IU desde allí.Si hay funciones específicas 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 (base de datos primero, luego entidades comerciales, luego UI) si es posible. Encuentro que es mucho más fácil mantener las cosas claras con este método.
¡También de forma ágil, escriba su prueba primero!
Entonces todo el software es un ciclo continuo de
defectos, nuevas funciones, cambios. Todo sigue el mismo patrón.
No creo que esto realmente responda la pregunta, que es de arriba hacia abajo vs diseño de abajo hacia arriba. –
Supongo que podría aclarar que esto caería bajo (3) Otro; analiza cosas, escribe pruebas, luego escribe el código. El hecho de escribir las pruebas es, a su manera, un enfoque externo. –
Estoy de acuerdo con toda la gente que dice "ninguno", pero todos caen en algún lugar del espectro.
Soy más un chico de arriba hacia abajo. Escojo una característica/punto/lo que sea de alto nivel y la 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 característica y refactorizo todo desde el original que puede ser utilizado por el segundo en nuevas entidades compartidas. Enjabona, enjuaga, repite hasta que la aplicación esté completa.
Sin embargo, conozco a mucha gente que son 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.
No creo que ninguno de los enfoques sea incorrecto o correcto. Ambos pueden lograr resultados. Incluso trato de encontrar hombres de abajo para trabajar, ya que podemos atacar el problema desde dos perspectivas diferentes.
Tiendo a diseñar de arriba hacia abajo e implementar de abajo hacia arriba.
Para la implementación, la construcción de las piezas funcionales más pequeñas y su ensamblaje en las estructuras de nivel superior parece ser lo que funciona mejor para mí. Pero, para el diseño, necesito partir de la imagen general y descomponerla para determinar cuáles serán esas piezas.
Ambos son enfoques válidos. A veces uno simplemente "se siente" más natural que el otro. Sin embargo, hay un gran problema: algunos lenguajes mainstream y especialmente sus frameworks y bibliotecas realmente en gran medida en soporte IDE, tales como resaltado de sintaxis, verificación de tipo de fondo, compilación de fondo, terminación de código inteligente, IntelliSense y así sucesivamente.
Sin embargo, ¡esto no funciona con la codificación de arriba hacia abajo! En la codificación de arriba hacia abajo, constantemente utiliza variables, campos, constantes, funciones, procedimientos, métodos, clases, módulos, características, 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á el código completo y así sucesivamente. Por lo tanto, el IDE prácticamente prohíbe que haga una codificación de arriba hacia abajo.
Tipo de verdad, pero si su programación contra interfaces y stubbing/burlas de sus dependencias para fines de prueba o hasta que se construyan, entonces esto no es un problema. – Owen
Hago una variante de arriba hacia abajo.Tiendo a intentar hacer primero la interfaz, luego la uso como mi lista de funciones. Lo bueno de esta versión es que todavía funciona con IDE que de otra forma se quejaría. Simplemente comente la llamada de una función a lo que aún no se ha implementado.
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 mis mentores me "enseñaron" a hacer es comenzar muy brevemente de arriba hacia abajo para comprender las entidades involucradas, luego pasar de abajo hacia arriba para descubrir los elementos básicos que quiero crear y luego hacer una copia de seguridad y vea cómo puedo bajar un nivel, sabiendo lo que sé sobre los resultados de mis resultados, y así sucesivamente hasta que "se encuentren en el medio".
Espero que ayude.
Hemos tenido mucho éxito usando este método general. Esto funciona especialmente bien en equipos con diseñadores y dba's. El dba comenzará naturalmente en la parte inferior, los diseñadores comenzarán naturalmente en la parte superior, y los codificadores pueden oscilar hacia adelante y hacia atrás según sea necesario. –
Personalmente, considero que esta es la forma más fácil de trabajar, con menos repeticiones. Otros han mencionado el TDD, pero me parece que me enfoca demasiado en la búsqueda de abajo hacia arriba y termino casi adivinando qué necesitarán las clases de clientes de alto nivel ... y hacerlo mal. Solo soy yo, aunque haga lo que sea que funcione para usted. –