Concepción y diseño antes de la codificación: ¿cuánto es esto cierto? [cerrado]

14

Aprendí en la escuela y leí en todas partes que una buena metodología de desarrollo necesita concepción y diseño antes de codificar correctamente.

Esa no es una nueva información, incluso para un programador principiante. Sin embargo, me pregunto si es un buen consejo, ya que desde que empecé a desarrollar en varios lenguajes de programación, nunca logré diseñar y concebir todo desde el principio.

Quiero decir, siempre fundí el diseño, la concepción y la programación. ¿Soy el peor desarrollador del mundo o la idea que aprendemos en la escuela es solo un antiguo dogma religioso ?

¿Cómo podemos siquiera concebir y diseñar algo que nunca antes experimentamos y programamos? ¿No es eso ridículo? ¿La programación no conduce la concepción y el diseño en su lugar?

    
pregunta 22.05.2014 - 18:13

8 respuestas

5

Creo que la respuesta debe ser: Planifica todo lo que puedas, pero no más que eso.

Pocas personas hablarían en contra de las virtudes de la planificación, pero el debate en su mayoría pasa por alto un aspecto importante. La planificación solo funciona en la medida en que tenga la habilidad para hacer un buen plan, esa habilidad suele venir con experiencia. Si no tiene mucha experiencia, cualquier plan que elabore tendrá una buena cantidad de problemas, esto significa que para hacer un producto que no sea un desastre total, el plan tendrá que ser revisado en gran medida durante el desarrollo. Si se detalla el plan, es probable que esto invalide muchos de los detalles, o peor aún, intentará mantener los ajustes al mínimo para poder seguir el plan.

Algunas cosas definitivamente requieren planificación, y si no tienes la habilidad para hacer el nivel requerido de plan, entonces la única forma de avanzar que puedo imaginar es crear un prototipo, escribir código simplemente para obtener la experiencia con la tarea requerida para hacer Un plan adecuado.

Ya sea que esté o no listo para escribir el código de producción, una vez que haya alcanzado su nivel máximo de planificación, no queda nada por hacer excepto la codificación. Tal vez sea un desastre, pero esas son buenas experiencias de aprendizaje y estará mucho mejor equipado para hacer un plan revisado.

    
respondido por el aaaaaaaaaaaa 22.05.2014 - 23:17
29

Es absolutamente cierto. Cuanto mayor y más complejo sea el requisito, más cierto será este.

Para que una aplicación de consola pequeña calcule la secuencia de Fibonacci, es posible que no necesite más que unos minutos de reflexión sobre cómo estructurar el algoritmo y la interfaz de usuario (que, sí, podría ser simplemente estándar y estándar).

¿Pero qué hay de una plataforma de negociación en tiempo real que se espera que haga millones de transacciones por segundo, distribuidas globalmente y eso requiere 99.9999 de tiempo de actividad y el 100% de corrección? ¿Podrías saltar a codificar eso?

Hay muchas otras opciones entre estos dos extremos.

Echa un vistazo a project Euler . Resolver algunos problemas, en la secuencia presentada. Descubrirá que para resolver algunos de los problemas en un tiempo razonable, debe pensar antes de ingresar al código.

Si no necesita tomar tiempo para pensar y diseñar su programa antes de comenzar a codificar, está trabajando en cosas triviales o falta algo más grande.

  

Nunca logré diseñar y concebir todo desde el principio

Nadie hace nada más que por los problemas más triviales. Nuevamente, cuanto más grande y complejo sea el proyecto, más cierto será este: los diseños tendrán errores, cosas que se pasan por alto, etc. ...

El arte es diseñar primero en alto nivel, ver si las piezas grandes encajan. Luego, obtenga una lista de prioridades: comience a trabajar en la infraestructura / infraestructura más importante. Luego vamos y dividimos las piezas más grandes en otras más pequeñas, asegurándonos de que cada pieza más grande esté compuesta de piezas que tengan sentido.

Esto requiere tiempo y esfuerzo, y puede no estar completo o totalmente correcto al principio.

Pero es por esto que se llama soft -ware y no hard -ware. Es maleable y se puede cambiar.

    
respondido por el Oded 22.05.2014 - 18:18
9
  

Aprendí en la escuela y leí en todas partes que una buena metodología de desarrollo necesita concepción y diseño antes de codificar correctamente.

Esto es cierto.

  

Sin embargo, me pregunto si este es un buen consejo porque desde que empecé a desarrollar en varios lenguajes de programación, nunca logré diseñar y concebir everything desde el principio.

Y ahí está tu problema.

