¿Cómo abordar algo complejo?

Question

¿Conoces esa parte particular de tu código que es esencial para el proyecto pero que probablemente llevará mucho tiempo hacerlo? ¿Alguna vez tiene la sensación de que prefiere trabajar en otra cosa (probablemente menos importante) o no codificar en absoluto en lugar de trabajar en esa parte? ¿Esa bestia que tratas de evitar y usas cada truco vago que conoces para retrasar su implementación inevitable?

Ahora, probablemente solo soy un vago, pero siempre he tenido que lidiar con un código como ese. Escribe algo que no tengo ganas de escribir (¡y es peor si lo haces por diversión y no te pagan!). Un sistema grande que llevará mucho tiempo llevarlo a una etapa en la que recupere cualquier resultado útil o indicación de que funciona. ¿Cómo comienzas a codificar algo así? La mayoría de la gente probablemente sugeriría dividir y conquistar y técnicas arquitectónicas similares, pero esto no se trata de cómo hacerlo; se trata de cómo empezar a hacerlo. ¿Cuáles son los primeros pasos que tomarías?

Answer 1

Te contaré una historia de un caso en el que esto me sucedió.

Quería implementar un nuevo algoritmo de decisión de tipo de marco para x264 que usara programación dinámica directa (el algoritmo de Viterbi). Pero iba a ser complicado, desordenado, feo, etc. Y realmente no quería hacerlo. Traté de empeñar el proyecto en Google Summer of Code, pero por algún tipo de terrible mala suerte, el único estudiante que tuvimos que simplemente abandonó su proyecto ... fue el estudiante que eligió ese proyecto.

Entonces, después de dos meses de quejarme y esquivarlo, finalmente pude trabajar en el algoritmo. Y así es como lo hice.

Primero, hablé con el otro desarrollador, que aparentemente ya tenía algunas ideas sobre cómo hacerlo. Lo hablamos y él me lo explicó hasta que entendí completamente el proceso desde un punto de vista algorítmico. Este es el primer paso de cualquier proyecto de este tipo: comprenda el algoritmo detrás de él tan bien que puede pseudocódigo todo.

Entonces, hablé con otro compañero de trabajo mío. Subimos a una pizarra y la dibujé hasta que él también la entendió. Al explicárselo a otra persona, gané comprensión. Este es el segundo paso: explicar el algoritmo a otra persona tan bien que ellos pueden seudocódigo. Esta es una emulación del proceso de programación, ya que la programación es una forma de "explicar" un algoritmo para la computadora.

Luego, escribí un prototipo simple de Java que usaba valores falsos arbitrarios para la función de costo y solo se usaba para probar la búsqueda de Viterbi. Lo terminé y lo comparé con una búsqueda exhaustiva: coincidía perfectamente. Mi programación dinámica fue correcta. Este es el tercer paso: escriba la forma más simple posible del algoritmo en el entorno más simple posible.

Luego lo porté a C, el idioma nativo de x264. Funcionó de nuevo. Este es el cuarto paso: transferir esa forma simple del algoritmo al entorno completo.

Luego, finalmente, reemplacé la función de costo falso por la real. Después de algunos arreglos y arreglos, funcionó. Este es el paso final: integrar el algoritmo completamente con el entorno.

Este proceso tardó apenas una semana, pero desde el punto de vista mío al comienzo del proyecto, fue completamente desalentador y ni siquiera pude comenzar, pero al dividirlo en un paso tan largo paso a paso, pude no solo hacerlo , pero hazlo mucho más rápido de lo que esperaba.

Y los beneficios fueron mucho más allá de x264; Ahora entiendo Viterbi tan a fondo que ahora puedo explicárselo a otros ... y esos otros pueden beneficiarse enormemente de ello. Por ejemplo, uno de los desarrolladores de ffmpeg está utilizando una adaptación de mi algoritmo y código para resolver de manera óptima un problema algo diferente: la ubicación óptima del encabezado en los archivos de audio.

Answer 2

Generalmente me encanta la parte grande y compleja. Son las partes que realmente extienden un desafío y me obligan a considerar cuidadosamente lo que estoy haciendo. Son todas las partes pequeñas y tediosas que no me gustan. Sin embargo, cuando se trata de hacer algo que he estado posponiendo, encuentro un simple consejo importante:

¡¡¡SOLO HAZLO !!!

En serio, una vez que comienza es mucho más fácil terminar. Siempre encuentro que pospongo las cosas hasta que las comienzo, y de repente me doy cuenta de que, ahora que he comenzado, no es tan malo como había imaginado, y ¡mira, ya casi está hecho!

