¿Es normal pensar en un problema de diseño durante días sin código escrito? [cerrado]

A veces miro fijamente al espacio o bosquejo ideas y escribo algunos pseudocódigos en papel. Luego lo tacho y comienzo de nuevo, luego, cuando creo que tengo la solución correcta para el problema, comienzo a escribir el código.

¿Es normal pensar durante días sin escribir ningún código? ¿Es esta una señal de que me estoy acercando al problema completamente equivocado? Me pone nervioso no tener ningún código tangible escrito en mi IDE.

Dependiendo del problema que intente resolver, la fase de diseño puede llevar semanas y meses (si no años), no solo días.

Se necesita experiencia para no comenzar a descifrar el código inmediatamente. Pensar en la arquitectura y el diseño de alto nivel debería llevar días, si no más, definitivamente algo que debería suceder antes de comenzar a escribir su código.

Esto se conoce comúnmente como "parálisis de análisis"

Es común pero está mal. En algún momento, debe probar las diversas ideas para ver cuál funcionará mejor para usted y luego mejorarlo gradualmente.

Lectura recomendada del programador pragmático Específicamente el Capítulo 2 la sección sobre "Tracer Bullets"

Esto es completamente común. Sin embargo, si adopta un enfoque de "Prueba primero" o TDD, es menos común y podría ayudarlo a formular mejor sus ideas.

Los hábitos generalmente son el resultado de enfoques de prueba y error de las cosas y de continuar lo que nos da los resultados deseados y evitar lo que no. Hacer lo que nos gusta y evitar lo que no nos gusta también entra en juego. Eso funciona hasta cierto punto porque eventualmente haremos algo que no nos gusta para que se pague el alquiler.

Depende de lo que te lleve a esto y tus razones. Aquí hay algunos:

• Con demasiada frecuencia, ha tenido que cambiar el código debido a cambios en el diseño.
• No cambia un diseño deficiente porque la solución menor ya estaba codificada
• Prefieres dibujar y diseñar que escribir procrastinación de código
• tener que preocuparse por la sintaxis y los detalles de la codificación lo distrae de pensar en mejores diseños.

Con suerte, ha descubierto que si diseña más tiempo, su código es mejor. Si puede mirar hacia atrás y ver que no importa cuánto tiempo dedique al diseño, puede cambiar. Otra consideración es la frecuencia con la que descubre problemas después de haber escrito el código en comparación con el trabajo con sus diseños. Si no encuentra problemas hasta después de escribir un código, debe considerar un equilibrio y comenzar a codificar algo más temprano que tarde. Tal vez este enfoque podría aplicarse al uso de nuevas tecnologías o una característica muy compleja.

No sé si tengo la disciplina para mantener un enfoque u otro, incluso cuando descubro que uno funciona mejor que el otro. A veces siento la necesidad de ir a la pizarra; otros el teclado.

Es muy común y siento que es una mejor manera de manejar y comprender las cosas. Mientras trabajo en un proyecto, me atasco muchas veces y me toma un día o dos entender cómo puedo abordarlo mejor. Incluso después de que se resuelva el problema, espero que pase un día. Esto me refresca y me pone en marcha.

Es un fenómeno natural y bueno para un desarrollador interceptar su tiempo mental y entre ellos.

Cuando tomé un curso de gestión de proyectos, una de las cosas que el instructor nos relató sobre planificación, que se me quedó grabado en la cabeza, fue que la regla general que enseñaban en el ejército era calcular 1/3 del tiempo para planificar . Entonces, si tuvo una operación que requirió completar 3 meses a partir de ahora, piense en gastar un mes en la planificación antes de comenzar la ejecución.

En mi opinión, hay tres enfoques, cada uno adecuado para una situación de codificación específica

1. He visto un problema similar antes, así que tengo una idea bastante buena de los patrones a aplicar, y está claro cómo debe comportarse y responder la solución.

   => Utilice BDD / TDD a partir de las soluciones deseadas y trabajando en el código. (Ok, a veces hago trampa y escribo un poco de código y luego la prueba, una especie de enfoque anidado 2. -> 1.).

2. Tengo una buena idea de los patrones para aplicar, pero no estoy seguro de cómo debería ser la solución.

   => Prototipo para ver qué tipo de cosas interesantes aparecen. Pase a 1. cuando descubra qué cosas interesantes se desean.

3. No estoy seguro de qué patrones aplicar.

   => Piensa en el problema y cómo las diversas formas de abordar el problema influyen en el código. Pase a 2) o 1) según el resultado de ese ejercicio.

En otras palabras, la respuesta es la favorita del ingeniero: depende.

Es mejor pasar un mes pensando y diseñando que preparar un prototipo rápido basado en un diseño deficiente que luego se debe poner en forma. Especialmente si estás en un equipo; Una vez que otros comienzan a depender de su código, es mucho más difícil implementar un mejor diseño con una API diferente.

