¿Debo planear con anticipación o averiguar los programas a medida que los estoy escribiendo? [duplicar]

Este es un ejemplo perfecto de la falacia media excluida. Sí, escribir el programa completo en papel antes de tocar el teclado es una mala idea. Pero eso no hace que el extremo opuesto (saltar inmediatamente a la codificación y comenzar a piratear) sea una buena idea. De hecho, es aún peor.

Es muy importante entender lo que estás tratando de escribir antes de comenzar a escribirlo. Cuando tengo una nueva característica para implementar en el trabajo, me aseguro de tener una especificación que describa lo que se necesita hacer antes de comenzar. Lo miro, y si hay algo allí que no tiene sentido, hablo con la gente que escribió la especificación y trabajo sobre el tema hasta que estemos de acuerdo. A veces no entendía los requisitos y ellos me pueden aclarar; otras veces, la gente de PM no entendió los detalles técnicos y terminaron modificando la especificación.

Casi cualquier persona que haya hecho esto puede decirle por experiencia personal que es mucho más fácil solucionar los problemas en la especificación que encontrar un problema en su código a mitad de la implementación, eliminarlo todo y reemplazarlo con algo mas Por lo tanto, tener un plan para lo que escribe antes de comenzar a escribir el código es muy, muy importante.

¿Crees que Miguel Ángel acaba de subir a la cima de la Capilla Sixtina y acaba de empezar a dibujar? Se hicieron dibujos de prueba. Se necesitaron aprobaciones del Papa. Había que construir andamios. Plantillas hechas para guiar al grupo de otros artistas. La restauración fue aún más compleja.

Si quiero crear una aplicación y no tengo que considerar las preferencias de diseño en la cabeza de otra persona, puedo comenzar a codificar. Si vas por el camino equivocado, simplemente cambia de opinión. No quería esa característica de todos modos.

Deje que el pintor o escritor se siente en un comité. "Oh, ve y haz que el personaje principal sea una mujer. Si cambiamos de opinión más adelante, te lo haremos saber. Y WTF, hagámoslo con 20 'de largo en lugar de 30. ¿Puedes agregar un galeón español con 50? ¿Remeros únicos antes del estreno mañana?

Creo que todo se trata de formar un equilibrio. Es imposible pensar en todo antes de que lo escribas, por eso precisamente el modelo de Waterfall está tan roto. Al mismo tiempo, si piensa demasiado, puede causar un gran lío cuando pase las primeras iteraciones. Después de todo, no puede convertir todo el código en forma, y sería muy desafortunado si hubiera pasado por alto un requisito básico desde el principio que requería una reescritura a mitad del proyecto.

Se requiere un cierto número de iteraciones en el proceso de desarrollo, que es lo que Waterfall pasa por alto (asume una iteración perfecta). Agile (o el amplio grupo de metodologías "similares a Agile") a veces pasa por alto que cada iteración tiene una cierta cantidad de sobrecarga, y si no se gana mucho a través de cada iteración, el número de iteraciones totales aumentará y esa sobrecarga se sumará a un costo significativo.

La premisa de la analogía es errónea: muchos escritores describen o al menos piensan lo que van a escribir antes de comenzar a escribir, y muchos pintores y arquitectos harán docenas de estudios y bocetos antes de comenzar su trabajo real. ".

Dado que la analogía es incorrecta, la respuesta es sí: los programadores deberían trabajar como escritores, pintores y arquitectos.

Tenía un compañero de cuarto en la universidad que estudiaba arte y diseño web. Él y yo comparamos muchas notas sobre nuestros flujos de trabajo. Cuando pinta, no se da cuenta de la pintura como la pinta. Había varias cosas que podía hacer de antemano. Para un tipo de pintura de collage podría dibujar un boceto. En una pintura fotorrealista dibujaba las principales formas con un lápiz y luego pintaba los detalles. Pero si sabía exactamente lo que quería de antemano, no necesitaba estas ayudas. Acaba de pintar.

Estoy seguro de que ves las similitudes. Utilizamos diferentes métodos para ayudar a encontrar una buena solución a un problema. Si no conocemos bien la tecnología, hackeamos un poco para descubrir cómo será la solución final. Los productos más grandes a menudo se benefician de una sesión de diseño de gran tamaño, y los detalles se completan más adelante. Y a veces sabemos exactamente lo que se requiere, así que simplemente lo codificamos. No porque seamos perezosos, sino porque a través de la experiencia y el pensamiento no necesitamos las herramientas adicionales.

Algunas ventajas de diseñar por adelantado:

• Ves todo el panorama general.
• Puedes iterar a través de varios diseños sin comprometer a ninguno. Si ya tiene un código escrito, no puede cambiar de dirección a gran escala.

