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 adecuadamente.
Esa no es una información nueva, incluso para un programador principiante. Sin embargo, me pregunto si este es un buen consejo porque desde que comencé a desarrollar en varios lenguajes de programación nunca logré diseñar y concebir todo desde el principio.
Quiero decir, siempre fundí diseño, concepción y programación. ¿Soy el peor desarrollador del mundo, o la idea que aprendemos en la escuela es solo un viejo dogma religioso sin sentido ?
¿Cómo podemos concebir y diseñar algo que nunca antes habíamos experimentado y programado? ¿No es eso ridículo? ¿La programación no lidera la concepción y el diseño?
Respuestas:
Creo que la respuesta tiene que ser: planifique tanto como pueda, pero no más que eso.
Pocas personas hablarían en contra de las virtudes de la planificación, pero el debate 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 tiende a venir con experiencia. Si no tiene mucha experiencia, cualquier plan que elabore probablemente tendrá una cantidad considerable 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, esto probablemente invalidará muchos de los detalles, o peor aún, tratará de mantener los ajustes al mínimo para poder seguir el plan.
Algunas cosas definitivamente requieren planificación, y si no tiene la habilidad para hacer el nivel de plan requerido, entonces la única forma de avanzar que puedo imaginar es la creación de prototipos, 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 código de producción, una vez que haya alcanzado su nivel máximo de planificación, no queda nada más que codificar. Tal vez sea un desastre, pero esas son buenas experiencias de aprendizaje, y estará mucho mejor equipado para hacer un plan revisado.
fuente
Es absolutamente cierto Cuanto mayor y más complejo es el requisito, más cierto es.
Para que una pequeña aplicación de consola calcule la secuencia de Fibonacci, es posible que no necesite más que unos minutos para pensar cómo estructurar el algoritmo y la interfaz de usuario (que, sí, podría ser simplemente stdin y stdout).
Pero, ¿qué tal una plataforma de negociación en tiempo real que se espera que haga millones de transacciones por segundo, distribuidas globalmente y que requiera 99.9999 de tiempo de actividad y 100% de corrección? ¿Podrías saltar a codificar eso?
Hay muchas otras opciones entre estos dos extremos.
Echa un vistazo al proyecto Euler . Resolver algunos problemas, en la secuencia presentada. Descubrirá que para resolver algunos de los problemas en un tiempo razonable, debe pensar antes de saltar al código.
Si no necesita tomarse el tiempo para pensar y diseñar su programa antes de comenzar a codificar, está trabajando en cosas triviales o le falta algo más grande.
Nadie hace nada más que el más trivial de los problemas. Una vez más, cuanto más grande y complejo sea el proyecto, más cierto será: los diseños tendrán errores, cosas que se pasarán 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 primero en la infraestructura / crucial más importante. Luego vamos y dividimos las piezas más grandes en piezas más pequeñas, asegurándonos de que cada pieza más grande esté compuesta de piezas que tengan sentido.
Esto lleva tiempo y esfuerzo, y puede no ser completo o completamente correcto al principio.
Pero es por eso que se llama software suave y no hardware duro . Es maleable y se puede cambiar.
fuente
Esto es verdad.
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 forma de que pueda planificar todo . Hay demasiadas cosas desconocidas para tener en cuenta, demasiados cambios que ocurrirán durante el desarrollo. Agile ha ganado la tracción que tiene porque acepta esta segunda mitad del trato: las personas no son omniscientes y el cambio es constante.
Por lo tanto, es cierto que debe diseñar con anticipación, pero también es cierto que es imposible diseñar solo con anticipación.
fuente
Absolutamente debe tener algún diseño antes de codificar.
La razón es bastante sencilla: si no tiene ningún diseño, no sabe lo que está haciendo .
Absolutamente debe tener algún código antes de que el diseño sea final.
La razón es bastante sencilla: 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, ya sea que el equipo se dé 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 se realiza el resto del trabajo.
Prueba 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 pequeña herramienta para su propio uso frente a un equipo que cree un producto grande de lanzamiento único como un videojuego importante).
fuente
He diseñado y observado que otros diseñen múltiples sistemas en el pasado y he visto que el proceso se desarrolla de muchas maneras diferentes, pero lo que encuentro común es que la arquitectura inicial debería al menos planificar la existencia de la mayoría de las características principales.
Por ejemplo, he visto un sistema de control de HVAC que no tenía el concepto de edificios, pisos, habitaciones, etc. que se adaptaron con esos y el resultado fue tan feo como parece. O un dispositivo de música móvil construido a partir de componentes más adecuados 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 más allá de "idea" y un concepto puede ser muy confuso. Las empresas generalmente se preocupan por los conceptos. Los clientes generalmente se preocupan por UX, un concepto hecho 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 abrir un estudio visual (o tu IDE de elección) y escribir código al azar, para ver a dónde va.
Es posible que no realice un diseño completo (y no debería hacerlo) antes de codificar, pero debe tener un bosquejo aproximado del flujo de trabajo del usuario.
El diseño y la codificación de UX a menudo se alimentan entre sí, es probable que se vea obligado a utilizar un enfoque ágil para cualquier cosa que no sea el más pequeño de los proyectos como una forma de incorporar este hecho en la forma en que aborda el trabajo. Así que no pienses que eres el peor de los programadores si no pudieras verlo todo de una vez: nadie puede y las personas que piensan que sí son las que simplemente ignoran el problema lo suficiente para que puedan afirmar que tienen un problema completo. imagen.
Un ejemplo para poner 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 genial y uno puede comenzar a escribir material de marketing y venderlo incluso antes de que esté allí. Tienes que tener esto antes de codificar.
Diseño previo: "Tener formas y flechas como en Visio para describir la lógica; tener capacidades de complemento para permitir conexiones a varias plataformas (SAP, SF, bases de datos ...); tener una consola de monitoreo donde uno puede buscar datos que pasan a través del sistema; tener una manera de describir datos visualmente y transformar un formato a otro ". Otro gran blob de marketing. También le da algunas ideas sobre lo que es importante, también debe tener un bosquejo aproximado antes de codificar.
Diseño / Código: "Tenga un diseñador HTML alojado en un navegador con tales características; codifique el backend en Java para que pueda ejecutarse en cualquier servidor existente; defina estructuras de datos y UX para consultarlas o modificarlas según sea necesario; planifique la recuperación ante desastres, error informes, registro de auditoría; control de versiones del plan; control de acceso del plan; .... "- cuanto más fina es la lista, más poco realista es prever todo.
... sin embargo, uno debe ser al menos consciente de cómo las cosas podrían terminar pareciendo más o menos, o su producto final podría terminar con algunas implementaciones realmente inútiles que terminan matando el concepto que suena de lo contrario, digamos que su diseñador visual requiere un 40 " pantalla para mostrar cualquier flujo de trabajo del mundo real, o no hay 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 de evitar que esto suceda que no sea ejecutar su implementación - Algunos tendrán éxito, otros fracasarán.
fuente
Siempre asigno tiempo de la siguiente manera:
Diseño: no solo visual, sino también conceptual. Dividirlo en partes, tanto visualmente como por lógica. Busque elementos comunes que se reutilicen y que sean un patrón de diseño en sí mismos.
Desarrollo: una vez que conozca sus piezas, codifíquelas. Entonces los integras.
Pruebas: no solo probar que el código se integró y escribió correctamente, invariablemente se detectarán ideas y se aprenderán lecciones, y creará nuevas formas de interactuar, se concebirán y desearán nuevas capacidades. Cuidado con el alcance de la fluencia.
Además de estos aspectos, tenga en cuenta que un proyecto también tiene 3 fases además de estas fases.
He descubierto que cuanto mejor hagas la fase de diseño, que minimiza los intentos adicionales. En lugar de volver a hacer todo, es posible que solo tenga un subsistema que se reelabore.
Soy desarrollador de software y gerente de desarrollo de software para proyectos de desarrollo internos, subcontratados y extraterritoriales.
fuente
Hay una suposición incorrecta fundamental aquí. Nunca podrás crear un buen diseño sin escribir primero el código (la escuela nunca te enseñará esto). Sin embargo, la escuela tiene razón en que no obtendrá un buen código sin el diseño.
La solucion es:
Desechar todo el código no es un paso opcional en este proceso, pero para proyectos pequeños, el diseño puede ser formal. Para proyectos grandes, es más probable que repita el paso " desechar todo el código ", aunque si tiene suficiente modularidad, esto solo puede aplicarse a parte de la base de código.
Demasiados proyectos conservan el código heredado porque no están dispuestos a cambiarlo, o porque es demasiado complicado, porque nunca fue diseñado para desecharse. Reconocer el hecho de que su primer intento será un fracaso hará que su vida sea mucho mejor.
fuente
la concepción es que el diseño clave siempre se puede cambiar, la programación tendrá que cumplir con los requisitos de la aplicación totalmente concebida.
Primero, cuál es el punto, segundo, cómo se necesita acceder, tercero quién es el usuario, cuarto, establecer un alcance SOW completo del trabajo, definir en términos específicos todo lo que esta aplicación debe hacer. y cómo funcionará cada función que agregue.
Antes de tomar cualquier decisión sobre la arquitectura de su aplicación web, planifíquela y piénselo completamente.
luego elige la mejor pila
Soy un desarrollador de LAMP
así que tiendo a limitar la pregunta a qué framework php usaré. y los scripts de front-end que tendré que hacer que haga todas las cosas que necesito que haga de una manera ideal
para agregar esto, aprenda a usar marcos MVC, ZEND y CAKEPHP son los mejores marcos de desarrollo rápido (PHP)
fuente