Estou entrando no meu terceiro ano do meu programa de doutorado e até agora meu código de pesquisa (problemas inversos numéricos / imagens médicas / processamento de imagens / etc) consiste principalmente de scripts e funções desorganizados do MATLAB, com alguns C ++ e CUDA MEX'd rotinas lançadas para obter mais velocidade aqui e ali. Trabalhar com o MATLAB tem sido (principalmente) divertido, e provavelmente não vou desistir completamente, no entanto:
Neste verão, eu estive trabalhando em um código 'grande' em um laboratório nacional e estou começando a ver a beleza em um código bem oleado, orientado a objetos e controlado por versão, com um bom uso de gmake e outros brinquedos de ciência da computação .
Minha pergunta é a seguinte: até que ponto devo tentar incorporar essas ferramentas no meu código de pesquisa? Quanto tempo devo gastar "planejando" a estrutura e a implementação do meu código, ou devo parar de pensar nisso e escrever boas rotinas? Sinto que deveria estar desenvolvendo uma base de código-fonte aberto bem planejada como um produto da minha dissertação, para a experiência e credibilidade do CV, mas não tenho certeza de como navegar nesse processo. Alguma dica, livro / artigo / site recomendações, etc?
fonte
Respostas:
Eu consideraria estas perguntas:
Deseja que seu código se torne um código de uso geral que você possa reutilizar mais tarde, ou isso é apenas um pouco de código que você está usando para um projeto ou trabalho de pesquisa que não planeja reutilizar? Se você não planeja reutilizar o código, provavelmente não vale a pena gastar tempo e esforço aprimorando o código.
Você aprendeu o suficiente sobre os algoritmos e as estruturas de dados que está usando e confia que deseja continuar usando esses algoritmos e estruturas de dados? Caso contrário, pode ser prematuro congelar sua pesquisa em um código estável.
Deseja compartilhar o código, levar outras pessoas a usá-lo e, finalmente, ajudar outras pessoas a desenvolver o código ainda mais? Como pesquisador, você deve entender que essa é uma das maneiras mais eficazes de garantir que seu código tenha impacto em seu campo de pesquisa. No entanto, para começar, você precisa fornecer um código razoavelmente robusto e deseja liberá-lo sob uma licença de código aberto, para que outros possam fazer uso do código em seus próprios projetos.
fonte
Somente o que você sente será recompensado pelo que estiver tentando fazer. Se você estiver executando scripts MATLAB, controle de versão e talvez teste de unidade serão tudo o que você precisa. Se você possui arquivos MEX, provavelmente é bom ter um Makefile que os compila, mesmo que seja para sua própria sanidade, já que digitar seqüências de comandos de compilação cada vez que você deseja criar os arquivos MEX é frágil.
Parte do motivo pelo qual essas ferramentas de fluxo de trabalho são usadas e incorporadas em grandes projetos é porque o investimento nessas ferramentas compensa seus objetivos. Como exemplo, para um código de pesquisa único que apóia sua tese, provavelmente não vale a pena usar um sistema de construção de plataforma cruzada como o CMake. Para uma biblioteca cujo objetivo declarado é ser compatível com várias plataformas, como, por exemplo, Elemental, faz mais sentido investir tempo no uso de um sistema de construção de plataforma cruzada.
Depende de como você está familiarizado com o problema que está tentando resolver, algoritmos apropriados, estruturas de dados, práticas de programação e assim por diante. Assim como delinear e pré-escrever são úteis para artigos de periódicos, uma certa quantidade de brainstorming e pseudo-codificação é útil para escrever código bem estruturado. Gosto do processo de programação de pseudocódigo no Code Complete, de Steve McConnell; ele também inclui algumas referências e diretrizes em termos de quanto tempo deve ser gasto na fase de design, dependendo do tipo de projeto.
Escrever versões descartáveis de rotinas e experimentar pequenos bits de código também é realmente útil. Um aforismo comum no desenvolvimento de software é que você sempre jogará fora pelo menos uma versão do seu código.
Eu acredito que as práticas de desenvolvimento "ágeis" tendem a funcionar melhor com a maioria dos desenvolvimentos científicos de software, com base no trabalho de Greg Wilson na Software Carpentry (aviso: eu me ofereci no passado). Em termos gerais, "ágil" significa que você deve definir metas que acha que alcançará em um curto período de tempo (digamos, alguns dias, uma semana, talvez um mês no máximo), planejar como alcançá-las fazendo algum pseudocódigo e projetar, escreva código e repita. Ciclos curtos ajudarão você a reagir às mudanças, como quando seu consultor decide que deseja que você estenda seu trabalho de maneiras que você não previu.
Tudo depende do que você quer fazer. Para posições que envolvem desenvolvimento de software, é útil desenvolver uma base de código-fonte aberto, porque é algo que você pode postar no GitHub e apontar. Dito isto, se você quiser torná-lo um pacote de software que as pessoas usarão, você precisará gastar algum tempo mantendo-o; você pode não querer fazer isso. Contribuir com seu código de pesquisa para projetos existentes relevantes também pode ser uma opção muito boa. As empresas parecem querer uma mistura de ambos. Se você pode contribuir com o código de outras pessoas, isso mostra que você é um jogador da equipe e que pode ler o código de outras pessoas e ainda fazer algo útil com ele.
Em termos de referências, a lista de leitura de referências do Software Carpentry é voltada para os cientistas e, se você quiser aprofundar as práticas de engenharia de software, o Code Complete (consulte a lista no link anterior) tem outras referências que estão começando a se tornar um pouco datado, mas são úteis para procurar. Os trabalhos publicados sobre as melhores práticas em computação científica também são úteis
As lições da Software Carpentry também são úteis. Eles são centrados no Python quando se trata de programação, então você pode levar isso com um pouco de sal, mas vale a pena examinar as partes do controle de versão.
fonte