Cuando está comenzando un nuevo proyecto, ¿cómo lo planifica o cuánto tiempo lleva?
¿Pseudocódigo? Diagramas de flujo?
¿Tratas de pensar en todas las clases por adelantado?
TBH, nunca planifico nada. Lo entiendo directamente y pienso en soluciones a medida que surgen problemas. Principalmente porque las pocas veces que intenté planificar con anticipación, siempre me olvidaba de algo importante, y por lo tanto, la lógica de la planificación sería defectuosa.
Mucho menos de lo que debería
Siempre buzo, me ensucio y luego me doy cuenta de que he hecho un desastre. Luego regresa y planifica, y hazlo bien.
pero la fase de errores desordenados me da grandes ideas que no hubiera tenido en cuenta a través de un proceso de diseño formal.
Editar : Obtengo principalmente este tipo de destrucción de los problemas del teclado cuando juego con mayor / complejo. Es interesante ver cuán lejos están las cosas antes de que te des cuenta de que tu diseño "está en mi cabeza, así que está bien" es 100% defectuoso.
Depende. La mayoría de las cosas que escribo son bastante sencillas y un diseño más grande se construye paso a paso y noto lo que aún falta y lo que ya está completo. Hubo algunas cosas más peludas que requirieron bocetos extensos y se pensó que iban bien, aunque aún no me he encontrado con muchos problemas arquitectónicos que lo requerían (todavía jóvenes y demás). La mayoría eran cosas aritméticas difíciles.
En mi pasantía el año pasado, mi gerente se sorprendió gratamente al utilizar diagramas de flujo para un problema. Él pensó que era un arte perdido con los estudiantes en estos días. No me sorprendió tan gratamente que se los considerara anticuados.
De todos modos, depende de la línea de tiempo del proyecto para mí, los plazos son lo más importante, por supuesto.
Probablemente no sea la mejor técnica ... pero ... planeo en código .
A menudo descubro clase / métodos / etc. que necesito solo por hacerlo de esta manera. Dicho esto, siempre asumo que mi código de planificación no será la solución final.
Además, escribiré notas que detallen "características principales" y "características menores / deseadas".
Cuando tomo un problema de cualquier tamaño, siempre planeo escribirlo al menos dos veces.
Todo depende de cuán grande sea el proyecto. A veces puede tomar meses reunir todos los requisitos y saber exactamente lo que debe hacer.
Cuando se trata de la parte de codificación, todo depende de lo complicado que sea. Si es extremadamente complicado, comenzaré simplemente por extraer lo que quiero que haga. Luego escribiré mi pseudo código en comentarios. Luego codificaré esos comentarios.
Sin embargo, si es simple codificación. Por lo general, solo escribo lo que tengo en mente y lo pruebo.
Usamos un enfoque muy ágil en el sentido de que trabajaremos en las partes principales y, por supuesto, las cosas siempre aparecen para aparecer en los requisitos. Así que acomodaremos para aquellos a medida que surjan. Nunca sabrá exactamente qué quiere crear exactamente al comienzo del ciclo de creación.
Esa es mi opinión.
La mayoría de las veces, al menos trato de tener un diagrama general (incluso en mi cabeza) de cómo funcionará el módulo / sistema. Me gusta saber lo que voy a hacer antes de hacerlo. Hace que la programación sea más fácil y más rápida (por lo general, tenemos plazos ajustados en los que trabajo). Cada vez que no lo hago, me encuentro con problemas que generalmente me llevan a sacar código y ponerlo en otro lugar. Lo admitiré, mi proceso llegó a través de una amarga experiencia y me volví realmente bueno al usar regex en el código junto con el descubrimiento y reemplazo global.
Alguien más sacó un buen punto, a veces tienes un sistema realmente grande y eso se pone difícil. Intento dividirlo en pedazos. Trabajaré en algo y lo perfeccionaré, y trabajaré en algo más por un tiempo y veré cómo interactúan. Incluso con la planificación anticipada, extraño las cosas y tengo que refactorizar el código, pero al menos no estoy rehaciendo todo, ya que al menos tenía algún tipo de plan de trabajo.
Depende de cuán complejo es el problema que está tratando de resolver. Si está asumiendo un gran proyecto de programación, debe tener un cierto grado de planificación antes de comenzar. Si no lo haces, te perderás terriblemente en los detalles de las cosas que no se comunican con las otras partes en muy poco tiempo.
Básicamente, trate de obtener una vista panorámica de los problemas que necesita resolver. Vea si alguno de los problemas es lo suficientemente pequeño como para poder resolverlos y descubrir qué podría necesitar para comunicarse con el resto de su solución. Piense en ello como una caja negra con una API para el mundo exterior.
Una vez que tenga todos sus bloques resueltos, vea si necesita dividir el problema en sub-problemas más pequeños, o si tiene una vista lo suficientemente detallada de todo el proyecto que puede comenzar con el código.
Mi experiencia es que la planificación te ayuda a prevenir problemas en el futuro, te hace pensar más sobre cómo se supone que crecerá el código en el futuro si necesitas agregar algo, etc.
En la mayoría de los casos, ahorrará el tiempo que invirtió en la planificación cuando está depurando o ampliando el proyecto. Además, tener una distribución aproximada del proyecto significa que será más fácil obtener ayuda para construir las cajas negras que necesita, para que pueda trabajar con más personas que usted.
Dependiendo de la complejidad del proyecto, generalmente empiezo con bloc de notas y papel, y escribo una especificación, y algunos pseudocódigos del flujo de control. Entonces siempre puedo referirme a eso mientras estoy codificando. Lo hace más fácil y requiere menos refactorización porque no pensaste en el problema.
Personalmente, depende del alcance y la complejidad del proyecto, con cuántas personas estoy trabajando y las expectativas generales de la entrega.
Es muy importante comprender las expectativas generales de las partes que utilizarán el software. Todos los involucrados en el proyecto deben tener una comprensión común de lo que se está trabajando: cómo se comunica se aplica en muchas direcciones.
Con demasiada frecuencia, las partes involucradas en el desarrollo de software no se dan cuenta de que la comunicación entre las partes a menudo es la parte más crítica y menos valorada del proyecto, y la principal causa de percances en los proyectos.
Después de la experiencia de MUCHOS proyectos sin terminar , tiendo a implementar una versión simplificada de mis procesos de negocios en mi metodología de desarrollo personal.
En general, siguen la siguiente estructura:
Preparo un poco de café y preparo un par de sándwiches.
Realmente depende del proyecto. Trabajé en algunos proyectos de la industria de la defensa que requirieron 2 años de planificación detallada antes de escribir una sola línea de código, y me senté y saqué algunas utilidades pequeñas de solo unas pocas solicitudes en un correo electrónico de un 3D o artista de la textura en una sola sesión con una bolsa de pretzels y una taza de Joe.
Poder desarrollar diagramas de flujo, diagramas UML, diccionarios de casos de uso y extensos estándares de codificación de antemano es una buena manera de mantener las cosas organizadas, y ciertamente vale la pena hacerlo en proyectos más grandes, equipos más grandes y proyectos de misión crítica. Pero estas cosas toman tiempo, y a menudo son exageradas para proyectos más pequeños.
Lo único que realmente debe asegurarse es que tenga una comprensión adecuada del dominio del problema. Si no, pasar el tiempo por adelantado para investigarlo hasta que lo haga siempre vale la pena.
Cuando estaba en la forma de "cascada" de hacer las cosas, escribía varios documentos de cientos páginas que mostraban todos los detalles que podrían descubrirse durante la investigación. Para llegar a este volumen masivo de documentación generalmente
En los últimos años he estado siguiendo junto con Agile (SCRUM) y he adoptado un enfoque totalmente diferente.
Debo decir que Agile reduce la cantidad de tiempo dedicado a escribir documentos que se deterioran tan pronto como la tinta se seca. El propietario del producto puede ver los resultados de una manera mucho más rápida. Lo que significa que pueden mantener el proyecto en la dirección correcta en el tiempo, incluso si esa dirección cambia a medida que avanzamos.
Tenga en cuenta que hay un tiempo y un lugar para ambas formas de desarrollo. ¡No me gustaría construir software Jet usando Agile!
Todavía estoy en la universidad y aún no tengo experiencia en la creación de sistemas de software a gran escala, pero ...
Lo primero que hay que hacer es encontrar lo que se quiere. Hasta ahora, para mí, esto normalmente es una especificación de asignación, pero en el mundo real implica hablar con el cliente. Mucho.
Luego averiguo cómo hacer lo que se requiere. Para los programas relativamente pequeños en los que he estado trabajando, normalmente tengo en mi mente una idea aproximada de cómo se verá mi programa (cuáles son las partes importantes del programa y cómo interactúan entre sí). Esto puede involucrar picos si no tengo idea de cómo funcionará alguna parte del programa. No creo que este enfoque (lo haga todo en mi mente) se escalará muy bien, pero la pregunta era preguntar qué hacemos realmente ...
Una vez que sé más o menos lo que estoy tratando de hacer, me siento y escribo el código. Es aquí donde descubro cualquier problema en lo que estaba pensando.
No creo que haya utilizado todos los pseudocódigos para diseñar un algoritmo. Creo que el pseudocódigo es de un nivel demasiado bajo para diseñar grandes fragmentos del programa.
Solo he usado un diagrama de flujo en una ocasión para ayudar con el diseño de un programa, cuando estaba aprendiendo ensamblaje y era bastante nuevo en programación (y fue útil). The Mythical Man-Month dice lo siguiente: "El detallado diagrama de flujo de golpe por golpe, sin embargo, es una molestia obsoleta, adecuada solo para iniciar a los principiantes en el pensamiento algorítmico ... Nunca he visto a un programador experimentado que hiciera rutinariamente detalles diagramas de flujo antes de comenzar a escribir programas ".
IMO 5 minutos de planificación anticipada = 1 hora de codificación ...
Muchas veces tenemos que volver y repensar toda la situación, porque no planificamos nada.
La parte más importante debe ser el FLOWCHART.
Los otros detalles a veces se pueden encargar sobre la marcha.
Dibujo diagramas de flujo extensas y escribo pseudo código para las funciones más complicadas. Siento que dibujar el diagrama de flujo me permite refactorizar sin introducir errores por accidente. Hacer un diagrama visual en papel como un diagrama de flujo también ayuda a averiguar si mi lógica es realmente correcta. Esto sólo funciona para las pequeñas - medianas proyectos donde se sabe que la mayor parte de las especificaciones.
Con más experiencia, la necesidad de dibujar diagramas de flujo extensas y escribir pseudocódigo función entera se convertirá en más redundante sin embargo antes de que llegue a ese punto, sugerimos que planea antes de código.
