Programação como Formação de Teoria (1985)

• O texto de Peter Naur, «Programming as Theory Building», vê a programação não como uma atividade de produzir texto de programa, mas como uma atividade em que o programador forma uma teoria sobre o problema e sua solução.
• Aqui, “teoria” não é apenas uma proposição abstrata ou uma explicação de projeto documentada.
  • É entender que significado um problema do mundo real tem
  • poder explicar como a estrutura do programa corresponde a essa realidade
  • justificar por que foi projetado daquela forma
  • e ser capaz de julgar como integrar novas exigências dentro da estrutura existente quando elas surgirem.
• Portanto, o conhecimento central de um programa não está totalmente contido no código ou na documentação, mas na cabeça do programador que entende aquele programa.

Programação e conhecimento

• Naur vê a programação como a atividade de mapear atividades do mundo real para manipulações formais de símbolos que um computador possa executar.
• Nessa perspectiva, modificar um programa também faz parte da programação.
  • Porque, se as atividades do mundo real mudam, o programa também precisa mudar.
• A essência da programação não são documentos nem artefatos de código, mas um tipo específico de conhecimento que os programadores acumulam.
• A documentação é importante, mas auxiliar.
  • A documentação não consegue substituir completamente a teoria.
  • Ela está mais próxima de uma ferramenta que ajuda na formação da teoria.

Caso 1: transferência de compilador e fracasso

• O grupo A criou um compilador para a linguagem L.
• O grupo B, para criar um compilador para a linguagem estendida L + M, recebeu do grupo A o código do compilador, a documentação e conselhos.
• Código e documentação foram fornecidos em quantidade suficiente, mas o grupo B, em algumas decisões de projeto, não conseguiu aproveitar a força da estrutura existente e propôs soluções em estilo remendo.
• O grupo A percebeu imediatamente o problema e apresentou uma solução mais simples e natural dentro da estrutura existente.
• O ponto central desse caso:
  • O texto do programa e a documentação, por si só, não transmitem a teoria profunda do projeto.
  • O “porquê” do projeto existente e “como ele deve ser estendido” não são transmitidos de forma suficiente apenas por documentação.
• Depois, quando outros programadores sem a orientação do grupo A modificaram o compilador, a estrutura originalmente forte foi sendo gradualmente enfraquecida por acréscimos amorfos.
• Isso mostra que texto de programa e documentação têm limites para preservar a teoria central de projeto.

Caso 2: sistema de tempo real de grande porte

• É apresentado o caso de um sistema industrial de tempo real com cerca de 200 mil linhas.
• Os programadores responsáveis pela instalação e pelo diagnóstico de falhas estavam ligados de perto ao sistema desde o início do projeto e por muito tempo.
• Ao diagnosticar falhas, eles dependiam principalmente da sua compreensão imediata do sistema e de código com comentários.
• Já programadores operadores externos, que haviam recebido documentação e treinamento, encontravam dificuldades repetidamente.
• Os programadores experientes do fabricante resolviam esses problemas com facilidade.
• Conclusão:
  • A manutenção e a modificação de programas grandes dependem essencialmente do conhecimento que têm as pessoas que permaneceram ligadas ao programa por muito tempo.
  • Explicações documentadas, sozinhas, não conseguem substituir totalmente esse conhecimento.

O conceito de “teoria” em Ryle

• Naur recorre ao conceito de teoria de Gilbert Ryle.
• Ter uma teoria não é simplesmente conhecer proposições.
  • É saber fazer algo
  • conseguir explicar esse algo
  • responder a perguntas
  • e justificar o próprio julgamento.
• Atividades inteligentes não podem necessariamente ser reduzidas a atividades de seguir regras.
  • Porque o próprio ato de seguir regras também precisa ser realizado de maneira inteligente.
  • Se dissermos que é preciso outra regra para saber como seguir a regra, surge uma regressão infinita.
• Portanto, atividade intelectual não é mera execução de regras, mas inclui a capacidade de perceber semelhanças entre situações e responder adequadamente.

A teoria não pode ser expressa completamente como regras

