Entendendo códigos-fonte: A missão

Para compreender um programa, primeiro temos que responder à questão: o quê diabos faz este programa ?

Pois bem, este é um excelente exercício que podemos nos habituar a fazer. O quê é o postgreSQL ? O que é o Samba ? E por aí vai.

Vamos pegar o PostgreSQL como exemplo: o que é o PostgreSQL ? A resposta mais rápida seria: "é um banco de dados". Embora isto seja o começo de tudo, esta resposta não estará completa sem antes listarmos todas as características que o compõe. Lembrando que características são itens mensuráveis, e não gostos, opiniões ou declarações variáveis com o tempo: "é o banco de dados mais rápido do mundo" não vale, pois mesmo mensurável, é variável com o tempo.

Missão do PostgreSQL
Considerando a versão 9.0, posso definir a "missão" do PostgreSQL como:

* é um SGBD (relacional, OLTP)
* trabalha no padrão SQL-95
* suporta transações (ACID, suporte à sub-transações - 'savepoints')
* suporta concorrência (MVCC)
* acesso é via rede tcp ou pipe de arquivo
* possui controle de permissões de acesso
* suporta replicação
* suporta integridade referencial (chaves primárias / estrangeiras)
* suporta "stored procedures" (linguagens modulares)
* suporta funções (do sistema, do usuário, funções anônimas)
* suporta visões (views não-materializadas)
* suporta gatilhos ('hooks' ativados por eventos)
* possui um sistema de mensagens (LISTEN/NOTIFY)
* suporte ao modelo híbrido objeto-relacional (SGBDOR, herança de tabelas)
* fortemente tipado
* multi-linguagem (BDs possuem um 'charset', 'collations')

Note que não existe definições corretas ou erradas (a menos que tenha uma informação falsa) - a "missão" de um programa é algo que deve ser feito para ser jogado fora. Serve apenas no momento em que está se montando a idéia do "quê" é o programa. Sua estrutura é algo estritamente pessoal. Eu por exemplo gosto de agrupar cada palavra-conceito do programa em características.

Valores
Adicionalmente, gosto de colocar a "filosofia" do programa - isto é, as características não-mensuráveis que servem para guiar o desenvolvimento dele - seus valores. No caso do PostgreSQL, segundo minhas constatações são:

* 1. estabilidade
* 2. baixa manutenção
* 3. segurança (pg_hba, grant, controle de usuários - owner/ACL, wal, PITR, 2PC, savepoints, hot/warm/cold/standby backup, logs, fsync, substituição de variáveis /set, RADIUS/LDAP)
* 4. velocidade (índices, fts, cluster (ordenação física), tablespaces, configurações postgresql.conf, shared buffers, vacuum/autovacuum - visibility map, toast, otimizador de querys, GEQO, explain, cost, fsync, cache (count e índices), heap only tuples - HOT, Copy vs INSERT, substituição de variáveis /set, estatísticas)
* 5. multi-plataforma: SO e arquitetura

Exercite sua mente
Tudo isto foi apenas um exercício mental. Brinque bastante de dizer qual a missão de um programa: o quê é e quais são suas características. Afinal, qual a missão do Windows 7, do Windows explorer, do Firefox, ... ?

Faça seu código voar

Uma tarefa cotidiana na vida de todo programador é ter que otimizar um código para velocidade. Afinal, a falta de velocidade até um certo ponto torna um programa inaceitável e acima do mesmo ponto, torna-se um atrativo poderoso. Porém, na medida que otimizamos para velocidade percebemos que o código vai se tornando ilegível, de difícil manutenção. Assim, ao otimizar, devemos optar por um conjunto de alterações que alcance nosso objetivo, mas que tenha o menor impacto nas demais características. Você não vai querer fugir da ira dos usuários para cair na ira dos programadores.

Otimização = antônimo de legibilidade
Quanto mais otimizamos, mais detalhistas temos que ser no código - temos que controlar cada detalhe - e como já vimos, quanto maior o nível de detalhe, menor é nossa visibilidade. É como ser uma formiga no meio de um campo de futebol e ter que dizer se um meio de campo é maior que outro. É como tentar entender a geologia do mundo olhando os seus grãos de areia. É como ..., bem acho que já entenderam.

Não faça "economia porca"
Normalmente 99% do tempo de execução de um programa é executado por um trecho de 1% do fonte ! Ok, estou exagerando, mas a regra é esta: apenas uma fração do seu código é responsável por quase todo o tempo de processo. Logo, só precisamos otimizar um pequeno pedaço, mantendo a legibilidade do resto do código. Isto é, só atacamos os gargalos - não é necessário deixar o código totalmente ilegível, mas apenas o que consome mais tempo:  funções rápidas que são acessadas muitas vezes, ou funções lentas acessadas poucas vezes.

Ponderação
Por fim, devemos sempre pesar se a ilegibilidade causada pela otimização não vai dificultar ou deixar mais lento as manutenções no fonte, os progressos e participação de novos programadores, se não irá aumentar o número de bugs, etc. Se o mote do projeto é ser "o mais rápido do mundo", então faça - mas fique sabendo o impacto que isto pode causar.

Entendendo códigos-fonte alheios