Estoy de acuerdo con las otras respuestas que, en principio, tomarse el tiempo para pensar un problema / solución es una buena idea. Sin embargo, si siente que está atascado, tengo algunas recomendaciones sobre cómo hacer que el proceso de planificación sea un poco más coherente:

• Crea artefactos de diseño. ¿Y qué si no escribes código? Tal vez solo escriba un diario de sus pensamientos. O un boceto de una solución general. O incluso un resumen realmente bueno del problema que refina con el tiempo. Al considerar las ideas y aceptarlas / rechazarlas, mantenga un registro de su razonamiento sobre el tema. De esta manera, al final del día, aún puede señalar los entregables del mundo real como evidencia de su trabajo.

• ¡Hablar con las personas! No hay nada como tener un ser humano vivo y con quien discutir ideas. Si crees que estás atrapado, háblalo con alguien. Agarra a alguien, ¡a cualquiera! Y explícales el problema. Esboza tus pensamientos sobre cómo resolver el problema. Incluso si todo lo que hacen es inhalar, exhalar y parpadear durante diez minutos mientras balbuceas, lo más probable es que descubras una nueva visión solo en el proceso de explicar el problema .

Como dijo Satchel Paige: "A veces me siento y pienso, y a veces me siento".

Supongo que a lo que se refería es que a veces es bueno despejar la mente, ya que puede llevarlo a pensar en su problema de una manera diferente. Por lo tanto, si no está golpeando el código, puede encontrar una solución o idea que podría haberlo evadido de otra manera. Entonces, sí, es normal y una buena práctica no saltar directamente a la codificación.

Hay dos formas en que hago este proceso yo mismo. Creo una carpeta donde tengo un archivo de texto y cualquier dibujo relacionado con el proyecto. Anoto mis ideas allí y trato de guardar todo el proceso de pensamiento lo mejor que puedo. También crearé un proyecto de scratchpad donde pueda probar rápidamente ideas simples desde algoritmos hasta diseños CSS.

Programa = Algoritmo + Estructura de datos

En mi humilde opinión, el proceso de diseño (resolución de problemas) gobierna totalmente. Los detalles de implementación (problema técnico) siguen y resuelven naturalmente.

Aquí está mi caso de pensamiento.

1. Comenzando desde cero Primero se requiere una idea aproximada de lo que desea. Intente obtener una lista de algunos requisitos o créelos. Debería llevar un poco de tiempo resolver las cosas aquí. Una vez que tenga al menos una pieza que está seguro de que desea, conozca la mayor parte de la interfaz de esa pieza, luego comience a codificar.

2. Solución de un problema con el código existente En primer lugar, realice un seguimiento del problema. Esto puede requerir un tiempo de no escribir código real (es posible que se escriba algún código de depuración, pero esto generalmente no se guardará). Una vez que encuentre el problema, dependiendo de la complejidad, comience a escribir código para intentar solucionarlo. Se debe pensar poco una vez que se conoce el error. Si el problema resulta ser un gran defecto de diseño, consulte la siguiente sección.

3. Cambios de diseño / características principales Esta es probablemente la que requerirá más atención. Se debe incluir la idea de preservar la estructura, la compatibilidad con versiones anteriores, etc. Pensar en el mejor cambio podría ahorrarme un tiempo significativo, pero generalmente para mí no es más que unos pocos días.

4. Agregar una función simple Si no se requiere un cambio significativo en el diseño, simplemente codifique su función, utilizando alguna prueba / error. Esto no debería requerir mucho tiempo en general.

No voy a estar de acuerdo con el consenso sobre este. Prefiero comenzar a crear prototipos de algo tan pronto como tenga la más vaga idea escrita de una servilleta de cómo quiero que funcione mi sistema. Es casi imposible para mí pensar en todos los pequeños detalles que pueden causar problemas a menos que esté especificando las cosas de una manera muy precisa. Si solo estoy discutiendo el diseño con la gente, es demasiado fácil simplemente agitar algunos de los problemas más complejos. Una vez que especifique cosas como esta, también puede estar directamente en el código fuente en lugar de algún otro medio de expresión que sea igual de preciso y formal, pero que no se pueda compilar y ejecutar.

Depende de qué quieres decir con "normal" . Hablando de mí, creo que el código es una gran herramienta de aprendizaje. Entonces, cuando enfrento un problema complejo, hago bocetos en papel pero también hago algo de codificación basada en pruebas. Code me dice que piensa que una pizarra no puede decir y viceversa, y tal vez el resultado sea una idea o la necesidad de un par de preguntas más para el experto en el dominio.

Entonces, el verdadero consejo es: "Use todas las herramientas de aprendizaje necesarias para acercarse a la definición del problema" , pero también "recuerde que estas son herramientas de aprendizaje, así que no se enamore de ellas", tanto el código como los bocetos están destinados a ser desechables .

En esta era de RAD y programación ágil, debe comenzar a desarrollar tan pronto como pueda identificar las partes principales del sistema, aparecerán detalles. Como los softwares son cada vez más grandes, enfocarse prematuramente en cada detalle no lo llevará a ninguna parte.