Boa noite irmãos!
No versículo anterior vimos a décima parte da tradução de “The Cathedral and the Bazaar”. Hoje veremos a décima primeira.
A Lei de Brooks é baseada na experiência de que os bugs tendem a se agrupar nas interfaces entre o código escrito por pessoas diferentes e que a sobrecarga de comunicação/coordenação em um projeto tende a aumentar com o número de interfaces entre os seres humanos. Assim, os problemas aumentam com o número de caminhos de comunicação entre os desenvolvedores, que se dimensionam como o quadrado do número de desenvolvedores (mais precisamente, de acordo com a fórmula N * (N – 1) / 2, onde N é o número de desenvolvedores).
A análise da lei de Brooks (e o medo resultante de grandes números em grupos de desenvolvimento) baseia-se em uma suposição oculta: que a estrutura de comunicação do projeto é necessariamente um gráfico completo, que todos falam com todos os outros. Mas em projetos de código aberto, os desenvolvedores do halo trabalham em subtarefas paralelas separáveis e interagem umas com as outras muito pouco; mudanças de código e relatórios de bugs são transmitidos através do grupo principal, e somente dentro desse pequeno núcleo nós pagamos a sobrecarga total de Brooks. [SU]
Existem ainda mais razões para o fato de que o relatório de bugs no nível do código fonte tende a ser muito eficiente. Eles se concentram no fato de que um único erro pode ter vários sintomas possíveis, manifestando-se de forma diferente, dependendo dos detalhes do padrão de uso e do ambiente do usuário. Esses erros tendem a ser exatamente o tipo de erros complexos e sutis (como erros de gerenciamento de memória dinâmica ou artefatos de janelas de interrupção não determinísticos) que são mais difíceis de reproduzir à vontade ou de análise estática, e que fazem mais para criar problemas de longo prazo no software.
Um testador que envia uma tentativa de caracterização em nível de código-fonte de tal bug de múltiplos sintomas (por exemplo, “Parece-me que há uma janela no sinal de manipulação perto da linha 1250” ou “Onde você está zerando esse buffer?”) pode dar um desenvolvedor, caso contrário, muito próximo ao código para vê-lo, a pista crítica para uma meia dúzia de sintomas disparatados. Em casos como esse, pode ser difícil ou até mesmo impossível saber qual comportamento inadequado visível externamente foi causado precisamente por qual bug – mas com versões frequentes, é desnecessário saber. Outros colaboradores provavelmente descobrirão rapidamente se o bug foi corrigido ou não. Em muitos casos, os relatórios de bugs no nível da fonte farão com que comportamentos inadequados sejam descartados sem nunca terem sido atribuídos a nenhuma correção específica.
Erros complexos de vários sintomas também tendem a ter vários caminhos de rastreamento de sintomas de superfície de volta ao erro real. Qual dos caminhos de rastreamento um determinado desenvolvedor ou testador pode perseguir pode depender das sutilezas do ambiente dessa pessoa, e pode muito bem mudar de uma maneira não obviamente determinista ao longo do tempo. De fato, cada desenvolvedor e testador testam um conjunto semi-aleatório do espaço de estados do programa ao procurar a etiologia de um sintoma. Quanto mais sutil e complexo for o erro, menos provável será que a habilidade seja capaz de garantir a relevância dessa amostra.
Para bugs simples e facilmente reproduzíveis, então, o realce estará no “semi” em vez do “aleatório”; habilidade de depurar e intimidade com o código e sua arquitetura será muito importante. Mas para bugs complexos, o realce estará no “aleatório”. Sob essas circunstâncias, muitas pessoas que executam rastreios serão muito mais eficazes do que algumas pessoas executando rastreios sequencialmente – mesmo que os poucos tenham um nível de habilidade médio muito maior.
Esse efeito será grandemente amplificado se a dificuldade de seguir trajetos de rastreio de diferentes sintomas superficiais de volta a um bug variar significativamente de uma maneira que não pode ser prevista observando os sintomas. Um único desenvolvedor que testar esses caminhos sequencialmente terá a mesma probabilidade de escolher um caminho de rastreamento difícil na primeira tentativa como um caminho fácil. Por outro lado, suponha que muitas pessoas estejam tentando traçar caminhos em paralelo enquanto fazem lançamentos rápidos. Então é provável que um deles encontre o caminho mais fácil imediatamente, e prenda o bug em um tempo muito mais curto. O mantenedor do projeto verá que, envie uma nova versão, e as outras pessoas que estiverem rastreando o mesmo bug poderão parar antes de terem passado muito tempo em seus rastreamentos mais difíceis [RJ].
[SU] É tentador, e não totalmente impreciso, ver a característica de organização núcleo-mais-halo de projetos de código aberto como um giro da Internet na própria recomendação de Brooks para resolver o problema da complexidade do N-quadrado, a organização “equipe cirúrgica” – mas as diferenças são significativas. A constelação de funções especializadas, como “bibliotecário de código”, que Brooks imaginou em torno do líder da equipe, realmente não existe; esses papéis são executados, em vez disso, por generalistas auxiliados por conjuntos de ferramentas um pouco mais poderosos do que os da época de Brooks. Além disso, a cultura de código aberto se apóia fortemente nas fortes tradições Unix de modularidade, APIs e ocultação de informações – nenhuma das quais eram elementos da prescrição de Brooks.
[RJ] O entrevistado que apontou para mim o efeito dos comprimentos de rastreios amplamente variáveis na dificuldade de caracterizar um bug especulou que a dificuldade do caminho- de rastreio para múltiplos sintomas do mesmo erro varia “exponencialmente” (o que eu considero significar em uma Distribuição de Gauss ou Poisson, e concordar parece muito plausível). Se for experimentalmente possível entender a forma dessa distribuição, isso seria um dado extremamente valioso. Partidas grandes de uma distribuição plana e de probabilidade igual de dificuldade de rastreio sugeririam que mesmo os desenvolvedores solo deveriam imitar a estratégia de bazar limitando o tempo que gastam em rastrear um determinado sintoma antes de mudar para outro. Persistência nem sempre pode ser uma virtude…
Fim da décima primeira parte. Amanhã a parte 12. Grande abraço!
