Link para o artigo: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/bird2011dtm.pdf
Este texto é uma síntese de pontos interessantes abordados em mais detalhes no artigo.
No geral, o objetivo do artigo é explorar a relação entre o ownership de projetos de software com a qualidade e quantidade de erros de sistemas, buscando evidenciar os motivos e efeitos de se ter um grande número de contribuidores em um projeto.
Processos de ensino para desenvolvedores 'recém chegados' em projetos de software podem aumentar ou manter a qualidade de desenvolvimento de um software. De acordo com isso e detalhes quantitativos do artigo, é possível afirmar que a exposição de um SWE/SDE em um determinado componente de código é uma forma de ensino sobre o domínio e de como melhorar o conhecimento e habilidades técnicas de um time. Além de seguir os processos de aprendizado impostos pelo time, participar de tarefas simples, escrita de testes e shadowing com pessoas mais experientes no time também incrementam a qualidade dos sistemas e favorece um onboarding mais completo de desenvolvedores em projetos de software.
Além de um bom onboarding, há um fator saudável de knowledge-sharing. O conjunto de desenvolvedores que contribuem para um determinado componente de código determinam as práticas de semântica e design de código contido nesse componente. Dessa forma, mudanças e criações significativas nesses componentes devem ser compartilhados/documentados. Falhas de comunicação reduzem o contexto de terceiros sobre usos de um determinado sistema.
Segundo os estudos contidos no artigo, é possível afirmar também que componentes que possuem mais contribuidores estão mais suscetíveis a falhas e possuem uma qualidade deteriorada de código, dadas diferentes opiniões, contextos e construções lógicas. Componentes com muitos contribuidores também podem indicar que esses componentes são altamente requisitados por outros, e isso pode ser nomeado como "major-minor-dependency relationship", que basicamente diz que um desenvolvedor faz alterações pontuais em outros componentes (minor contributor em Bar.dll) para adequar o uso de um componente no qual ele possui mais propriedade (Foo.exe).
Em projetos onde a maior parte desses contribuidores são minor contributors (possuem menos de 5% de participação na base de código), é essencial ter uma análise mais criteriosa das alterações para garantir que a qualidade do código de um componente não seja degradada e que erros sejam mitigados.
Comentário solto:
Falhas de comunicação também é um ponto de atenção aqui. Se SWE/SDEs aplicarem pouca atenção ao time/componente, ele não terá o conhecimento para fazer alterações nesses componentes sem causar erros no decorrer do tempo, visto que não detém uma visão abrangente sobre o time/componente. Dessa forma, nota-se também que a baixa qualidade de sistemas e grande quantidades de erros não são apenas resultados de uma questão cultural, mas também de posicionamentos e atitudes individuais.
Top comments (0)