Existe uma correlação entre a complexidade do código e a produtividade do desenvolvedor?

10

O tempo gasto na refatoração de uma base de código vale a pena a longo prazo, em termos de produtividade do desenvolvedor?

Parece-me bastante claro que modificar um sistema limpo e bem projetado é muito mais simples e rápido do que trabalhar em um sistema mal projetado, mas estou procurando evidências sólidas. Existem estudos sobre esse tópico?

productivity complexity

— Benny Hallett
fonte

Veja RECONSTRUÇÃO

— hakre

11

Comece a manter uma bagunça e seja o juiz.

— Tulains Córdova

16

Empiricamente, software com métricas de maior complexidade, como complexidade ciclomática, é mais difícil de manter. Há pesquisas apoiando isso desde os anos 1970 ("Complexidade do programa e produtividade do programador", ET Chen) . Também existe um trabalho que sugere que a densidade da complexidade, que é complexidade ciclomática em relação ao tamanho do sistema, também se relaciona ao tempo de manutenção ("Densidade da complexidade ciclomática e produtividade de manutenção de software", GK Gill, CF Kemerer) , que também está disponível gratuitamente aqui . Infelizmente, uma assinatura do IEEE é necessária para o artigo de Chen, mas você pode tentar procurá-la em outras fontes, se estiver interessado.

De uma perspectiva de qualidade, geralmente vale a pena gastar algum tempo refatorando, supondo que você tenha uma estrutura de teste para evitar a introdução de novos defeitos. Isso permitirá que você implemente mais facilmente novos recursos em seu sistema, adicione testes adicionais e treine novos desenvolvedores para o trabalho.

Por fim, no entanto, há pressão para oferecer novas funcionalidades e valor agregado. Você precisa equilibrar a refatoração com a implementação de novas funcionalidades e o reparo de defeitos.

— Thomas Owens
fonte

2

Outro ponto a acrescentar é que, quando você refatorar, provavelmente implementará recursos de uma maneira melhor / mais eficiente / mais limpa. Há um ditado que eu ouvi uma miríade de vezes para o efeito de "em 5 anos você vai encolher que você pensou que seu código era 'bom'"

— Warren

11

@hakre Eu verifiquei quando publiquei isso e novamente agora, usando uma pesquisa na Web do Google e o Google Scholar. Na época em que escrevi originalmente este post, nenhum documento estava disponível sem compra. No entanto, desde então, um artigo foi publicado em um domínio da Universidade de Pittsburgh, que parece pertencer a um dos autores e eu adicionei um link para ele. O outro papel não está disponível gratuitamente. Eu adicionei os títulos ao corpo da postagem para facilitar a procura por eles. Se você não quiser ler os artigos, precisará aceitar minha análise, juntamente com meu conhecimento e experiência.

— Thomas Owens

0

Estou atrás de alguma evidência sólida

Então pare de desperdiçar seu tempo aqui.

Encontre um código caro para manter. É fácil. Veja os registros de problemas da sua organização.
Encontre um código que seja barato de manter. Encontre o código que é executado com frequência, mas tem poucos ou nenhum registro de problemas.
Avalie a complexidade com qualquer uma das ferramentas de complexidade amplamente disponíveis.
Aproveite as evidências.

Você forneceu números para confirmar o óbvio.

— S.Lott
fonte

5

Na verdade não. a complexidade da tarefa executada pelo software deve ser diferenciada da complexidade adicionada causada pela implementação escolhida.

— reinierpost

4

-1 não uma resposta

— Dave Hillier