• Quem possui uma teoria reconhece semelhanças significativas entre várias situações do mundo real.
• Mas essas semelhanças são difíceis de expressar completamente em critérios ou regras claras.
• Exemplos:
  • semelhança entre rostos
  • semelhança entre melodias
  • semelhança entre sabores de vinho
• Da mesma forma, na programação também é difícil reduzir a regras simples a decisão sobre com o que uma nova exigência se parece dentro da estrutura existente e onde ela deve ser integrada.
• Esse ponto é o núcleo do conhecimento tácito.

A teoria que o programador precisa ter

• O programador que possui a teoria de um programa deve ser capaz de fazer o seguinte.

1. Ser capaz de explicar a correspondência entre o mundo real e o programa

• Deve ser capaz de explicar a que atividade ou conceito do mundo real corresponde cada parte do programa.
• E, em sentido inverso, também deve ser capaz de explicar como uma atividade do mundo real é representada dentro do programa.
• Para julgar o que é relevante e o que é irrelevante, é preciso compreender o mundo real como um todo.

2. Ser capaz de justificar por que o programa é como é

• Deve ser capaz de explicar por que a estrutura do programa e os detalhes da implementação foram projetados daquela forma.
• Essa justificação pode usar regras, raciocínio, princípios de projeto, estimativas quantitativas etc.
• Mas, no fim, decidir qual princípio aplicar depende da percepção direta do programador.

3. Ser capaz de responder construtivamente a novas demandas de modificação

• Deve ser capaz de reconhecer com que funcionalidade ou estrutura do programa existente uma nova exigência se parece.
• Com base nessa semelhança, deve conseguir projetar a modificação de modo que ela se integre naturalmente à teoria existente.
• Essa capacidade é difícil de substituir apenas com procedimentos documentados.

Modificação de programas e custo

• Software inevitavelmente é modificado.
  • Porque surgem novas exigências durante o uso
  • e porque as condições do mundo real também mudam.
• Costuma-se pensar que modificar um programa existente sai mais barato do que criar um novo.
• Mas, na perspectiva de Naur, essa expectativa nem sempre é válida.
• O custo de modificar um programa não é o custo de editar texto.
  • O custo principal está em compreender a teoria do programa existente
  • e integrar a nova exigência dentro dessa teoria.
• Portanto, o simples fato de código ser um texto fácil de editar não significa que modificá-lo seja fácil.

Os limites da flexibilidade

• A ideia de inserir previamente flexibilidade no programa para mudanças futuras é válida apenas em parte.
• Flexibilidade não é gratuita.
  • É preciso decidir para quais situações futuras se preparar
  • projetar parâmetros e estruturas
  • e arcar com custos de implementação, teste e explicação.
• Sua utilidade depende de eventos futuros incertos.
• Portanto, flexibilidade não pode ser uma solução geral para lidar com mudanças.
• O importante não é inserir de antemão uma estrutura preparada para toda mudança, mas ter a capacidade de julgar adequadamente, com base na teoria do programa, quando a mudança chegar.

Boas modificações e más modificações

• A mesma modificação, satisfazendo o mesmo comportamento externo, pode ser implementada de várias maneiras.
• Na superfície, todas podem parecer corretas.
• Mas, do ponto de vista da teoria do programa, a diferença é grande.
  • Algumas modificações estendem naturalmente a teoria existente.
  • Outras funcionam como remendos acrescentados sobre a estrutura já existente.
• Quando esse segundo tipo de modificação se repete, o programa vai se tornando cada vez mais uma colcha de retalhos.
• A viabilidade de longo prazo de um programa depende de quão bem cada modificação cria raízes na teoria existente.

Vida, morte e ressurreição de um programa

Vida de um programa

• Um programa está vivo quando os programadores que possuem sua teoria ainda o controlam ativamente.
• Eles conseguem responder intelectualmente às demandas de modificação.

Morte de um programa

• Quando a equipe que possui a teoria do programa se desfaz, o programa morre.
• Um programa morto ainda pode continuar executando e produzindo resultados úteis.
• Mas sua morte se revela quando ele já não consegue responder adequadamente às demandas de modificação.

Ressurreição de um programa