Para la mayoría de los problemas no triviales, tendrá que pensar un poco para descubrir cómo van a funcionar las cosas, cómo van a encajar las cosas. Paradójicamente, para la mayoría de los problemas no triviales, no hay manera de que puedas planificar todo . Hay demasiados aspectos desconocidos para que los tengas en cuenta, demasiados cambios que se producirán durante el desarrollo. Agile ha ganado la tracción que tiene porque acepta esta segunda mitad del trato: la gente no es omnisciente y el cambio es constante.

Por lo tanto, es cierto que debes hacer el diseño con anticipación, pero también es cierto que es imposible solo diseñar con anticipación.

    
respondido por el Telastyn 22.05.2014 - 18:25
4

Es absolutamente necesario tener algún diseño antes de codificar.

El motivo es bastante sencillo: si no tiene ningún diseño, no sabe lo que está haciendo .

Es absolutamente necesario tener algún código antes de que el diseño sea definitivo.

El motivo es bastante sencillo: el diseño cambiará y el desarrollo de partes del diseño revelará preguntas, oportunidades y desafíos que son difíciles de anticipar sin comenzar a trabajar en la solución.

El desarrollo es iterativo.

Ya sea por plan o no, si el equipo se da cuenta o no, cada proyecto de software se realiza de forma iterativa: parte del trabajo se completa y luego se evalúa, y la evaluación conduce a cambios en la forma en que el resto del trabajo se realiza. hecho.

Pruebe más de un enfoque.

Se necesita práctica y experiencia para conocer la mejor manera de equilibrar el diseño inicial con la creación de código. Es una habilidad que casi nadie ha dominado y cada proyecto tendrá diferentes ideales (considere diseñar una herramienta pequeña para su propio uso en lugar de un equipo que cree un producto grande de una sola versión, como un videojuego importante).

    
respondido por el asfallows 22.05.2014 - 22:53
1

He diseñado y observado que otros diseñaron sistemas múltiples en el pasado y he visto que el proceso se desarrolla de muchas maneras diferentes, pero lo que encuentro en común es que la arquitectura inicial debe al menos planificar la existencia de de la mayoría de las características principales.

Por ejemplo, he visto un sistema de control de HVAC que no tenía ningún concepto de edificios, pisos, habitaciones, etc. que se haya actualizado con esos y el resultado fue tan feo como parece. O un dispositivo de música móvil creado a partir de componentes mejor adaptados para su reloj de bolsillo (no inteligente). No hace falta decir que los productos finales en ambos casos no eran los favoritos de los clientes.

Cuando dices "concepción", eso es solo un paso adelante de "idea" y un concepto puede ser muy difuso. Los negocios generalmente se preocupan por los conceptos. Por lo general, los clientes se preocupan por el UX, un concepto que se hace realidad de una manera fácil y agradable de usar y que aporta algo de valor a través de su uso.

Tienes que hacer un "concepto" antes de cualquier programación, no puedo imaginarme abriendo Visual Studio (o tu IDE de tu elección) y escribiendo código al azar, para ver a dónde va.

Puede que no haga un diseño completo (y no debería) antes de codificar, pero debería tener un bosquejo aproximado de lo que sería el flujo de trabajo del usuario.

El diseño y la codificación de UX a menudo se complementan entre sí, es probable que se vea obligado a utilizar un enfoque ágil para cualquier proyecto que no sea el más pequeño, como una forma de incorporar este hecho en la forma en que aborda el trabajo. Así que no creas que eres el peor de los programadores si no pudieras verlo todo al mismo tiempo, nadie puede y las personas que piensan que pueden son las que ignoran lo suficiente del problema para poder afirmar que tienen una completa foto.

Un ejemplo para ponerle un tamaño a algo grande. Concepto: "Crear una herramienta visual basada en la nube que permita a las empresas integrar sus plataformas de software". Esto suena bien y uno puede comenzar a escribir material de marketing y venderlo antes de que esté ahí. Tienes que tener esto antes de codificar.

Pre-diseño: "Tenga formas y flechas como en Visio para describir la lógica; tenga capacidades de complemento para permitir conexiones a varias plataformas (SAP, SF, bases de datos ...); tenga una consola de monitoreo donde se puedan buscar datos pasando por el sistema; tenga una forma de describir los datos visualmente y transformar un formato a otro ". Otra gran burbuja de marketing. También le da algunas ideas sobre lo que es importante, debe tener un bosquejo tan aproximado antes de codificar también.