Ventajas de saltar en el código:

• En un nivel micro, tienes la posibilidad de probar muchas cosas rápidamente antes de elegir One True Parser
• Puede ayudar a romper un bloque de diseño. Si no puede decidir sobre un modelo de objeto en particular, digamos, puede generar un poco de código y ver cómo encaja.

La respuesta a esta pregunta es como la respuesta a muchos en la programación: Depende. Depende del proyecto: ¿necesita un registro de auditoría de diseño, el proceso lo ayuda a usted y a los demás desarrolladores a comprender las decisiones que necesita, lo ayudan activamente o lo retienen de Getting Stuff Done? ¿Es crítico que el proyecto sea absolutamente correcto, o se pueden descubrir y reparar algunas fallas más adelante? ¿Cómo es tu marco de tiempo? ¿Qué experiencia puedes aportar al problema? Y finalmente, ¿entiendes completamente qué problema tienes que resolver?

Lo que me funciona en este momento es hacer un diseño de gran imagen por adelantado en papel. Esto describirá las partes principales de la aplicación y cómo se comunicarán. Por lo general, dibujo un diagrama de objetos y algunos diagramas de flujo / psuedocode / código real para las secciones más complicadas. Luego me meto de lleno, una sección a la vez. Si una falla en el modelo está causando un problema, siempre puedo volver a las especificaciones de diseño y revisarlas para esa área. Y cambiar un buen diseño inicial por lo general no significa que más de un poco tendrá que cambiar.

Me enseñaron a programar de la misma manera que construyes un ferrocarril modelo.

Cuando construyes un modelo de ferrocarril, colocas un trozo de vía y pones un motor en la vía. Si se mueve, coloca el siguiente fragmento de pista y ve si el motor se mueve hacia esa pista. Continúa hasta que hayas completado el bucle, y el motor también ha completado el bucle.

La ventaja de este método de construcción de un ferrocarril modelo es que si el motor se detiene, está bastante seguro de cuál es el problema. El que acabas de colocar.

La programación es similar. Necesitas hacer el análisis y el diseño, pero en algún momento, debes comenzar a establecer la pista. Su primera iteración puede ser nada más que módulos ficticios. Eso está bien, siempre y cuando tu proyecto se ejecute sin enmendar.

Usted agrega un método a la vez (idealmente), o la cantidad mínima de métodos para obtener algo para ejecutar. Cada vez, ve si el motor se mueve (el proyecto se ejecuta sin anular).

Es posible que descubras que mientras estás rastreando, necesitas un revestimiento adicional (algunos métodos adicionales). Eso está bien, siempre y cuando no estés cambiando radicalmente el diseño. Si está cambiando radicalmente el diseño, entonces detenga la codificación. Pase algún tiempo pensando en el diseño y realice los cambios de diseño antes de reanudar la codificación.

Cuando haya colocado las últimas piezas de la pista (haya terminado los últimos métodos), su proyecto debería ejecutarse sin interrumpirse. Porque has estado probando todo el tiempo. Al igual que los constructores de ferrocarriles modelo.

La relación entre pensamiento y acción depende de una serie de variables, que van desde la complejidad del problema hasta el dominio y los objetivos finales. No existe un único enfoque de talla única para calcular la cantidad de pensamiento y planificación que necesita por adelantado en comparación con cuando puede simplemente "piratear" un programa.

Si tiene un problema complejo o está trabajando en algo que es crítico para la vida o la misión, debe dedicar tiempo a entenderlo y pensar en soluciones y compensaciones por adelantado. Si desea aprender rápidamente una tecnología, una biblioteca o un marco, tal vez salte y cometa sus errores en un prototipo desechable. Otras opciones incluyen la creación de prototipos evolutivos: pensamiento y diseño suficientes para asegurarte de que puedas evolucionar tu trabajo hacia un producto terminado, pero no tanto como para que te limiten en una sola ruta.

Como señaló @Thomas, no existe una solución única para todos. En esta era de abundante capacidad de cómputo y memoria, la mayoría de los problemas con los que nos enfrentamos no son difíciles, por lo que casi cualquier enfoque servirá para obtener una solución correcta. Sin embargo, todavía hay áreas en las que puedes fallar miserablemente si intentas encontrar una solución sobre la marcha, escribiendo el código de inmediato.

