domingo, marzo 27, 2005
Ensayos sobre "el código como diseño"
Encuentro uno ensayos muy interesantes de Jack W. Reeves sobre el código como diseño. Son viejos (el primero de 1992) pero no los conocía. Sólo he leído la carta al editor que envió el autor antes del primer ensayo, pero me he encontrado con unas cuantas ideas como mínimo thought provoking.
La primera es que el código es parte del diseño. En ese sentido, no existe programa sin diseño. Como dice el autor, "el diseño no es importante: es todo".
La segunda es que una de las formas de refinar el diseño son las pruebas y la depuración. Es decir, estos procesos no son parte de un sistema de calidad, sino parte del proceso del diseño. En ese sentido, el autor afirma que no debemos avergonzarnos de que la fase de pruebas y depuración lleve más del 50% del tiempo, porque en realidad lo que estamos haciendo es mejorar el diseño.
La razón, según el Reeves, por la que se utilizan las pruebas y la depuración como parte del diseño, en lugar de emplear modelos como se hace en otras disciplinas ingenieriles, es que resulta más rápido compilar el código y probarlo. La verdad es que aquí veo uno de sus puntos débiles.
También resulta interesante la parte en la que dice que cuando se hacen comparaciones con otras industrias como la hardware, la construcción de aviones o puentes diciendo que la informática tiene peores resultados, también ha habido procesadores con fallos y aviones y puentes que se caen por fallos de diseño. Sin embargo, me temo que no es tan habitual como en el software.
El autor tampoco dice que no se haga un diseño de alto nivel. Lo que dice es que ese diseño no se considere el único diseño y que no se considere acabado hasta que se haya hecho la codificación y las pruebas; es decir, el diseño de alto nivel no es más que un esquema, que puede ser necesario cambiar cuando se pruebe.
También parece estar en contra de las notaciones independientes del lenguaje de programación. Afirma que no reflejan ciertos aspectos y que en las traducciones entre distintas notaciones se pierden detalles importantes.
Como aspectos problemáticos de su enfoque "código como diseño", el autor apunta que los lenguajes de programación son difíciles de leer para los humanos; por otra parte, hay aspectos del espacio del problema que se reflejan en el código, pero no es fácil reconstruirlos del código directamente. Para esto está la documentación auxiliar, que es eso: documentación auxiliar y no el diseño en sí.
Uno de los motivos por los que el diseño tradicional en cascada falla es porque, en muchas ocasiones, son personas distintas las que hacen lo que se llama el diseño (el documento) y los que luego realizan la codificación (que en realidad también es diseño). Se supone que estos últimos son personas que necesitan menos experiencia, pero eso es en realidad no darse cuenta de la importancia de su trabajo y de que está ligado al diseño del software. Es decir, el problema es que se intenta hacer que el diseño y la codificación sean dos actividades distintas con distintas notaciones, productos y personas involucradas, con lo que al final se acaba con algo que no funciona.
Por lo visto estos ensayos han tenido bastante repercusión en las metodologías ágiles de desarrollo como Extreme Programming.
La primera es que el código es parte del diseño. En ese sentido, no existe programa sin diseño. Como dice el autor, "el diseño no es importante: es todo".
La segunda es que una de las formas de refinar el diseño son las pruebas y la depuración. Es decir, estos procesos no son parte de un sistema de calidad, sino parte del proceso del diseño. En ese sentido, el autor afirma que no debemos avergonzarnos de que la fase de pruebas y depuración lleve más del 50% del tiempo, porque en realidad lo que estamos haciendo es mejorar el diseño.
La razón, según el Reeves, por la que se utilizan las pruebas y la depuración como parte del diseño, en lugar de emplear modelos como se hace en otras disciplinas ingenieriles, es que resulta más rápido compilar el código y probarlo. La verdad es que aquí veo uno de sus puntos débiles.
También resulta interesante la parte en la que dice que cuando se hacen comparaciones con otras industrias como la hardware, la construcción de aviones o puentes diciendo que la informática tiene peores resultados, también ha habido procesadores con fallos y aviones y puentes que se caen por fallos de diseño. Sin embargo, me temo que no es tan habitual como en el software.
El autor tampoco dice que no se haga un diseño de alto nivel. Lo que dice es que ese diseño no se considere el único diseño y que no se considere acabado hasta que se haya hecho la codificación y las pruebas; es decir, el diseño de alto nivel no es más que un esquema, que puede ser necesario cambiar cuando se pruebe.
También parece estar en contra de las notaciones independientes del lenguaje de programación. Afirma que no reflejan ciertos aspectos y que en las traducciones entre distintas notaciones se pierden detalles importantes.
Como aspectos problemáticos de su enfoque "código como diseño", el autor apunta que los lenguajes de programación son difíciles de leer para los humanos; por otra parte, hay aspectos del espacio del problema que se reflejan en el código, pero no es fácil reconstruirlos del código directamente. Para esto está la documentación auxiliar, que es eso: documentación auxiliar y no el diseño en sí.
Uno de los motivos por los que el diseño tradicional en cascada falla es porque, en muchas ocasiones, son personas distintas las que hacen lo que se llama el diseño (el documento) y los que luego realizan la codificación (que en realidad también es diseño). Se supone que estos últimos son personas que necesitan menos experiencia, pero eso es en realidad no darse cuenta de la importancia de su trabajo y de que está ligado al diseño del software. Es decir, el problema es que se intenta hacer que el diseño y la codificación sean dos actividades distintas con distintas notaciones, productos y personas involucradas, con lo que al final se acaba con algo que no funciona.
Por lo visto estos ensayos han tenido bastante repercusión en las metodologías ágiles de desarrollo como Extreme Programming.
Comentarios:
Publicar un comentario