• É a tentativa de uma nova equipe de reconstruir a teoria do programa existente.
• Naur considera que isso é impossível em sentido estrito.
• Porque apenas com documentação e código não se pode restaurar completamente a teoria que a equipe original possuía.
• Mesmo quando a ressurreição é possível, ela tende a ser cara e difícil, com grande chance de gerar uma teoria diferente da original.
• Em alguns casos, pode ser melhor e mais barato para a nova equipe resolver o problema de novo do que salvar o código existente.

Crítica às metodologias

• Naur vê metodologias de programação como “conjuntos de regras que definem em que ordem e que trabalho o programador deve fazer”.
• Na perspectiva da formação de teoria, metodologias nesse sentido não capturam a essência da programação.
• Razões:
  • A formação de teoria não tem uma ordem fixa.
  • A teoria, por natureza, não é uma combinação linear de partes.
  • Notações ou formatos de documentação podem ajudar a formar a teoria, mas não são a teoria em si.
• Portanto, chega-se à conclusão de que não existe um método universalmente correto para a atividade primária da programação.

Isso não significa que metodologias sejam totalmente sem valor

• O que Naur rejeita é a metodologia como procedimento que garantiria mecanicamente um bom projeto.
• Metodologias, técnicas de projeto, notações e técnicas de verificação podem ter valor educacional.
• Programadores familiarizados com bons exemplos, princípios de estruturação e técnicas de verificação têm mais chance de formar teorias melhores.
• Mas decidir qual técnica aplicar, quando aplicá-la e em que ordem deve ficar a cargo do julgamento do programador que compreendeu o problema real.

O status do programador

• Quando se vê a programação como produção industrial, o programador é tratado como uma peça substituível.
• É a visão segundo a qual, seguindo procedimentos e regras, qualquer pessoa pode produzir o mesmo resultado.
• Naur rejeita essa visão.
• Se o produto central de um programa é a teoria que o programador possui, então o programador não é um trabalhador facilmente substituível.
• O programador está mais próximo de um profissional responsável por desenvolver e administrar, com responsabilidade, a atividade completa que inclui o computador.
• Portanto, o programador deve receber status e responsabilidade contínuos.
• A educação também deve ir além de gramática, notações e técnicas de processamento de dados, para desenvolver a capacidade de formação de teoria.

A metáfora do XP e a formação de teoria

• A “metáfora” do XP é bem explicada pela perspectiva de formação de teoria de Naur.
• Uma boa metáfora ajuda a equipe a fazer inferências semelhantes sobre a estrutura do programa.
• Exemplos:
  • entender o programa como uma “linha de montagem”
  • entender o programa como um “restaurante”
• Uma boa metáfora não é apenas uma analogia simples.
  • Ela ajuda os projetistas a julgar que estrutura devem esperar
  • onde novo código deve ser adicionado
  • e como ele deve se encaixar no código feito por outras pessoas.
• Quanto mais membros na equipe e mais trabalho paralelo houver, maior o valor de uma metáfora compartilhada.
• Sem uma teoria comum, cada programador cria sua própria teoria, e o sistema vai ficando cada vez mais inconsistente e complexo.

O papel da documentação

• É difícil para a documentação acompanhar completamente o estado atual do programa.
• Isso não significa que documentação seja desnecessária.
• O objetivo da documentação não é registrar tudo, mas ajudar o próximo programador a formar uma teoria adequada.
• Uma boa documentação estimula a memória e a experiência do leitor e abre o caminho para o raciocínio correto.
• Esse tipo de documentação sobrevive melhor do que documentos que apenas listam classes, funções e módulos atuais.

A composição de um bom documento de projeto

• Projetistas experientes normalmente começam a documentação com os seguintes itens.
  • a metáfora central
  • a explicação do propósito dos principais componentes
  • um diagrama das interações centrais entre os principais componentes
• Esses três elementos ajudam muito a próxima equipe a formar a teoria do projeto.
• O próprio código-fonte também é um meio de transmitir teoria.
  • nomenclatura consistente
  • estrutura simples
  • padrões previsíveis
  • minimização de exceções desnecessárias
• Grande parte do que se chama de “código limpo” está relacionada a quão facilmente o leitor consegue formar uma teoria coerente sobre o sistema.