Referências citáveis ​​para práticas recomendadas de software

Atualmente, estou escrevendo minha tese de doutorado. Passei uma fração significativa do meu doutorado limpando e estendendo o código científico existente, aplicando as práticas recomendadas de engenharia de software que não eram usadas anteriormente e gostaria de escrever sobre isso em minha tese. Em vez de simplesmente dizer "eu adicionei testes de unidade", quero poder escrever algo como isto:

J. Doe inventou testes de unidade em 1975 . Um estudo recente de Bloggs et al mostrou que os testes de unidade reduzem a incidência de erros de software em 73% ... 234 testes de unidade separados foram adicionados à base de código, gerenciados pela estrutura xUnit criada por Timpkins et al.[ 24 ] [ 25 $^{[23]}$$^{[24]}$$^{[25]}$

Estou procurando referências acadêmicas citáveis ​​(de preferência artigos em jornais revisados ​​por pares, onde posso obter DOIs, BibTeX etc.) para as melhores práticas de engenharia de software amplamente aceitas, especificamente:

• testes de unidade
• controle de versão
• modularização / separação de preocupações
• perfil / otimização de desempenho com base em informações de perfil
• rastreamento de bug / problema

Estou procurando informações sobre a invenção inicial e avaliações subseqüentes de eficácia. Se houver um artigo de revisão que lista todas essas coisas em um só lugar, tanto melhor.

O livro de Steve McConnell, Code Complete, 2nd edition, tem uma extensa bibliografia que discute essas questões do ponto de vista mais dos desenvolvedores de software do que dos cientistas da computação. O livro está começando a ficar um pouco antiquado, já que se aproxima de uma década, por isso não abrange metodologias de teste mais recentes, como o desenvolvimento orientado pelo comportamento. No entanto, é a coisa mais próxima de um artigo abrangente de revisão sobre construção de software que eu conheço. Você também pode procurar artigos no IEEE Software.

Do lado da ciência da computação, acho que o melhor artigo é provavelmente a versão PLoS da pré-impressão do arXiv que DavidKetcheson citou em "Melhores práticas para computação científica". Digo isso vindo de uma experiência em engenharia, em que menos pessoas citam referências ao arXiv ou publicam pré-impressões do arXiv e, portanto, citam um "artigo de revista real" (deixando de lado, é claro, todos os problemas de publicação científica que estão sendo debatidos no momento ) é encarado de maneira mais favorável (e tenho a impressão de que esses autores escolheram publicá-lo em um periódico).

Os autores do artigo PLoS que DavidKetcheson e eu citamos fazem parte de uma organização chamada Software Carpentry que realiza (normalmente 2 dias) "campos de treinamento" para ensinar aos cientistas algumas das melhores práticas para o desenvolvimento de software e habilidades computacionais úteis para os cientistas (não apenas cientistas computacionais). O site Software Carpentry possui uma extensa bibliografia relacionada ao desenvolvimento de software na ciência. Se você estiver interessado nessas questões, recomendamos que você as procure; eles estão sempre procurando mais defensores das melhores práticas em desenvolvimento de software para fazer voluntariado em várias capacidades. ( Isenção de responsabilidade : sou voluntário na Software Carpentry.)

Outra justificativa comum para se envolver nas melhores práticas de desenvolvimento de software é a reprodutibilidade. Victoria Stodden selecionou uma longa lista de referências de pesquisa reproduzíveis que podem ser interessantes, dependendo do que você deseja dizer.

Não tenho referências para a origem de cada uma dessas idéias / práticas. Mas aqui estão algumas referências relevantes e muito recentes:

• O que faz com que as bibliotecas de software de código aberto computacional sejam bem-sucedidas?
• Práticas recomendadas para computação científica

IMHO Eu tomaria muito cuidado citando "Melhores Práticas" no contexto de abordagens cientificamente comprovadas. A maioria das práticas deriva do "que parece funcionar para um conjunto de projetos por alguém percebido como guru envolvido nesses projetos", em vez de derivar de testes rigorosos de diferentes abordagens. Existem muitas variáveis ​​e fatores humanos na engenharia de software para afirmar que há uma lista referencial de "melhores práticas" (por exemplo, uma prática que funciona em um projeto falha completamente em outro).

Eu abordaria isso, declarando o que seu projeto precisava, por que ele precisava e adicionando referências aos métodos usados ​​e por que você os usou.

Eu também me inclinaria a relatar resultados quantificáveis ​​em vez de referências para expressar seu ponto de vista. Por exemplo, se seus testes de unidade descobriram 100 bugs, 10 dos quais sérios o suficiente para colocar em dúvida os resultados publicados anteriormente. Esta é uma afirmação muito mais poderosa para se ter no seu doutorado do que uma afirmação de que você sabe a origem dos testes de unidade.

edit: (erro de digitação fixo) - Respondendo ao seguinte - Costumo criar filhos como uma analogia a projetos de software. Existem muitos métodos e maneiras testadas de criá-los, tentando criar seus filhos com um método, porque funciona para a subamostra média ou para uma subamostra testada, funcionará desde que seu filho seja o mesmo que o testado. É melhor conhecer muitos métodos e aplicar os que funcionam na sua instância. Sim, o teste de unidade pode ser comprovado, mas aplicá-lo com base nisso pode significar que seu projeto chega ao mercado tarde e, portanto, falha no objetivo (se esse é o objetivo). Estou dizendo que aplicar um método para obter um resultado e dar o resultado desse resultado, na minha opinião, é melhor em uma tese do que listar coisas que você tentou com base em outros projetos - a menos que o tópico da tese esteja medindo metodologias :)