Hola a todos. Esto es un poco off topic, pero quizás a algunos de acá les puede interesar. Estaba leyendo este post: http://tagide.com/blog/2011/05/programming-is-math-apparently/ que reflexiona (o se cuestiona, mejor dicho) un poco sobre el tipo de competencias de programación que hay últimamente. Aparentemente, la mayoría de las competencias son de las que se pide solución a problemas de indo algorítmico. Es esa la única dimensión donde se evalúa. M gustó la idea de pensar algún tipo de competencias de programación donde se premien otras cosas que existen en la programación. Por ejemplo: robustez del código, inteligibilidad, simpleza, etc.
Pensé en este esquema: Existen dos problemas, A y B. Ademas, para cada uno de estos problemas, dos particiones : A1 y A2, B1 y B2, tal que A1 intercecsión A2 distinta de vacía (digamos, no son disjuntas), y lo mismo para B1 y B2. A cada uno de los equipos (*) se les asigna otro equipo, que es su pareja fantasma (fantasma por que ellos no saben quien es su pareja, pero que las, las hay). Entonces, el equipo X tiene la pareja Y. Al equipo X se le da el problema A1, y al equipo Y se les da el problema B1. Luego de un determinado tiempo, al X se les da el problema B2 y la solución Y(B1). De la misma forma, al equipo Y se le da el problema A2 y la solución X(A1) (**). Los "entregables" serían: X(B2(Y(B1))) e Y(A2(X(A1))). Esto se hace con todas las parejas, y ganarían las parejas (no los grupos), que mejor hayan resuelto los problemas A y B. Sería importante que haya varias rondas para poder discriminar niveles. Creo que para que esto funcione, las parejas tendrían que ser mas o menos del mismo nivel. Esto no mide directamente cuestiones de las que había planteado (con relación al código), pero si de una forma indirecta. Si el código se entiende, es simple, y tiene tests, le facilita la vida al otro equipo, que tiene que seguir construyendo sobre eso. Por otro lado, eso que parece excesivamente rebuscado, se basa sobre los mismos principios por lo que uno haría las cosas de esa manera en la practica. Me parece que puede ser una síntesis interesante. Bueno, comentarios son bienvenidos :) saludos jb * pueden ser equipos de uno, pero programación y equipos se llevan bien, aparentemente ** Comentarios están prohibidos. -- " To be is to do " ( Socrates ) " To be or not to be " ( Shakespeare ) " To do is to be " ( Sartre ) " Do be do be do " ( Sinatra ) -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
