Quanto esforço é necessário para manter um sistema de construção?

9

No Podcast StackExchange # 09 , é observado:

Outro estudo analisou recentemente quanto esforço é necessário para manter o sistema de compilação: 5 a 30% de todo o esforço de desenvolvimento é gasto na manutenção do sistema de compilação. Com as variações enormes, mesmo quando se trabalha em projetos semelhantes.

Qual o nome do estudo referenciado e onde ele pode ser encontrado? O áudio do podcast não contém mais detalhes.

Além disso, alguém tem links para outros estudos que abordam o mesmo tópico.

commandline-build-tool

— Neil Mitchell
fonte

3

Uau. Nunca me passou pela cabeça que uma loja pudesse gastar tanto tempo em um sistema de construção. Temos um sistema de compilação personalizado, feito à mão, que faz compilações noturnas de todas (20 algumas) ramificações (50 algumas) de desenvolvimento (se alterações foram confirmadas), inicia testes de unidade e para e inicia servidores de teste (um ou mais mais por lançamento e um ou mais para muitos ramos de desenvolvimento), envia resultados etc. No entanto, nos 4 anos em que estive neste empregador, acho que não gastamos muito mais do que duas semanas de trabalho nele e que inclui estender os recursos de nossa solução personalizada!

— Marjan Venema

É o que acontece quando as pessoas se referem a algo / alguém e se esqueça de adicionar as referências ...

— wleao

Não conhece o estudo, mas os resultados podem diferir dependendo do que você define "mantendo o sistema de construção". "A adição ou alteração de arquivos" faz parte disso? A configuração de um instalador faz parte da "manutenção do sistema de construção"?

— Doc Brown

1

Não ouvi o podcast, mas o estudo provavelmente é um artigo do ICSE mais recente , chamado "Um estudo empírico do esforço de manutenção da construção", de Shane McIntosh et al. Verifique o link direto (ou a página oficial do DOI, se você quiser metadados).

O estudo deles concentra-se principalmente na frequência com que as alterações no código-fonte afetam a compilação e quantos desenvolvedores de uma equipe geralmente se preocupam em manter a compilação. Lembro-me de que é um estudo interessante, mas achei os números um pouco difíceis de interpretar, como costuma ser o caso de estudos empíricos tentando encontrar conexões entre as coisas :)

— Deckard
fonte

2

Não tenho um link para você, mas falando por experiência pessoal, esse percentual varia de acordo com 2 pontos principais: 1) design e complexidade do sistema 2) e organização pessoal

Um sistema bem projetado exigirá um esforço mínimo de manutenção, mesmo que seja bastante complexo. Mas se sua equipe não for treinada e organizada adequadamente para lidar com o código, você provavelmente passará muito tempo consertando construções incorretas ou confirmações incorretas e coisas do tipo ...

No entanto, quando você tem um ambiente de desenvolvimento, perguntas e respostas, RC e produção ... Tudo isso afeta o processo de passar do desenvolvimento para a produção real.

Eu diria que as porcentagens estão corretas, inclinando-se mais perto da marca de 30% do que 5%. Se tudo o que você está investindo é de 5%, está fazendo um bom trabalho. (Isso inclui erros encontrados durante as perguntas e respostas ou o RC ou mesmo a produção devido à falta de gerenciamento do sistema de compilação, o que pode causar grandes atrasos).

— AJC
fonte

Se tudo o que você está investindo é de 5%, sugiro que você não esteja medindo tudo ou com precisão.

— mattnz

não mate. Você está usando uma definição diferente. A maioria das empresas em que trabalhei NÃO possui um sistema de compilação instalado, como em nenhum servidor de compilação automatizado, integração de VCS (geralmente nenhum VCS, exceto os projetos que eles mesmos podem configurar por conta própria, que acaba sob o radar) etc. Em qualquer "estudo" da porcentagem de recursos usados na manutenção do "sistema de compilação", eles acabam listados como gastos quase nulos, a menos que sejam divididos para incluir o esforço gasto na manutenção de todos os scripts ANT e Maven, algo raramente feito.

— jwenting