Cómo reconocer y abordar problemas en programación

[César Krall]

Cuestión planteada por Enryrigdane:

Hola Cesar por el momento agradecido y satisfecho por el curso, lo siguiente seria la cuestion de los problemas con resolucion intuida, directa,etc. En base a esto ¿cuales utilizariamos en programacion? ¿y como puedo aprender a identificar bien a que tipo de resolucion pertenece cada problema?
Saludos.

[César Krall]

Trato de responder a lo planteado.

La clasificación de problemas de programación se puede hacer de muchas maneras.

Una de ellas se basa en clasificar la estrategia algorítmica que se usa (voraz, divide y vencerás, vuelta atrás, etc.), otras distinguen soluciones recursivas e iterativas, etc.

La clasificación que se plantea en el curso (en problemas de resolución directa, problemas con resolución documentada, problemas con iteración para búsqueda de soluciones, problemas a plantear con una tabla de decisión o problemas con resolución intuida pero método paso a paso a determinar) no es tanto una clasificación exacta como una orientación para que la persona que se enfrenta a un problema trate de clasificarlo de forma orientativa.

En programación utilizamos todas esas formas de resolver problemas.

¿Cómo aprender a identificar bien a qué tipo de resolución pertenece cada problema?

Cito algo que es parte del curso: "nos basamos en una clasificación práctica (o de base subjetiva): lo que para algunos es resolución directa, para otros puede ser resolución documentada. Igualmente la resolución intuida para algunas personas puede ser resolución directa o documentada para otras... No se trata de acotar de qué tipo es un problema desde el punto de vista científico: el objetivo es que cada uno sepamos identificar los problemas, conocerlos, y saber establecer estrategias para su resolución."

De lo que se trata, al fin y al cabo, es que antes de ponernos delante del ordenador a hacer algo hayamos reflexionado sobre lo que vamos a hacer.

Supongamos que el programador es un albañil al que se le plantea:

"Haz un edificio de una habitación con el techo plano" --> Lo puede hacer directamente (resolución directa)
"Haz un edificio con un techo a 4 aguas de estilo achinado" --> Quizás necesite ver alguna documentación para hacerlo bien (resolución documentada)
"Haz un edificio y vete dándole distintas formas al techo hasta que se obtenga una forma asimétrica que recuerde una estrella" --> Tendrá que ir repitiendo (resolución iterativa)
"Haz un edificio que si da el sol desde el sur, reduzca la luminosidad, si da el sol en vertical impida la entrada de luz, si da la luz de la luna permita el paso total de luz, si da..." --> Podría usar tablas para reflejar las posibilidades (resolución con tablas de decisión)
"Haz un edificio con techo de bóveda y deja escrito cómo lo hiciste" --> Quizás sepa lo que es el techo de bóveda y cómo hacerlo, pero no tenga del todo claro cómo construirlo paso a paso (resolución intuida pero método paso a paso a determinar)

En resumen: a medida que se vaya teniendo práctica como programador se irá sabiendo cómo abordar los problemas, no te preocupes ahora demasiado por esto. Lo que sí es importante es tener claro que antes de abordar un problema hay que reflexionar sobre él. Saludos.

[Enryrigdane]

wow no pues mas claro ni el agua la verdad es que tienes madera para la docencia Cesar jeje y pues como dices y bien es cierto sobre la marcha es como puede uno aprender a abordar problemas, bueno continuare con el curso ya que desde la primera vez que entre a esta pagina me parecio interesante.
Saludos.

[chévere]

Hola a todos. César, he visto que te refieres a estrategias algorítmicas y hablas de "voraz", "divide y vencerás", "vuelta atrás" ¿A qué te refieres con esto? Por lo que he visto en curso de bases de la programación lo único que me suena es el divide y vencerás.

[César Krall]

Hola, lo primero de todo dar las gracias a Enryrigdane por sus palabras de elogio. No me considero un experto, pero sí trato de ser lo más didáctico posible (es una política general que mantenemos en aprenderaprogramar.com) porque cuando se está aprendiendo algo es frustrante solo encontrar explicaciones complicadas y farragosas. Por tanto agradezco a todos que de vez en cuando vayan valorando si las explicaciones son útiles. Y por otro lado, también se agradece que se diga cuándo no son útiles para tratar de hacer la explicación de otra manera.

En relación a lo que plantea chévere, las clasificaciones de algoritmos tratan de reflejar distintas estrategias para resolver un problema. Por ejemplo, supongamos que en vez de programadores fuéramos "demoledores" que nos dedicamos a demoler cosas. Entonces tendríamos que estudiar qué es lo que vamos a demoler (el programa) y aplicar una estrategia distinta según lo que queremos hacer. Por ejemplo, para demoler un muro podríamos plantearnos ir tirando trozos de muro con la pala de una máquina excavadora. Otra opción sería poner una carga explosiva y tratar de volarlo de una sola vez. Otra opción sería hacer un agujero en la base del muro, dejar los cimientos al descubierto y luego empujarlo hasta que cayera...
En programación también tenemos distintas estrategias. Lo que pasa con la clasificación de voraces, vuelta atrás, etc. es que es una clasificación un poco más avanzada y yo creo que en el curso no se entra en esto porque se trata de ir a lo más didáctico. Por tanto dentro de un curso básico yo me preocuparía de las cosas básicas. Ya habrá tiempo de complicarse con cosas avanzadas.

[chévere]

Pero ¿esa otra clasificación se explica en otro curso?

[César Krall]

De momento que yo sepa no; supongo que más adelante se incluirá dentro de algún curso de tipo avanzado.