Diseño / Código: "Tener un diseñador de HTML alojado en el navegador con tales y tales características; codificar el backend en Java para que pueda ejecutarse en cualquier servidor existente; definir estructuras de datos y UX para consultarlos o modificarlos según sea necesario; planificar un desastre recuperación, informe de errores, registro de auditoría; control de versión del plan; control de acceso al plan; ... ": cuanto más precisa sea la lista, más irreal es prever todo.

... sin embargo, al menos uno debe ser consciente de qué cosas podrían terminar pareciendo más o su producto final puede terminar con algunas implementaciones realmente inútiles que terminan matando el sonido que de otra manera sería genial. concepto: digamos que su diseñador visual requiere una pantalla de 40 "para mostrar cualquier flujo de trabajo del mundo real, o no hay otra forma de buscar en los registros que no sea una coincidencia de cadena exacta limitada a uno de los 20 campos en el registro, etc. No hay una buena manera para evitar que esto suceda, aparte de ejecutar su implementación, algunos tendrán éxito y otros fallarán.

    
respondido por el Sten Petrov 22.05.2014 - 22:01
0

Siempre asigno tiempo de la siguiente manera:

  1. 1/3 Diseño
  2. 1/3 Desarrollo
  3. 1/3 Pruebas

Diseño: No solo visual, sino también conceptual. Divídelo en partes, tanto visualmente como por lógica. Busque elementos comunes que sean reutilizables y que sean un patrón de diseño en sí mismos.

Desarrollo: Una vez que conozca sus partes, codifíquelas. Luego los integras.

Pruebas: no solo se comprueba que el código se integró y se escribió correctamente, invariablemente, se verán puntos de vista y se aprenderán lecciones, y se crearán nuevas formas de interactuar, se concebirán y se desearán nuevas capacidades. Tenga cuidado con el alcance del error.

Además de estos aspectos, tenga en cuenta que un proyecto también tiene 3 fases además de estas fases.

  1. El primer intento de ingeniería insuficiente
  2. El segundo intento de ingeniería excesiva, de las lecciones aprendidas del primer intento.
  3. El tercer intento correctamente diseñado.

Descubrí que cuanto mejor haces en la fase de diseño, minimiza los intentos adicionales. En lugar de volver a hacer todo el proceso, es posible que solo tenga un subsistema que se vuelva a trabajar.

Soy un desarrollador de software y gerente de desarrollo de software para proyectos de desarrollo interno, externo y de alta mar.

    
respondido por el user9170 22.05.2014 - 22:00
-1

Hay una suposición incorrecta fundamental aquí. Nunca podrá hacer un buen diseño sin escribir primero el código (la escuela nunca le enseñará esto). Sin embargo, la escuela tiene razón en que no obtendrás un buen código sin diseño.

La solución es:

  1. Escriba algún código que crea que podría resolver el problema.
  2. Cree un diseño basado en lo que aprendió del código.
  3. Deseche todos el código y vuelva a escribirlo desde cero de acuerdo con el diseño.
  4. Repita según sea necesario.

Desechar todo el código no es no un paso opcional en este proceso, pero para proyectos pequeños, formalmente, escribir el diseño puede ser. Para proyectos grandes, es más probable que repita el paso " deshacerse de todo el código ", aunque si tiene suficiente modularidad, esto solo puede aplicarse a parte del código base.

Hay demasiados proyectos en el código heredado porque no están dispuestos a cambiarlo, o porque es demasiado complicado, porque nunca fue diseñado para ser desechado. Reconocer el hecho de que su primer intento será un fracaso hará que su vida sea mucho mejor.

    
respondido por el o11c 23.05.2014 - 05:28
-3

la concepción es la clave el diseño siempre puede ser cambiado La programación tendrá que cumplir los requisitos de la aplicación totalmente concebida.

Primero cuál es el punto, segundo, cómo se debe acceder, tercero quién es el usuario, cuarto, establezca un alcance completo de la SOW para definir el trabajo en términos específicos que toda esta aplicación debe hacer. y cómo funcionará cada función que agregue.

antes de realizar cualquier elección en cuanto a la arquitectura de su aplicación web, planifique y analice completamente.

luego elige la mejor pila

Soy un desarrollador de LAMP

así que tiendo a restringir la pregunta a qué marco de php usaré. y los scripts front-end que necesitaré para hacer que haga todas las cosas que necesito hacer de una manera ideal

para agregar esto, aprenda a usar los marcos MVC, ZEND y CAKEPHP son los mejores marcos de desarrollo rápido (PHP)

    
respondido por el kevin 22.05.2014 - 19:07

Lea otras preguntas en las etiquetas