A veces miro fijamente el espacio o bosquejo ideas y escribo algunos pseudo códigos en un papel. Luego lo borro y vuelvo a empezar, 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 totalmente equivocado? Me pone nervioso no poder escribir ningún código tangible en mi IDE.
Dependiendo del problema que esté intentando resolver, la fase de diseño puede tomar semanas y meses (si no años), no solo días.
Se necesita experiencia para no comenzar a eliminar el código de inmediato. Pensar en la arquitectura y en el diseño de alto nivel debería tardar días o 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 qué funciona mejor para usted, y luego mejorarla de manera gradual.
Lectura recomendada el programador Pragmático específicamente en el Capítulo 2 la sección sobre "Viñetas de seguimiento"
Esto es completamente común. Sin embargo, si toma un enfoque de "Probar primero" o TDD, es menos común y podría ayudarlo a formular mejor sus ideas.
Los hábitos suelen ser el resultado de los enfoques de prueba y error de las cosas y 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 poder pagar la renta.
Depende de lo que te lleve a esto y tus razones. Aquí hay algunos:
Esperemos que hayas descubierto que si diseñas más, tu código es mejor. Si puede mirar atrás y ver que no importa cuánto tiempo dedique al diseño, es posible que desee cambiar. Otra consideración es la frecuencia con la que está descubriendo problemas después de haber escrito un código en comparación con el trabajo con sus diseños. Si no encuentra problemas hasta después de escribir algún código, debe considerar un balance y comenzar a codificar algo más temprano que tarde. Quizás este enfoque podría aplicarse al uso de nuevas tecnologías o una característica muy compleja.
No sé si tengo la disciplina para seguir con un enfoque u otro incluso cuando descubro que uno funciona mejor que el otro. A veces siento la necesidad de ir a la pizarra blanca; otros el teclado.
Es muy común y creo que es una mejor manera de manejar y entender las cosas. Mientras trabajo en un proyecto, me quedo atascado muchas veces y me lleva un día o dos entender cómo puedo enfocarlo mejor. Incluso después de resolver el problema, espero que pase un día. Esto me refresca más y me pongo en marcha.
Es un fenómeno natural y es bueno para un desarrollador interceptar su tiempo mental y el intermedio.
Cuando tomé un curso sobre gestión de proyectos, una de las cosas que el instructor nos relató acerca de la planificación, que se me quedó en la cabeza, fue que la regla de oro que enseñaron en el ejército era representar 1/3 de la tiempo para la planificación. Por lo tanto, si tuvo una operación que requirió que se completara dentro de 3 meses, calcule cómo 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
He visto un problema similar antes, así que tengo una idea bastante buena de los patrones que se deben 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 anidado 2. - > 1. enfoque).
Tengo una buena idea de los patrones que aplicar, pero no estoy seguro de cómo debería ser la solución.
= > Prototipo para ver qué tipo de cosas interesantes salen. Mover a 1. cuando descubro qué cosas interesantes se desean.
No estoy seguro de qué patrones aplicar.
= > Piense en ello el problema y cómo influyen en el código las diversas formas de abordar el problema. Pase a 2) o 1) dependiendo del 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 para crear un prototipo rápido basado en un diseño de calidad inferior que luego tiene que darle 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 de que, en principio, tomarse un tiempo para pensar en un problema / solución es una buena idea. Sin embargo, si sientes que estás estancado, tengo algunas recomendaciones para 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 usted acaba de escribir un diario de sus pensamientos. O un esbozo de una solución general. O incluso simplemente un buen resumen del problema que refinó con el tiempo. Cuando considere ideas y las acepte / rechace, mantenga un registro de su razonamiento sobre el tema. De esta manera, al final del día, todavía puede señalar los entregables del mundo real como evidencia de su trabajo.
¡Habla con la gente! No hay nada como tener un ser humano que viva y respire con quien discutir ideas. Si crees que estás atascado, háblalo con alguien. Agarra a alguien - ¡a cualquiera! - y explícales el problema. Haz un bosquejo de tus pensamientos sobre cómo resolver el problema. Incluso si todo lo que hacen es inhalar, exhalar y parpadear durante diez minutos mientras balbucea, es probable que descubra una nueva perspectiva solo en el proceso de explicar el problema .
Como dijo Satchel Paige, "A veces me siento y pienso, y otras veces simplemente me siento".
Supongo que a lo que se refería es que a veces es bueno aclarar tu mente, ya que puede llevarte a pensar en tu problema de una manera diferente. Entonces, si no estás golpeando el código, puedes encontrar una solución o idea que te haya evitado de otra manera. Entonces, sí, es normal y una buena práctica no saltar directamente a la codificación.
Hay dos formas de hacer este proceso yo mismo. Creo una carpeta donde tengo un archivo de texto y cualquier dibujo relacionado con el proyecto. Anoto mis ideas allí e intento guardar todo el proceso de pensamiento lo mejor que pueda. También crearé un proyecto de bloc de notas en el que pueda probar rápidamente ideas simples desde algoritmos a diseños CSS.
Programa = Algoritmo + Estructura de datos
En mi humilde opinión, el diseño (resolución de problemas) procesa totalmente las reglas. Los detalles de la implementación (problema técnico) se siguen y resuelven de forma natural.
Aquí está mi caso de pensamiento.
Empezando desde cero Primero se requiere una idea aproximada de lo que desea. Trate de obtener una lista de algunos requisitos, o crearlos. Debería tomar un poco de tiempo resolver las cosas aquí. Una vez que tenga al menos una pieza que confíe en que desea, conozca la mayor parte de la interfaz de esa pieza y luego comience a codificar.
Solucionar un problema con un código existente En primer lugar, realice un seguimiento del problema. Esto puede requerir algún tiempo para no escribir código real (se puede escribir algo de código de depuración, pero esto generalmente no se mantendrá). Una vez que encuentre el problema, dependiendo de la complejidad, comience a escribir el código para intentar solucionarlo. Se debe pensar poco una vez que se conoce el error. Si el problema resulta ser un defecto de diseño importante, consulte la siguiente sección.
Cambios de diseño / características principales Es muy probable que esta sea la que requiera más atención. Se debe incluir el pensamiento en cuanto a la preservación de la estructura, la compatibilidad hacia atrás, etc. Pensar en el mejor cambio podría ahorrar un tiempo significativo, pero en general para mí no es más que unos pocos días.
Agregar una función simple Si no se requiere un cambio de diseño significativo, simplemente codifique su función, usando alguna prueba / error. Esto no debería requerir una tonelada de tiempo en general.
Voy a estar en desacuerdo con el consenso en este caso. Prefiero comenzar a crear prototipos de algo tan pronto como tenga una idea más vaga y escrita sobre una servilleta de cómo quiero que funcione mi sistema. Es casi imposible para mí pensar en todos los pequeños detalles que podrían 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 muy fácil simplemente agitar manualmente algunos de los problemas más complejos. Una vez que estoy especificando cosas como esta, puede ser que esté directamente en el código fuente en lugar de en otros medios de expresión que sean tan precisos y formales, pero que no puedan compilarse y ejecutarse.
Depende de a qué se refiere con "normal" . Hablando de mí mismo, creo que el código es una gran herramienta de aprendizaje. Entonces, cuando me enfrento a un problema complejo, hago bocetos en papel, pero también hago un poco de codificación basada en pruebas. El código dice que piensa que una pizarra no puede decir y viceversa, y tal vez el resultado sea una visión o la necesidad de un par de preguntas más para el experto en dominios.
Por lo tanto, 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 caiga en la amor con ellos " tanto el código como los bocetos están destinados a ser desechados.
En esta era de RAD y programación ágil, debería comenzar a desarrollar tan pronto como pueda identificar las partes principales del sistema, los detalles aparecerán. Debido a que los softwares se están haciendo más grandes, enfocarse prematuramente en cada detalle no lo llevará a ninguna parte.
Lea otras preguntas en las etiquetas design