Existe um estudo de caso que demonstre de forma convincente que o código limpo melhorou o desenvolvimento? [fechadas]

Estou no meu primeiro trabalho real como programador e o que vejo é apenas o código "Big Ball of Mud" (sem comentários úteis também), mas eu gosto de fazer um código limpo, e é realmente difícil para mim codificar de maneira pior caminho.

Estou procurando por alguns casos de estudo em que o uso de código limpo (vejo várias definições aqui do que é código limpo) melhorou o desenvolvimento e a manutenção.

Uma rápida (mas de nenhuma maneira exaustiva) busca de Google Scholar vira para cima um monte de artigos que se referem a de Bob Martin Código Limpo , mas eu não vi pessoalmente quaisquer documentos que cobrem uma correlação entre "código limpo" e melhor desenvolvimento.

No entanto, pense na sua pergunta por um momento. Você está perguntando sobre o desenvolvimento aprimorado, e isso por si só é uma área de assunto muito ampla, abrangida não apenas pela criação de um código melhor, mas também por muitos outros fatores, como comunicação, gerenciamento de expectativas, metodologia e racionalização de processos, testes, integração contínua e realmente a caixa inteira e os dados quando você considera quantas coisas são necessárias para o sucesso de um projeto de desenvolvimento de software, sem falar em aprimorá-lo.

Então, sua pergunta provavelmente deve ser: escrever código limpo contribui para melhorar o desenvolvimento de software? Para responder a isso, a única "evidência" que eu poderia fornecer seria inteiramente anedótica, e por isso acho que o livro do Código Limpo seria uma excelente referência, pois foi escrito não apenas pelo próprio Bob Martin, mas também com muitos capítulos contribuídos por alguns dos desenvolvedores de software mais inteligentes do mercado. Se isso não ajudar, talvez um pouco de lógica rígida possa ser aplicada.

Se você faz uma bagunça em sua casa e nunca sai para limpá-la, viver em sua casa se tornará uma tarefa árdua. Torna-se mais difícil encontrar coisas, mais difícil de se movimentar, e ninguém em sã consciência vai querer visitá-lo se você vive em um ambiente imundo. O mesmo também com o código. Se o seu código estiver uma bagunça, é mais difícil encontrar problemas localizados, quanto mais corrigi-los. Torna-se mais fácil justificar uma solução alternativa que pode não dar certo, mas, ei, com certeza é melhor ter que passar por toda aquela sujeira antiga, certo? No final, assim como nunca arrumar sua casa, permitir que seu código se torne desarrumado custará tempo e esforço, além de criar dificuldades para você a longo prazo. Manter seu código limpo, no entanto, fornecerá uma plataforma melhor para você trabalhar, tornar a refatoração e a depuração menos trabalhosas,

Não, não tenho evidências diretas para dar a você, e esses são apenas os pensamentos de alguém que faz essas coisas há muito tempo e que, esperançosamente, ganhou um pouco de conhecimento em desenvolvimento de software pelo caminho. :-)

O que você precisa entender é que nenhuma empresa decide escrever código medíocre. O problema é que 50% do código, mais ou menos, é escrito pelos programadores abaixo da média da sua empresa. Você está pregando para o coral quando expõe os benefícios do código limpo. O truque é como fazê-lo. Faça alguma pesquisa sobre ferramentas como revisão por pares, análise estática, testes automatizados, integração contínua, TDD, scrum, programação extrema etc. e apresente possíveis soluções em vez de apenas explicar por que o problema é ruim.

Sei que isso vai contra a corrente aqui, mas o tempo de colocação no mercado, a adequação dos requisitos, o financiamento adequado, o bom marketing, o preço certo e a boa sorte têm muito mais influência no sucesso dos produtos de software do que na qualidade do código.

Isso NÃO significa que a qualidade do código deve ser ignorada, mas você deve reconhecer que é apenas um dos muitos fatores.

Existem muitos exemplos de códigos simplesmente horríveis em produtos de enorme sucesso (por exemplo, o Apple OS original que deixou o gerenciamento de threads para os aplicativos).

Não consigo pensar em nenhum exemplo de código bonito que supere um produto mal concebido ou muito caro.

Portanto, se é hora de comercializar vs. código bonito, a hora de comercializar deve ter prioridade!

Você precisa separar o código limpo dos objetivos reais: reduzir o custo de correção de defeitos após a implantação e reduzir o retrabalho desnecessário. Quando você fala sobre "escrever código limpo para que ele tenha menos erros", você está falando de religião. Quando você está falando sobre "reduzir a taxa de defeitos em 10%, economizando 2 meses / mês de esforço no projeto", você está falando de gerenciamento. O código limpo é uma ferramenta para melhorar a qualidade inicial da base de código e, assim, reduzir o custo total, mas é um dos muitos.

O documento a seguir explica por que acertar na primeira vez é importante sob uma perspectiva de custo: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

Não conheço nenhum estudo específico, mas confira o trabalho de Steve McConnell .

Se alguém tiver, ele o fará. Por exemplo, uma verificação de dois minutos encontrou isso (16 anos, mas ainda é relevante hoje).

Para adicionar à resposta de mattnz, se você ainda não o tiver, eu diria especificamente que consulte o Código Completo: Um Manual Prático de Construção de Software, de Steve McConnell. Além do fato de que provavelmente melhorará sua codificação, ele cita vários estudos ao longo do livro sobre como várias práticas de codificação afetam a qualidade dos programas.

Como um exemplo (do livro):

Outro estudo de 450 rotinas diferentes (o que é apenas uma coincidência incomum) descobriu que as rotinas com as maiores taxas de acoplamento / coesão tinham 7 vezes mais erros do que aquelas com as menores taxas de acoplamento / coesão e eram 20 vezes mais caras para corrigir (Selby e Basili 1991).

Também costumava ser a resposta número um à pergunta Qual é o livro mais influente que todo programador deve ler? (apesar de eu ver que as respostas a essa pergunta foram recentemente reorganizadas de uma maneira esfarrapada)