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

14

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.

user1915639
fonte
1
Isso ajuda: plosbiology.org/article/…
akid
Se o objetivo de adicionar referências é convencer os leitores de que melhores práticas são melhores, pode fazer mais sentido explicar por que elas são melhores diretamente; simplesmente dar referências pode ser menos persuasivo. Lembre-se de que muitas dessas coisas são comuns nos cursos de graduação em engenharia de software, podem ser encontradas em livros didáticos padrão e não são necessariamente pesquisas de ponta.
Kirill
Minha experiência é que você precisa de motivação e referências. Ontem, tive uma conversa com colegas de trabalho (os quais estão praticando cientistas) que acreditavam que as metodologias de teste ad hoc funcionam melhor (resposta curta: não funcionam). É importante expressar a motivação em termos de métricas com as quais os cientistas da computação parecem se importar: mais documentos de impacto mais rápido e resultados mais corretos (consulte o link sobre pesquisa reproduzível). Aponte para referências, porque as pessoas vão lutar com você nesses pontos, alegando que não há benefícios significativos.
precisa saber é o seguinte
Com toda a probabilidade, as pessoas que examinarão minha tese serão professores de química ou de ciências dos materiais, em vez de especialistas em ciências da computação. Eles provavelmente terão alguma experiência em escrever código, mas certamente não terão feito nenhuma codificação séria desde que eram estudantes ou pós-docs. O que eu preciso é algo que diz: "Naquele ano do meu PhD que eu gasto com isso, eu estava realmente fazendo algo útil e não apenas faltar"
user1915639

Respostas:

13

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.

Geoff Oxberry
fonte
A lista de leitura "Software Carpentry" parece útil.
precisa saber é o seguinte
6

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:

David Ketcheson
fonte
Definitivamente, sou a segunda dessas referências :-) As informações completas são Wolfgang Bangerth, Timo Heister O que faz com que as bibliotecas de software de código aberto computacional sejam bem-sucedidas? Computational Science & Discovery, vol. 6, artigo 015010 (18 páginas), 2013
Wolfgang Bangerth
-2

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 :)

internetscooter
fonte
1
De fato, os estudos compararam estratégias de detecção de defeitos, como teste de unidade, programação de pares, execução de um programa com um depurador e revisão formal de código e avaliaram sua eficácia. Você está certo que cada estratégia tem seu lugar. A comunidade de desenvolvimento de software reconhece esse ponto na literatura e sugere o que pode funcionar melhor para diferentes tipos de projetos. Se "muitas variáveis ​​e fatores humanos" fossem realmente um obstáculo à formulação de melhores práticas, não as teríamos na medicina ou em outros campos com questões complexas semelhantes, mas o fazemos. Eu não compro seu argumento.
Geoff Oxberry
"um mush declaração mais poderosa em seu PhD" é um belo erro de digitação
denis