Por ejemplo, una aplicación en la que trabajé estaba analizando redes móviles. Si necesita escribir código para analizar una red de un par de miles de nodos en una docena de capas de red diferentes, que se supone que no se ejecutan en supercomputadoras sino en simples computadoras portátiles de doble núcleo, es mejor que encuentre los mejores algoritmos de gráficos conocidos por la humanidad antes. Empezando a escribir cualquier código. La alternativa podría ser darse cuenta, después de medio año de impacientes desarrollos, de que su algoritmo, aunque proporciona resultados correctos para su red de prueba de 10 nodos, es O (n ⁴ ), por lo que termina después de dos años en la cuenta del usuario. Cuando se alimenta con el plan de red de la vida real en el que está trabajando ahora mismo ...

  

¿Por qué no hay más personas que pirateen y armen un programa sin tener una idea preconcebida de cómo se verá?

Muchas personas hacen precisamente eso, a lo largo de sus carreras. Este sitio está lleno de sus preguntas. Los otros sitios afiliados están llenos de preguntas de otras personas que intentan usar el software que escribieron.

El tipo de personas que simplemente expulsan el código, como usted lo dice, a menudo dicen algo como "El código es su propia documentación". El código es no documentación. El código no es una demostración de tu intención, es una versión de lo que recuerdas como la intención, más un montón de cosas que te interesaron en el camino, algunas de las cuales resultaron no ser útiles pero no tuviste tiempo para hacerlo. retirar. Ah, y esa increíble idea que tenías después de dos noches sin dormir pero con mucha cafeína, que iba a revolucionar todo el proyecto, solo sé que ni siquiera sabes cómo se compila, y mucho menos qué se supone que debe hacer, o precisamente qué efecto tendrá si lo eliminas.

Sin algún tipo de documento de diseño, aunque sea mínimo, ¿cómo dicen sus colaboradores (o sucesores) qué bits extender y cuáles soltar? Ese documento no tiene que estar escrito al principio, pero para un proyecto de cualquier tamaño y valor debe suceder en algún momento.

Spew-and-refactor funciona para proyectos en solitario, hasta cierto punto (y vale la pena conocer a las personas que son buenos jueces de dónde se encuentra ese punto). Es menos práctico para los equipos; ¿Cómo trabajan las personas de manera eficiente en paralelo sin un consenso mínimo sobre la especificación? La metodología ágil es en gran medida un intento de resolver ese problema sin matar el entusiasmo nativo de las personas por la codificación.

En general, la programación es un ejercicio de abstracción. Por lo tanto, cualquier intento de actualizar en exceso cualquier solución particular sin duda lo llevará a juzgar mal el alcance de su esfuerzo.

Simplemente no eres tan bueno juzgando la complejidad. Confía en mí, simplemente no lo eres.

El mejor código comienza con un resumen de lo que quiere lograr y se desarrolla de forma iterativa en partes. Con el código sucesivo construyendo sobre sí mismo. En las etapas de planificación de un proyecto es mucho más útil sentarse y hacer una lista de lo que su programa NO va a hacer. De esa manera, al menos no sucumbirás a tratar de hervir el maldito océano.

enlace

Sé que esto ha sido respondido, pero no estoy convencido de que Graham haya hecho caso omiso de cualquier resumen de alto nivel o diseño por adelantado. Pienso en el problema de antemano, tengo especificaciones, etc., pero todavía entiendo completamente lo que dice mientras trabajo de la misma manera.

Para mí, la "piratería" no es lo que vas a hacer, sino cómo lo vas a hacer. En la escuela me enseñaron pseudocódigo y diseñé el código real desde el principio. Para mí, eso es una tontería. Tomaré una descripción general de alto nivel, una brújula y me alejaré de allí. No voy a tratar de pensar en todo el código porque no soy un compilador o una computadora y no puedo comprender las consecuencias de todo mi código en papel por adelantado. Cortaré una implementación ineficiente o dañada de las especificaciones o el diseño y luego lo "pondré en forma" desde allí.

Bueno, ¿quién soy yo para disputar lo que dice pg, pero ... creo que el mejor enfoque probablemente varía según el individuo, y eso, en la medida en que podría haber una verdad objetiva hasta este punto, la verdad probablemente reside en el medio en alguna parte Por lo menos, creo que hacer una dicotomía entre "no planear con anticipación" y "resolver todo por adelantado" es una falsa dicotomía. Es un continuo, en mi experiencia.

Personalmente me inclino más hacia el estilo de programación exploratorio, y "lo resuelvo a medida que avanzo", pero al mismo tiempo, dos de mis herramientas de programación favoritas son un bloc de dibujo para artistas y un conjunto de lápices de colores. Definitivamente, hay un momento y un lugar para sentarse y esbozar relaciones de alto nivel y visualizar las cosas para ayudarte a entender cómo encajarán las cosas. Bueno, hay para mí.

