- «Programming as Theory Building» de Peter Naur considera la programación no como una actividad de producir texto de programa, sino como una actividad en la que el programador forma una teoría sobre el problema y su solución.
- Aquí, “teoría” no es una simple proposición abstracta ni una explicación de diseño documentada.
- Es comprender qué significado tienen los problemas del mundo real
- poder explicar cómo la estructura del programa corresponde a esa realidad
- justificar por qué se diseñó de esa manera
- y poder juzgar cómo integrar nuevos requisitos dentro de la estructura existente cuando aparezcan.
- Por lo tanto, el conocimiento central de un programa no está contenido por completo en el código ni en la documentación, sino que está en la mente del programador que entiende ese programa.
Programación y conocimiento
- Naur ve la programación como la actividad de hacer corresponder actividades del mundo real con manipulaciones formales de símbolos que una computadora pueda ejecutar.
- Desde esta perspectiva, modificar un programa también es parte de programar.
- Porque si cambian las actividades del mundo real, el programa también debe cambiar.
- La esencia de la programación no son los documentos ni el código como productos, sino el conocimiento específico que los programadores van acumulando.
- La documentación es importante, pero secundaria.
- La documentación no puede reemplazar por completo la teoría.
- Se parece más a una herramienta que ayuda a formar la teoría.
Caso 1: transferencia de un compilador y fracaso
- El grupo A creó un compilador para el lenguaje L.
- El grupo B recibió el código del compilador de A, la documentación y consejos para crear un compilador para el lenguaje extendido L + M.
- Aunque se entregaron suficiente código y documentación, B no logró aprovechar la solidez de la estructura existente en varios puntos del diseño y propuso soluciones tipo parche.
- A detectó el problema de inmediato y propuso una solución más simple y natural dentro de la estructura existente.
- El punto central de este caso:
- Solo con el texto del programa y la documentación no se transmite la teoría profunda del diseño.
- El “por qué” del diseño existente y “cómo debe ampliarse” no se comunican suficientemente solo con documentación.
- Más tarde, cuando otros programadores sin la guía de A modificaron el compilador, la estructura originalmente sólida fue debilitándose poco a poco por añadidos amorfos.
- Esto muestra que el texto del programa y la documentación tienen límites para preservar la teoría central del diseño.
Caso 2: sistema grande de tiempo real
- Se presenta el caso de un sistema industrial de tiempo real de unas 200 mil líneas de código.
- Los programadores encargados de la instalación y del diagnóstico de fallas habían estado vinculados estrechamente al sistema durante mucho tiempo desde las primeras etapas del diseño.
- Al diagnosticar fallas, dependían sobre todo de su comprensión inmediata del sistema y del código comentado.
- En cambio, los programadores de operación externos que habían recibido documentación y capacitación tropezaban repetidamente con dificultades.
- Los programadores expertos del fabricante resolvían esos problemas con facilidad.
- Conclusión:
- El mantenimiento y la modificación de programas grandes dependen esencialmente del conocimiento que tienen las personas que han estado vinculadas al programa durante mucho tiempo.
- Las explicaciones documentadas por sí solas no pueden reemplazar por completo ese conocimiento.
El concepto de “teoría” en Ryle
- Naur retoma el concepto de teoría de Gilbert Ryle.
- Tener una teoría no significa simplemente conocer proposiciones.
- Es saber hacer algo
- poder explicarlo
- poder responder preguntas
- y poder justificar el propio juicio.
- La actividad inteligente no se reduce necesariamente a seguir reglas.
- Porque incluso seguir reglas debe hacerse de manera inteligente.
- Si para seguir reglas hiciera falta otra regla más, se produciría una regresión infinita.
- Por lo tanto, la actividad intelectual no es mera ejecución de reglas, sino que incluye la capacidad de captar similitudes entre situaciones y responder adecuadamente.
La teoría no puede expresarse por completo como reglas
- Una persona que tiene una teoría reconoce similitudes significativas entre distintas situaciones del mundo real.
- Pero esas similitudes difícilmente pueden expresarse por completo mediante criterios o reglas claras.
- Ejemplos:
- el parecido entre rostros
- la similitud entre melodías
- la similitud en el sabor del vino
- Del mismo modo, en programación también es difícil reducir a reglas simples cómo se parece un nuevo requerimiento a la estructura existente y en qué parte debe integrarse.
- Ese es el núcleo del conocimiento tácito.
La teoría que debe tener un programador
- Un programador que posee la teoría de un programa debe poder hacer lo siguiente.
1. Poder explicar la correspondencia entre el mundo real y el programa
- Debe poder explicar a qué actividad o concepto del mundo real corresponde cada parte del programa.
- Y a la inversa, también debe poder explicar cómo se representa dentro del programa cierta actividad del mundo real.
- Para juzgar qué es relevante y qué no lo es, hace falta una comprensión del conjunto del mundo real.
2. Poder justificar por qué el programa es así
- Debe poder explicar por qué la estructura del programa y los detalles de implementación fueron diseñados de esa manera.
- Esta justificación puede usar reglas, razonamiento, principios de diseño, estimaciones cuantitativas, etc.
- Pero al final, decidir qué principio aplicar depende de la percepción directa del programador.
3. Poder responder de forma constructiva a nuevas solicitudes de cambio
- Debe poder reconocer a qué función o estructura del programa existente se parece un nuevo requerimiento.
- Con base en esa similitud, debe poder diseñar la modificación para que se integre de manera natural en la teoría existente.
- Esta capacidad es difícil de reemplazar únicamente con procedimientos documentados.
Modificación de programas y costo
- El software inevitablemente se modifica.
- Porque durante su uso surgen nuevos requisitos
- y porque también cambian las condiciones del mundo real.
- A menudo se piensa que modificar un programa existente es más barato que crear uno nuevo.
- Sin embargo, desde la perspectiva de Naur, esa expectativa no siempre es válida.
- El costo de modificar un programa no es el costo de editar texto.
- El costo central está en comprender la teoría del programa existente
- e integrar el nuevo requerimiento dentro de esa teoría.
- Por eso, el simple hecho de que el código sea texto fácil de editar no permite afirmar que modificarlo sea fácil.
Los límites de la flexibilidad
- La idea de incorporar por adelantado flexibilidad en un programa para prepararlo para cambios futuros solo es válida parcialmente.
- La flexibilidad no es gratis.
- Hay que decidir para qué situaciones futuras prepararse
- diseñar parámetros y estructuras
- e incurrir en costos de implementación, pruebas y explicación.
- Su utilidad depende de eventos futuros inciertos.
- Por lo tanto, la flexibilidad no puede ser una solución general al cambio.
- Lo importante no es meter de antemano una estructura para todos los cambios posibles, sino la capacidad de juzgar adecuadamente, con base en la teoría del programa, cuando el cambio llegue.
Buenas y malas modificaciones
- Incluso modificaciones que satisfacen el mismo comportamiento externo pueden implementarse de varias formas.
- En la superficie, todas pueden parecer correctas.
- Pero desde la perspectiva de la teoría del programa, la diferencia es grande.
- Algunas modificaciones amplían de forma natural la teoría existente.
- Otras funcionan como parches agregados sobre la estructura existente.
- Si estas últimas se repiten, el programa se va convirtiendo poco a poco en un remiendo.
- La viabilidad a largo plazo de un programa depende de qué tan bien cada modificación eche raíces en la teoría existente.
La vida, muerte y resurrección de un programa
La vida de un programa
- Un programa está vivo cuando los programadores que poseen su teoría todavía lo controlan activamente.
- Ellos pueden responder intelectualmente a las solicitudes de cambio.
La muerte de un programa
- Cuando el equipo que posee la teoría del programa se desintegra, el programa muere.
- Un programa muerto puede seguir ejecutándose y producir resultados útiles.
- Pero su muerte se hace visible cuando ya no puede responder adecuadamente a las solicitudes de cambio.
La resurrección de un programa
- Es el intento de un nuevo equipo por reconstruir la teoría del programa existente.
- Naur considera que esto es imposible en sentido estricto.
- Porque ni la documentación ni el código bastan para restaurar por completo la teoría que tenía el equipo original.
- Aun si la resurrección es posible, es costosa y difícil, y es muy probable que produzca una teoría distinta de la original.
- En algunos casos, puede ser mejor y más barato que un nuevo equipo resuelva el problema desde cero en lugar de intentar salvar el código existente.
Crítica a las metodologías
- Naur entiende las metodologías de programación como “conjuntos de reglas que determinan en qué orden y qué tareas debe realizar un programador”.
- Desde la perspectiva de la formación de teoría, una metodología en ese sentido no logra captar la esencia de la programación.
- Razones:
- La formación de teoría no tiene un orden fijo.
- La teoría no es, en esencia, una combinación lineal de partes.
- La notación o los formatos de documentación pueden ayudar a formar teoría, pero no son la teoría misma.
- Por lo tanto, se concluye que no existe un método universalmente correcto para la actividad primaria de programar.
Esto no significa que la metodología sea totalmente inútil
- Lo que Naur rechaza es la metodología como procedimiento que garantiza mecánicamente un buen diseño.
- Las metodologías, técnicas de diseño, notaciones y técnicas de verificación pueden tener valor educativo.
- Un programador familiarizado con buenos casos, principios de estructuración y técnicas de verificación tiene más probabilidades de formar una mejor teoría.
- Pero decidir qué técnica aplicar, cuándo y en qué orden debe quedar en manos del juicio del programador que entendió el problema real.
El estatus del programador
- Si se ve la programación como producción industrial, el programador es tratado como una pieza reemplazable.
- Es la perspectiva según la cual, si se siguen procedimientos y reglas, cualquiera puede producir el mismo resultado.
- Naur rechaza esa visión.
- Si el producto central de un programa es la teoría que posee el programador, entonces el programador no es un trabajador fácilmente reemplazable.
- El programador se parece más a un profesional que desarrolla y gestiona con responsabilidad la actividad completa en la que está involucrada la computadora.
- Por lo tanto, al programador se le debe otorgar continuidad de estatus y responsabilidad.
- La educación también debe orientarse a desarrollar la capacidad de formar teoría, más allá de la simple gramática, notación y técnicas de procesamiento de datos.
La metáfora de XP y la formación de teoría
- La “metáfora” de XP se explica bien desde la perspectiva de la formación de teoría de Naur.
- Una buena metáfora ayuda a que el equipo haga suposiciones parecidas sobre la estructura del programa.
- Ejemplos:
- entender el programa como una “línea de ensamblaje”
- entender el programa como un “restaurante”
- Una buena metáfora no es una simple analogía.
- Ayuda a los diseñadores a juzgar qué estructura deberían esperar
- dónde deberían agregar código nuevo
- y cómo debería encajar con el código creado por otras personas.
- Cuantos más integrantes haya en el equipo y más trabajo en paralelo exista, mayor será el valor de una metáfora compartida.
- Sin una teoría común, cada programador construye su propia teoría y el sistema se vuelve cada vez más inconsistente y complejo.
El papel de la documentación
- Es difícil que la documentación alcance por completo el estado actual del programa.
- Eso no significa que la documentación sea innecesaria.
- El propósito de la documentación no es registrar todo, sino ayudar al siguiente programador a formar una teoría adecuada.
- Una buena documentación estimula la memoria y la experiencia del lector, y le abre el camino correcto de pensamiento.
- Ese tipo de documentación sobrevive más que una que solo enumera clases, funciones y módulos actuales.
Composición de un buen documento de diseño
- Los diseñadores con experiencia suelen empezar la documentación con los siguientes elementos.
- la metáfora central
- una explicación del propósito de los componentes principales
- un diagrama de las interacciones clave entre los componentes principales
- Estas tres cosas ayudan mucho al siguiente equipo a formar la teoría del diseño.
- El propio código fuente también es un medio para transmitir teoría.
- nombres consistentes
- estructura simple
- patrones predecibles
- minimización de excepciones innecesarias
- Gran parte de lo que llamamos “código limpio” está relacionado con qué tan fácilmente el lector puede formar una teoría consistente sobre el sistema.
Aún no hay comentarios.