Answer 3

Divide y vencerás no se trata solo de estructurar código, también funciona como un enfoque para hacer que un proyecto sea manejable conceptualmente. Si me resulta difícil comenzar un proyecto, casi siempre porque es demasiado grande y aterrador . Al dividirse en piezas conceptualmente manejables, se vuelve menos aterrador.

También creo en " viñetas de seguimiento " según lo descrito por los programadores pragmáticos. Reduzca el proyecto a la "prueba de concepto" absolutamente más simple posible de las partes centrales, p. sin interfaz de usuario, casos especiales, manejo de errores, etc. Quizás sean solo algunas rutinas centrales con pruebas unitarias asociadas. Con esto has conquistado las partes aterradoras y puedes construir desde el núcleo.

Básicamente, el truco para comenzar (al menos para mí) es: No comenzar en todo el proyecto. Comience en una parte pequeña (preferiblemente núcleo) y construya desde allí. Si todavía tengo dificultades para comenzar, es porque la pequeña parte que decidí todavía es demasiado grande, así que tengo que dividirla y reducirla aún más.

Answer 4

Estoy de acuerdo con usted en que muchas partes grandes e importantes de un software no son divertidas de escribir. Por lo general, comienzo mi día de desarrollo con algunas cosas más pequeñas, como agregar una función aquí o corregir un error allí. Cuando llega el momento, empiezo con la gran parte, pero cuando ya no puedo ver la cosa, hago algo diferente. Eso está bien si todavía haces todo a tiempo. Y recuerde que puede facilitar las cosas si habla con otras personas sobre esa bestia grande antes de hacerlo, mientras lo hace y después de haberlo hecho. Esto no solo liberará su mente, sino que también obtendrá la opinión de otras personas desde un punto de vista menos subjetivo. Planear esas cosas juntos también ayuda.

Answer 5

Divertido, soy al revés. Cuando empiezo a abordar un problema, primero voy por los grandes. El núcleo del problema suele ser lo que me interesa.

Si estoy haciendo un proyecto por mí mismo, generalmente no me molestaría en implementar todos los bits difusos alrededor de los bordes, por lo que nunca se hacen. Si estoy haciendo algo de verdad, eventualmente llego a todas las partes difusas, pero no es mi parte favorita.

Answer 6

Creo que hay dos problemas aquí.

Primero, en realidad está comenzando. Como dices, eso puede ser bastante complicado. Personalmente, solo comienzo en cualquier momento, solo para obtener algo en papel / pantalla. Probablemente estará mal y necesitará edición, pero, en general, es más fácil criticar que crear, incluso en su propio trabajo.

Luego está el proceso real de resolver problemas difíciles. Hay un gran libro llamado "Conceptual Blockbusting" que discute varias formas de abordar los problemas. Aprendí mucho sobre cómo abordo la resolución de problemas y mis puntos ciegos usando ese libro. Muy recomendable.

Answer 7

Intento establecer una metáfora de lo que el sistema está tratando de hacer. Siempre me siento más cómodo cuando puedo describir el comportamiento en términos de una metáfora.

Luego lo abordo desde un punto de vista de desarrollo basado en pruebas, es decir, comienzo a describir lo que el sistema necesita hacer configurando las pruebas que verificarán el comportamiento correcto.

HTH.

aplausos,

Rob

Answer 8

La parte más difícil del proyecto es pasar de no hacer nada a la primera línea. Simplemente poner cualquier cosa en papel inicia este proceso y es sorprendente lo rápido que puede fluir el resto desde aquí.

Soy fanático del " divide y vencerás " -type enfoque mí mismo.

Cuando hay una tarea grande en particular en un sistema que se cierne sobre mí, dejo la computadora, tomo un bolígrafo y papel, y divido la tarea en todos sus componentes lógicos y flujo de trabajo.

Luego tome cada una de estas tareas y divida las funciones / llamadas más básicas requeridas.

Luego puedo poner métodos de código auxiliar que creo que necesitaré. y darles cuerpo uno por uno. En este punto, cada una de estas "subtareas" no es más grande que las tareas de desarrollo más pequeñas que orbitan en el mismo proyecto, así que siéntase como una tarea mucho menos onerosa que se cierne sobre mí.

Answer 9

Por lo general, abordo este tipo de problemas en casa usando un bolígrafo y un trozo de papel. Me imagino el algoritmo y / o el flujo lógico y luego aplico (en el papel) las clases y los apéndices del método y cuando entro frente a la computadora, puedo hacerlo mucho más fácil ... Probablemente soy solo yo ...