Al desarrollar algoritmos, ¿omitir la fase de lápiz y papel es un mal hábito? [cerrado]

Escuché a muchas personas decir que al desarrollar algoritmos, primero debe usar lápiz y papel, diagramas de flujo y demás, para que pueda enfocarse en el algoritmo en sí mismo, sin preocuparse por la implementación de dicho algoritmo (es decir, enfrenta un problema a la vez hora).

Sin embargo, la mayoría de las veces me resulta más fácil desarrollar mi algoritmo sobre la marcha. Es decir, pienso un poco en el problema hasta que sé la dirección general que debo tomar, y luego comienzo a escribir código y hacer cambios hasta que el algoritmo emerge y funciona.

¿Es este un mal hábito que debería intentar cambiar?

Algunos desarrollos algorítmicos pueden requerir muchas pruebas y ajustes de prueba y error, ya que uno puede encontrar que las suposiciones que entrarían en un diseño estrictamente en papel no son lo suficientemente precisas cuando se dan restricciones de rendimiento y datos reales.

Tal vez la iteración (think-code-test-think-code-test ...), en lugar de solo una opción u otra para el "hábito" óptimo.

También hay un camino intermedio, que suelo usar. No pensar demasiado de antemano y no perderme en los detalles de mi código ...

TDD (desarrollo impulsado por pruebas) le permite pensar un poco y luego hacerlo funcionar; luego piense un poco más sobre lo que necesita, luego haga que funcione, teniendo la red de seguridad que su caso de uso anterior sigue funcionando en todo momento ... Los pasos son:

1. Escriba una prueba (es decir, un caso de uso).
2. Míralo fallar, haz que el fracaso sea comprensible.
3. Escribe el código.
4. Refactorice el código y la prueba.

Esto depende de sus hábitos de pensamiento y la complejidad del algoritmo.

El lápiz y el papel ofrecen un pensamiento de "forma libre" sin que un compilador grite a cada personaje que escriba.

Algunos de nosotros que usamos lápiz y papel, nos tomamos el tiempo para ajustar los límites de los bucles, probar diferentes valores, etc.

Entonces, supongo que escribir el código directamente fomenta el enfoque de prueba primero mientras que el lápiz y el papel promueven el enfoque de pensar primero. Es definitivo que si la tarea es trivial, puede codificarla sobre la marcha (si tiene suficiente experiencia) pero los algoritmos complejos probablemente necesitarían un enfoque de desarrollo diferente.

Los diagramas ayudan en algunos casos, pero esto requiere que esté familiarizado con ellos y los haya usado antes.

Creo que el tuyo es el enfoque más común. Si el algoritmo es especialmente complejo o difícil, puede ser difícil tanto descifrar el algoritmo como implementarlo a la vez, pero en general dudo que ayude a la mayoría de las personas.

Pero, por ejemplo, no inventaría reglas para una gramática e implementaría un analizador sin escribir las reglas en papel (o tal vez con alguna herramienta especial que no tengo) primero, o implementar un B-Tree sin pseudo- Código disponible.

No diría que tienes un mal hábito a menos que te esté haciendo daño, y creo que lo notarías si lo fuera.

¿Quiénes son estas "muchas personas"? ¿Y están programando para ganarse la vida? Lo que estás haciendo es exactamente lo que hacen la mayoría de los programadores, al menos la mayoría de lo que he conocido. Hay poco uso para el papel cuando es más rápido escribir, y poco uso para el pseudocódigo cuando se programa en un lenguaje de alto nivel. Ocasionalmente uso lápiz y papel para visualizar un algoritmo complicado (por ejemplo, rotar un árbol), pero sobre todo empiezo con un código de alto nivel y gradualmente lleno los espacios en blanco.

Al igual que KLE, creo que esto funciona mejor después del desarrollo basado en pruebas. Suponiendo que va a escribir pruebas de todos modos, es mejor que las escriba primero.

puede crear un diseño mientras realiza las clases, métodos y pruebas de código auxiliar, pero puede atascarse mientras crea los detalles

Para las cosas realmente complejas (compiladores y demás), un diseño de bolígrafo y papel (o al menos en una herramienta de diseño) lo ayudará a mantener el rumbo y la vista en toda la imagen y evitar malas elecciones de diseño e incluso permitirle elegir ciertos patrones de diseño desde el principio

pero en última instancia depende de qué tan bien puedas seguir viendo el panorama general

Recomiendo esbozar las instrucciones generales (la fase de "lápiz y papel") antes de saltar a la implementación para ahorrar tiempo eliminando los requisitos / restricciones más obvios .

Luego, puede ajustarlo en el camino dado que nunca puede adivinar todo al principio porque pueden aparecer / aparecerán más restricciones más adelante en el desarrollo, por varias razones.

De esa manera, sabrá a dónde va, pero aún puede adaptarse a los cambios.

1. La cantidad de preparación necesaria suele ser proporcional a la complejidad de lo que está haciendo. No tiene sentido escribir con lápiz y papel 2 días completos para un algoritmo que se usa una vez en un trimestre, funciona una hora en una sola máquina. Tiene sentido escribir con lápiz y papel tres semanas-hombre (si es necesario) para diseñar el nuevo módulo compensador de flujo de alto rendimiento que podrá procesar medio millón de solicitudes por hora y debe ejecutarse 24/7/365 sin tiempo de inactividad.

2. Puede ver si es un mal hábito en 30 segundos si observa qué soluciones está codificando. Usted preguntó si es un hábito bueno o malo. Bueno, eso depende de ti. Si es un principiante lento al comienzo de su carrera de programación, probablemente sea una buena idea escribir con lápiz y papel para detallar todo. Si tiene algunos años de experiencia, será suficiente con pensarlo durante 5 minutos y luego simplemente hacerlo. Por supuesto, aún con respecto a 1. anterior.

Línea de fondo

Solo su código dice la verdad si necesita más o menos lápiz y papel. No dejes que nadie más te dicte eso, pero descúbrelo por tu cuenta. Eso te mantiene aprendiendo.

_{Descargo de responsabilidad: Esto puede no ser lo que se llama pensamiento convencional y sentido común. Está bien. Simplemente establezca un marcador y léalo nuevamente en aproximadamente cinco años.}