¿Es malo que me guste “diseñar” en partes de papel de mi software antes de comenzar a codificar?

Sé que todos ya lo han dicho antes, pero voy a reiterar este punto porque hago lo mismo. Ningún desarrollador que valga su sal puede codificar antes de hacer un diseño. Los desarrolladores senior generalmente pueden hacerlo en su mente y luego pueden recordarlo cuando sea necesario. La razón de esto, es que para ellos, ningún módulo, ningún problema y ningún error es algo independiente. Han trabajado en algo que es similar a la situación actual, o que se parecía a él de una forma u otra. Como resultado, no están diseñando un nuevo software, están recordando viejos errores y puntos ciegos y luego se ocupan de no repetirlos. Con el tiempo, también llegarás a un nivel en el que podrás recordar las cosas viejas, en un abrir y cerrar de ojos.

Soy un desarrollador de nivel de entrada, y la forma en que hago las cosas actualmente es que uso la pizarra para dibujar todo el trabajo. Luego lo discuto con un senior, hago tantos ajustes como sea necesario, me siento, lo miro una vez en todo su esplendor. Y luego toca mi teclado, nunca antes. Estoy en un punto donde literalmente divido el diseño en partes donde decido si voy a pasar un puntero aquí o una variable. Probablemente ya hayas superado ese punto y ahora te diriges hacia arriba.

Así que siéntete orgulloso de tus técnicas y codifica esa mierda.

Lo que está haciendo es lo que la gente llama “creación de prototipos” en el campo del diseño de la experiencia del usuario. Es una excelente manera de planificar y evaluar enfoques alternativos, algo que los desarrolladores apenas hacen. ¡Buen trabajo!

Es esencial diseñar el programa antes de comenzar a escribir el código. Es posible que no los vea garabatear en los papeles porque tienen un método diferente para ello.

Para casos más simples, generalmente paso varias horas pensando en la idea general y las estructuras, lo hago mientras conduzco, me baño, como comer, y luego empiezo a codificar mientras sigo pensando en el panorama general .

Para casos más complejos, tomo un bolígrafo y una hoja de papel (o simplemente voy a la pizarra) y luego escribo todo lo que me viene a la mente, tratando de sacarle provecho.

Entonces sí, es perfectamente normal.

De ningún modo.
Usar documentos para organizar las cosas en el desarrollo es una gran práctica.
Mantener todo organizado le ayudará a pensar con claridad.
Nunca sentirá la carga de recordar todo una y otra vez, cada vez que los necesite.
Eso se llama el poder de la organización.
Tiene el potencial de impulsar tu carrera mucho más rápido que cualquiera que no la siga.

Por el contrario, ¡es genial!
Mi tutor de programación solía decir que “la programación comienza con un lápiz y papel”. Tu pregunta indica que has acertado intuitivamente.

Pensar la imagen completa primero promueve un diseño “de arriba hacia abajo” y una mejor estructura de software. Vale mucho la pena cuando codificas más adelante.

¡¡¡¡¡Absolutamente no!!!!!

Es la forma correcta de diseñar un proyecto y le permite ver las partes móviles y cómo interactúan. No es necesario que haga un diagrama de flujo a la antigua, pero necesita abarcar a todos los actores y conexiones, y hacer funciones y subrutinas para ellos.

A medida que identifica las partes móviles, puede crearlas utilizando pseudocódigo en los comentarios. Mientras escribe el código en particular, los comentarios serán su guía, y el ‘plan’ en papel lo ayudará a mantener su plan correcto y ordenado.

No. Diferentes personas resuelven problemas de manera diferente. La mayoría de las veces, excepto si está programando algo trivial, debe hacer análisis, planificación, diseño de prototipos, etc. antes de codificar algo.

Cuando está en un equipo en desarrollo, probablemente diferentes personas ya hicieron ese trabajo anterior y el programador recibe una tarea específica.

Tal vez pueda hacer su parte directamente, o tal vez necesite organizar sus ideas de la manera que describa. Depende de cuán compleja sea su tarea, cuán grande, cuán experimentado sea, si hizo algo similar en el pasado, etc.

Para nada, también es la forma en que codifico. Considero una señal de planificación adecuada y una gran estrategia de desarrollo. Este enfoque le permite ver algunas dificultades potenciales con la aplicación antes de que quede enterrado en toneladas de código.

¡Sigan con el buen trabajo!

Eso es algo bueno antes de codificar. Hago eso también. Primero diseño mis sitios web en forma de marcos de alambre y me ayuda como desarrollador web front-end. ¡Nada tiene de malo!

Es genial que lo hagas primero en papel. En realidad, es muy recomendable. Me sorprende que sus compañeros de trabajo no lo hagan, pero una vez más, podrían estar utilizando un software de creación de prototipos, lo cual también está bien, si uno quiere ser amigable con el medio ambiente.

No, es una señal de que no te equivocarás depurando todas las cosas que escribiste, línea por línea. Es bueno tener todo en el papel para que cualquier falla técnica de la tarea sea identificada.
Cuando haces la misma tarea una y otra vez, esto no necesita ser necesario y es por eso que muchos omiten esta práctica. Sin embargo, siempre se recomienda anotar todo en papel, en lugar de quedarse atascado en la pantalla de la computadora preguntándose sobre el próximo código.