Bom dia amigos!
No último versículo vimos a nona parte de “The Cathedral and the Bazaar”. Hoje vemos a décima.
Quantos Globos Oculares Domam a Complexidade
Uma coisa é observar que o estilo do bazar acelera a depuração e a evolução do código. Outra é entender exatamente como e por que isso acontece no nível micro do comportamento do desenvolvedor e testador do dia-a-dia. Nesta seção (escrita três anos depois do artigo original, usando insights de desenvolvedores que leram e reexaminaram seu próprio comportamento), vamos dar uma boa olhada nos mecanismos reais. Leitores não tecnicamente inclinados podem pular com segurança para a próxima seção.
Uma chave para o entendimento é perceber exatamente por que é que o tipo de relatório de bug que os usuários que não conhecem o código normalmente entregam tende a não ser muito útil. Usuários que não conhecem o código tendem a relatar apenas sintomas de superfície; eles subestimam o ambiente, então eles (a) omitem dados históricos críticos e (b) raramente incluem uma receita confiável para reproduzir o bug.
O problema subjacente aqui é um descompasso entre os modelos mentais do programa do testador e do desenvolvedor; o testador, do lado de fora olhando para dentro, e o desenvolvedor do lado de dentro olhando para fora. No desenvolvimento de código fechado, ambos estão presos a esses papéis e tendem a falar uns com os outros e a se encontrar profundamente frustrados.
O desenvolvimento de código aberto quebra essa ligação, tornando muito mais fácil para o testador e o desenvolvedor desenvolverem uma representação compartilhada com base no código-fonte real e se comunicar efetivamente sobre isso. Praticamente, há uma enorme diferença na alavancagem para o desenvolvedor entre o tipo de relatório de bug que apenas relata sintomas visíveis externamente e o tipo que se liga diretamente à representação mental do programa baseada no código-fonte do desenvolvedor.
A maioria dos bugs, na maioria das vezes, é facilmente fixada, mesmo com uma caracterização incompleta, mas sugestiva, de suas condições de erro no nível do código-fonte. Quando alguém entre seus beta-testers pode apontar, “há um problema de limite na linha nnn”, ou apenas “nas condições X, Y e Z, essa variável rola”, uma rápida olhada no código ofensivo geralmente é suficiente para fixar o modo exato de falha e gerar uma correção.
Assim, a conscientização do código-fonte por ambas as partes aumenta muito a boa comunicação e a sinergia entre o que o beta-tester reporta e o que o desenvolvedor (es) principal (is) conhece. Por sua vez, isso significa que o tempo dos desenvolvedores do núcleo tende a ser bem conservado, mesmo com muitos colaboradores.
Outra característica do método de código aberto que conserva o tempo do desenvolvedor é a estrutura de comunicação de projetos típicos de código aberto. Acima eu usei o termo “desenvolvedor principal”; isso reflete uma distinção entre o núcleo do projeto (geralmente muito pequeno; um desenvolvedor central único é comum e um a três é típico) e o halo de projeto dos testadores beta e colaboradores disponíveis (que geralmente chegam às centenas).
O problema fundamental que a organização tradicional de desenvolvimento de software aborda é a Lei de Brook: “Adicionar mais programadores a um projeto atrasado torna-o mais atrasado”. De maneira mais geral, a Lei de Brooks prevê que os custos de complexidade e comunicação de um projeto aumentam com o quadrado do número de desenvolvedores, enquanto o trabalho feito sobe apenas linearmente.
Fechamos a parte de número 10. Amanhã a décima primeira. Abraços!