Quem já não teve dificuldades em entender o código-fonte escrito por outra pessoa ? Pior é quando temos que dar manutenção no código e aí não basta apenas entender, temos que entender muito bem. E quando é nosso próprio código, escrito há meses atrás, que não entendemos - aí chega a ser constrangedor. Mas por quê esta dificuldade ?

Visão Micro x Visão Macro
Imagine-se no meio de um campo de futebol. Olhando para o chão você vê a linha branca que delimita o meio de campo. Você olha para um lado e para o outro e tudo parece certo. Você consegue dizer se esta linha está torta ? Se ela realmente divide o campo ao meio ? Se uma das metades do campo não está maior que a outra ? Difícil. Agora vá para um ponto bem alto na arquibancada e você conseguirá ver o que está errado. Melhor, pegue um helicóptero, veja o campo de cima e... voilá, você terá a nítida noção se está tudo correto e poderá inclusive orientar a equipe de manutenção para corrigir os problemas. Agora, vamos considerar as folhas como o item mais elementar de um gramado de futebol, e que estas podem ser branca (pintada, formando as linhas) ou verde, conseguiríamos responder às questões acima olhando uma a uma com uma lupa ? Agora imagine uma foto ampliada 1 bilhão de vezes. Você consegue dizer a cor dos olhos da pessoa ? Você consegue dizer se há uma pessoa ? Acho que não.

 

Micro = implementação
Ocorre que quanto mais micro é nossa visão, quanto mais próximos estamos dos itens elementares, mais dificuldade temos em entender o todo. As coisas tornam-se tão micro, tão indivisíveis que é impossível fazer uma análise, que por definição significa dividir, decompor. Qualquer análise deve partir do ponto mais macro e ir dividindo até chegar ao ponto mais indivisível.
    Ao analisar um livro, partimos da idéia geral e vamos dividindo em capítulos, parágrafos, frases, palavras. Não é possível entender apenas olhando as palavras. O autor pode expressar suas idéias de várias formas. As sequencias de palavras são apenas uma forma que ele arranjou de implementar sua idéia. É possível então alterar as palavras sem perder a idéia geral. É possível passar o livro para outro idioma sem perder a idéia geral, assim como podemos trocar cada capim de posição que ninguém notará a diferença.
    Se olharmos para o gramado com uma lupa, folha por folha, estaremos tão perdidos que nem saberemos se estamos dentro ou fora do gramado. Não conseguiremos nem dizer se é um gramado de futebol ou de rugby. O mesmo é com um código-fonte: não é possível analisá-lo olhando linha por linha. É preciso fazer uma síntese - criando uma idéia macro, para depois analisarmos.
    A visão micro nos diz como uma idéia macro foi implementada, mas existem várias formas de implementar uma idéia. Olhe estas duas expressões: “2 + 2 = 4”, “3 + 1 = 4”. As duas expressões produzem o mesmo resultado (macro), mas tem seus elementos (micro) totalmente diferentes. Porém só a partir da visão macro (R=4) é que podemos discutir e implementar de formas diferentes.

Não analise um fonte, sintetize-o
Um fonte é o nível mais indivisível de uma idéia - você não pode analisá-lo. Quando alguém olha um código e modifica, está fazendo (mesmo que inconscientemente) uma síntese, e depois uma análise. Se dispomos apenas do micro, então temos que fazer uma síntese para fazer uma análise. Tudo que é análise é assim: processos de uma empresa, música, livros, fontes, etc. O “micro” é apenas uma implementação do “macro”.
Faça e execute um “Olá mundo” em “ASP + IIS + Win” e outro em “PHP + Apache + Linux”. Se olharmos para as instruções do processador, veremos que são totalmente diferentes, mas embora os resultados sejam iguais.

Mapeamento do programa Em resumo: o “micro”, a implementação, o fonte em si é supérfluo e não é analisando ele que você entenderá o código ou conseguirá discutí-lo. Faça antes uma síntese: qual a missão deste programa / quais são as características que o definem (missão) ? Quais os serviços que ele dispõe para alcançar sua missão (serviços) ? Quais os macroprocessos de cada serviço ? Quais os processos de cada macroprocesso ? Quais os subprocessos de cada processo ? Quais as atividades que compõe cada subprocesso ? Escreva estes 6 níveis e você começará a entender o fonte, por mais complexo que ele seja.

Por quê as pessoas contribuem com o Postgres e com o Software-livre

 segue interessante post no blog do Momjian sobre o porquê de participar da comunidade de software-livre:

Na última semana houve uma pequena discussão filosófica na lista sobre o por quê das pessoas contribuirem com o Postgres e com projetos de software-livre (que definitivamente vale a pena ler). 

Acredito que o comentário mais profundo foi este:
 
"Trabalhar no PostgreSQL é uma aventura e uma experiência muito boa - é um grande aprendizado para mim. É algo para quem gosta de programar, para quem gosta de 'hackear' e não para aqueles que ficam no escritório somente por suas 8 horas. Além disto, eu uso o PostgreSQL no meu trabalho - assim, 'hackear' o PostgreSQL me dá um perfeito conhecimento, um perfeito contato com desenvolvedores, e eu ainda posso trabalhar junto com os melhores programadores do planeta. e eu posso criar algumas coisas boas. Provavelmente se eu trabalhasse em projetos comerciais poderia ganhar mais dinheiro - mas a vida é uma só e dinheiro, embora importante, não está no topo das minhas prioridades - a vida DEVE ser uma aventura ! "