Soy un programador intermedio con algunos años de experiencia profesional que está a la mitad de una maestría. Al aprender a programar, a menudo escuché dos consejos aparentemente contradictorios.
El primer consejo fue hacer que algo funcione rápidamente, ver cómo funciona (ya sea a través de prototipos o pruebas informales), mejorar la versión, ver cómo funciona nuevamente, mejorarlo nuevamente ... y luego repetir el ciclo hasta que haya terminado . Esto a veces se llama "desarrollo en espiral" o se expresa como "lanzamiento temprano, lanzamiento a menudo".
El segundo consejo fue: realmente piense en un proyecto antes de escribir cualquier código.
He tenido éxito con ambos métodos y diría que estoy de acuerdo con cada filosofía.
Pero ahora estoy empezando a abordar proyectos mucho más complejos que no tengo idea de cómo completar (como las aplicaciones distribuidas y la programación de gráficos basada en el rendimiento).
¿Cómo hago para estos proyectos?
¿Acabo de comenzar a codificar ALGO y aprender (plataformas / métodos / lenguajes / arquitecturas) a medida que avanzo, o evito la codificación y hago un montón de investigación / lectura incluso antes de abrir el IDE?
¿Cómo concilio estos consejos contradictorios de programación?
fuente
Respuestas:
No estoy seguro de que pensar en un problema antes de tiempo versus un enfoque iterativo sea contradictorio entre sí. Al igual que muchas otras cosas, creo que debe esforzarse por lograr el equilibrio entre los dos. ¿Cómo encuentras el equilibrio? Eso es algo que aprende con la experiencia y, a menudo, las mejores lecciones de tiempo (es decir, cosas que le dan experiencia) es cuando no lo hace bien (o incluso una mejor lección: simplemente hágalo mal). Como ya señaló, hay un dicho "liberar rápido, liberar a menudo". Hay otra similar, "falla temprano, falla rápido, falla a menudo"
Pensar en el futuro es genial y absolutamente debes hacerlo. Pero con experiencia, aprenda cuándo dejar de pensar y simplemente construir algo, incluso si no tiene todos los datos. Al construirlo, podrá obtener más información sobre el dominio del problema y, potencialmente, encontrar una solución mucho mejor. Por lo tanto, recomiendo no excluir una de la otra, pero hacer que la "mente pensante" sea parte de sus iteraciones y, con el tiempo, creo que encontrará la respuesta correcta a esta pregunta usted mismo.
Solo un pequeño ejemplo. El otro día estaba luchando con una decisión de diseño de software. En retrospectiva, era relativamente trivial, pero tenía dos alternativas y parecía que ambas funcionarían. Seguí dando vueltas a los pros / contras de cada uno y luego dando vueltas y reconsiderando mis decisiones. Mirando hacia atrás, es un poco vergonzoso cuánto tiempo pasé pensando. Entonces me dije a mí mismo, f # @ k! Y en lugar de usar cualquiera de los diseños, simplemente seguí adelante y pirateé un código juntos, ignorando completamente todas las cosas buenas que aprendiste sobre un buen diseño. Obtuve la función trabajando en unos 45 minutos. Luego volví, miré mi código y lo refactoricé en algo sólido y algo que no me avergonzaría de comprobar en el control de la fuente. La parte divertida es que después de que el truco funcionó, surgió "
Otra cosa que recomendaría específicamente para los problemas que enfrenta ahora (es decir, una tarea grande y compleja que se avecina). En lugar de hacer las cosas en serie, hazlas en paralelo. Divide tu día en pedazos donde investigas y luego detente, cambia de marcha y codifica por un tiempo, al menos en partes del proyecto que no son incógnitas completas. De esta manera, permanecer cerca del código le dará una mejor perspectiva y no se agotará al intentar absorber demasiada información demasiado rápido. Al menos para mí, después de algunas horas de investigación, es bueno dejar que el cerebro digiera cosas, cambie de tareas y haga algo más por un tiempo. Luego regrese a más investigación.
fuente
Hay ciertas decisiones que deben tomarse con anticipación.
¿Estás haciendo una aplicación web? Entonces necesita saber cómo se verá la arquitectura general. Las arquitecturas como MVC ya definen cuáles serán sus grandes piezas funcionales (como enrutamiento, controladores, modelos, capas de servicio, protocolos de comunicación, etc.); inventar todo eso desde cero será un largo recorrido, innecesario y probablemente inferior al que ya se ha inventado.
¿Estás escribiendo algún tipo de aplicación que implique colecciones de objetos o datos? Entonces necesitará saber qué tipos de estructuras de datos son más apropiadas para su escenario particular y cuáles son sus características de rendimiento. ¿Necesita un tiempo de búsqueda rápido? ¿Qué tal conjuntos de datos ordenados? ¿Lo hará una colección en memoria o necesita algo más industrial como una base de datos? No puede comenzar a codificar sin pensar en estas decisiones, porque si toma la decisión equivocada, tendrá que comenzar de nuevo.
Dicho esto, una vez que se toman las decisiones tecnológicas, tienes libertad dentro del marco que has establecido. El objetivo es permanecer flexible, iterativo y (me atrevo a decir) lo suficientemente ágil como para que cuando el cliente cambie de opinión sobre lo que quiere, pueda acomodarlos con un mínimo de alboroto.
¿Cómo haces eso? Experiencia, principalmente. Como alguien dijo una vez, la experiencia es lo que obtienes justo después de que la necesitas. Pero si sigue las decisiones de diseño exitosas de otros (como se plasma en las plataformas, bibliotecas y otras herramientas del oficio), puede aprender de ellas y reducir su riesgo.
fuente
No los veo como mutuamente excluyentes.
Al igual que cualquier tipo de gestión de proyectos, necesita una visión a largo plazo y objetivos a corto plazo.
Sin la primera, terminarás perdiendo el tiempo, por ejemplo, en funciones que ni siquiera se pueden usar, y sin la última pasarás todo el día considerando cómo crear la aplicación perfecta sin terminar tu proyecto.
Con qué frecuencia liberas / etc. depende de la metodología específica que esté utilizando.
Lo que tiene que investigar depende de lo que sabe versus de lo que no se siente cómodo.
fuente
La "iteración" y la "reflexión" no son contradictorias, sino complementarias.
Incluso en sus extremos, reflejan dos caminos para llegar al mismo lugar.
Debe comprender el dominio y el problema antes de comenzar a codificar. Esta es la parte de "piénsalo bien". Idealmente, verá el camino de alto nivel de principio a fin sobre cómo resolver el problema.
Pero es posible que solo vea porciones importantes de ese camino, y ciertamente no todas las paradas en el camino. Ahí es donde entra en juego la iteración. Puede comenzar a iterar a través de las versiones de la aplicación y buscar comentarios para:
La raíz latina de decide significa "cortar". La iteración le permite decidir qué funciona en la práctica en lugar de solo la teoría y la iteración le permite eliminar las otras opciones que no son factibles.
Por lo tanto, debe pensar detenidamente el problema para comprender lo que va a hacer. Pero luego debe iterar a través de las versiones de la aplicación para transformar realmente la idea en código real.
fuente
Mi regla general: si no comprende completamente ninguna parte del problema, debe retroceder y pensarlo completamente (incluyo la creación de prototipos y el código desechable para comprender las API, etc., como parte de "pensarlo") . Si es básicamente una colección de problemas que ha resuelto antes y solo necesita encontrar la mejor manera de encajar todo en esta instancia en particular, luego repita.
Honestamente, sin embargo, esa no es una regla difícil y rápida. Realmente creo que necesitas hacer una combinación de ambos para cualquier proyecto. La cantidad de cada uno que haga probablemente dependerá principalmente de qué tan cerca esté el proyecto de uno que ya ha completado en el pasado.
fuente