Una vez más, creo que esto depende mucho del individuo ... y también del dominio del problema y la complejidad inherente del programa. Es decir, un programa simple de calculadora de línea de comando (piense, "poor hombre aC") probablemente requeriría menos planificación inicial que un sistema ERP para una compañía de 30,000 empleados.

Creo que el flujo de trabajo es muy individual para cada programador. Utiliza el método que mejor te funcione.

Yo, personalmente, generalmente comienzo con un papel en blanco y un lápiz (o una pizarra muy grande si tengo uno). Primero estoy dibujando diagramas de clase y relaciones. Luego lo refino hasta que tenga una estructura básica. También hago las máquinas de estado en esta etapa. En este punto no se ha escrito ni pensado ningún código, solo clases y relaciones.

Ahora esto es solo un boceto perdido y, mientras comienzo a programar mis clases, tendré más preguntas de diseño. Luego vuelvo a mi pizarra (o papel) y analizo los nuevos problemas, lo que a veces significa que rompe parte del diseño original.

Esto también es similar a cómo funciona Diseño ágil (note SIMILAR para todos ustedes que se quejarán de esto). Existe una ciencia completa sobre cómo realizar un seguimiento del progreso del proyecto con este método, ya que la cantidad de nuevas tareas se acelerará al principio y debería desaparecer hasta el final del proyecto.

La idea es iterar código y diseño. Utilizamos este proceso en mi empresa anterior (con 130 desarrolladores) y funciona muy bien. También utilizamos Doxygen para producir diagramas de clase y relación a partir del código. Esta fue una forma rápida de obtener una buena visión general del diseño realmente codificado, para detectar fallas y relaciones faltantes.

Si esto funciona para ti o no, no puedo decirlo. Tienes que probar y ver qué funciona mejor para ti.

También voy a hacer una señal con mis dos centavos.

Escribir un programa completo en papel antes de comenzar es un ejercicio "CS 101" que funciona para Hello World. Pero lanzar código sin tomarse el tiempo para pensar en lo que quiere lograr también es una pérdida de tiempo.

Entre estos dos extremos, tiene la gama completa de metodologías de software, desde la cascada dura (un conjunto expansivo de especificaciones, casi una salida al final) hasta ágil (especificaciones "ligeras" con un cambio muy rápido entre versiones y constante " cliente "diálogo).

En cualquier caso, necesita saber qué está construyendo antes de poder comenzar, sea cual sea la metodología. Esto ayudará a enmarcar la arquitectura del programa. Waterfall pondrá énfasis en tener todo el sistema arquitectónico antes de comenzar a codificar, para que sepa con qué terminará. Agile pondrá énfasis en "especificar la funcionalidad mínima que se logrará para la próxima iteración", y le recomendará que esté preparado para la re-arquitectura constantemente (mediante la creación de conjuntos de pruebas adecuados y similares para que pueda realizar ese trabajo). ).

Tenga en cuenta que NINGUNA metodología le dirá que simplemente comience a codificar sin pensarlo, y de hecho, debe tener una idea bastante buena de lo que está tratando de hacer (ya sea todo con Waterfall, o un área más pequeña con Agile ). Improvisas un poco en "CÓMO" haces algo, no en "QUÉ" que intentas hacer.

Puedo dibujar un paralelo con lo que aprendes cuando tomas lecciones de actuación. Una gran parte es la "improvisación". Al comenzar una improvisación, debes entrar con la menor cantidad de piezas de piedra que puedas y estar preparado para abandonar tu idea si alguien toma la escena en otra dirección. Necesitas grandes habilidades para escuchar, y necesitas aceptar las proposiciones de los demás. Lo principal es subir al escenario con un personaje, una situación, tal vez un sentimiento que quieras transmitir y, potencialmente, un final hacia el que quieras tomar la escena. Pero cuanto más lejos esté la idea en la escena, más probable es que termines en otro lugar. Al final, es una forma de pensar muy "ágil", que podría ser con lo que estás luchando aquí.

Ahora, si está hablando en el nivel "escribamos código" (especificaciones, historias o lo que esté disponible), entonces depende de usted. Algunas personas escriben pseudocódigo, otras escriben comentarios antes del código real (en una "forma en blanco" y otras comienzan escribiendo pruebas (consulte Desarrollo guiado por pruebas). En cualquier caso, el objetivo es enmarcar su idea para que usted pueda lograr lo que se propuso hacer en su método particular. En ese nivel, la mayoría de la gente piensa antes de escribir el código real. Pero ir tan lejos como para escribir el código antes de que aparezca en el papel me parece excesivo ...

El cazador obligatorio S. Thomson cita pero siempre funciona para mí

Si tienes una idea clara de lo que quieres lograr, sabes cómo estructurar tu código y eres un buen programador, a menudo es más rápido solo para escribir el código.