Boas estratégias para o desenvolvimento do desperdício de código?

Question

Eu freqüentemente escrevo descartáveis código (em um ambiente de pesquisa), por exemplo, para explorar um algoritmo ou de um modelo científico de propriedade ou de processo.Muitos desses "experimentos" são one-off, mas às vezes eu acho que eu preciso usar um pouco mais tarde.Por exemplo, eu tenho apenas revelaram a existência de código de seqüência de caracteres correspondente eu escrevi há 7 anos (parado devido a outras prioridades), mas que agora é valioso para um colega de trabalho do projeto.Tendo olhado para ele (eu realmente escrever impenetrável código?) Eu sei que há algumas coisas que eu poderia ter feito, em seguida, para me ajudar, quando eu reiniciei o "projeto" (o"experimento" é ainda uma palavra melhor).A experiência anterior "trabalhou" mas eu sei que no momento eu não teria tempo para refatorar como minhas prioridades leigos em outro lugar.

Que abordagens são custo-eficazes, permitindo que tal trabalho a ser escavado e re-utilizado?

EDITAR:Já respondi a minha própria pergunta (abaixo), porque há questões que ultrapassam a fonte real em si.

Answer 1

Eu discordo de todas as respostas dizendo "Escreva comentários". Isso está sendo oferecido como um problema para o próprio código não ser compreensível.

Pegue uma cópia de Código completo (Steve McConnell, 2ª edição). Se você aprender as técnicas de escrever código sustentável em primeiro lugar, não levará mais tempo e você poderá retornar ao seu trabalho mais tarde com menos problemas.

Qual você prefere:

• Código enigmático com comentários?
• Principalmente ok código sem?

Eu prefiro fortemente o último, pois o código OK é mais fácil de entender nas situações em que o código enigmático não foi declarado e os comentários são outro lugar que o desenvolvedor original pode cometer erros. O código pode ser Buggy, mas nunca é errado.

Depois de se sentir confortável com Código completo, Eu recomendo O programador pragmático, como oferece conselhos de desenvolvimento de software um pouco mais alto.

Answer 2

Respondendo à própria pergunta] Existem vários outros aspectos no problema que não foram levantados e que eu teria achado útil ao revisá -lo. Alguns deles podem ser "evidentes", mas lembre-se de que esse código era pré-SVN e IDES.

• Descobertabilidade. Na verdade, tem sido difícil encontrar o código. Acredito que está no meu projeto Sourceforge, mas há tantas versões e ramificações ao longo de 7 anos que não consigo encontrá -lo. Então, eu teria que ter um sistema que pesquisasse código e até que o IDES aparecesse, eu não acho que houvesse.
• O que isso faz?. O check -out atual contém cerca de 13 classes (tudo em um pacote, pois não era fácil refatorar na época). Alguns são claros (DynamicAligner) Mas outros são opacos (MainBox, nomeado porque estendeu uma caixa de balanço). Existem quatro main() programas e na verdade existem cerca de três subprojetos na distribuição. Portanto, é fundamental ter um manifesto externo sobre o que os componentes realmente eram.
• instruções sobre como executá -lo. Ao executar o programa, main() oferecerá um breve uso de linha de comando (por exemplo DynamicAligner file1 file2) Mas não diz como é realmente o conteúdo dos arquivos. Eu sabia disso na época, é claro, mas não agora. Portanto, deve haver associado exemplo arquivos em diretórios de irmãos. Estes são mais valiosos do que tentar documentar formatos de arquivo.
• ainda funciona?. Deveria ser possível executar cada exemplo sem pensar. A primeira pergunta será se as bibliotecas associadas, os tempos de execução etc. ainda são relevantes e disponíveis. Um ex-coworker escreveu um sistema que só funciona com uma versão específica do Python. A única resposta é reescrever. Portanto, certamente devemos evitar qualquer bloqueio sempre que possível, e eu me treinei (embora não necessariamente colegas de trabalho) para fazer isso.

Então, como eu e os colegas de trabalho evitam problemas no futuro? Eu acho que o primeiro passo é que deve haver uma disciplina de criar um "projeto" (por mais pequeno) quando você cria código e que esses projetos devem estar sob controle de versão. Isso pode parecer óbvio para alguns de vocês, mas em alguns ambientes (academia, doméstico), há uma sobrecarga significativa para a criação de um sistema de gerenciamento de projetos. Suspeito que a maioria do código acadêmico não esteja sob nenhum controle de versão.

Depois, há a questão de como os projetos devem ser organizados. Eles não podem estar no Sourceforge por padrão, pois o código é (a) trivial e (b) não aberto por padrão. Precisamos de um servidor onde possam haver projetos comunais e privados. Eu calcularia que o esforço para configurar e executar é cerca de 0,1 ETI - é 20 dias por ano de todas as partes (instalação, treinamento, manutenção) - se houver opções mais fáceis que eu gostaria de saber, pois é um grande Despesas em alguns casos - passo meu tempo configurando um servidor ou escrevo papéis?

O projeto deve tentar incentivar uma boa disciplina. Isso é realmente o que eu esperava obter dessa pergunta. Pode incluir:

1. Um modelo de componentes necessários (manifesto, readme, log de commits, exemplos, bibliotecas necessárias, etc. Nem todos os projetos podem ser executados no Maven - por exemplo, fortran).
2. Um meio de pesquisar um grande número (pelo menos centenas) de pequenos projetos para cordas mnemônicas (gostei da idéia de despejar o código em Googledocs, e isso pode ser uma avenida frutífera - mas é um esforço de manutenção extra).
3. Convenções claras de nomeação. Estes são mais valiosos do que comentários. Agora eu tenho nomes regularmente do tipo iterateVallXandDoy. Eu tento usar o createx () em vez de getx () quando a rotina realmente cria informações. Eu tenho um mau hábito de chamar o processo de rotinas () em vez de converterlbtoy ().

Estou ciente, mas não usei Git e Mercurial e GoogleCode. Não sei quanto esforço eles são para configurar e quantas das minhas preocupações elas respondem. Eu ficaria encantado se houvesse um plug -in IDE que ajudasse a criar um código melhor (por exemplo, "má escolha do nome do método").

E quaisquer que sejam as abordagens que eles têm que vir naturalmente para pessoas que não têm naturalidade têm uma boa disciplina de código e valem a pena o esforço.

Answer 3

Como os excelentes respostas em seu outro post indicar, e a partir de minha própria experiência, não é difícil-para-cruz lacuna entre o software utilizado para a investigação e o software que foi projetado.Na minha opinião, o Código Completo pode ajudar um pouco, mas não muito.Como uma questão econômica, é que vai ser útil para refatorar tudo para reutilização em comparação com a ocasional de recompensa para encontrar um uso posterior para alguma coisa?Seu ponto de equilíbrio pode variar.

Aqui está uma dica prática para armazenar fragmentos.Em vez de full-blown comentários, jogar um pouco de palavras-chave:

• "gráfico de isomorfismo wrapper"
• "polímero de recozimento simulado"
• "cadeia de caracteres de correspondência de feynmann"
• "equilíbrio"

e, em seguida, coloque o código em algum lugar do Google pesquisável, como uma conta do GMail.

Editar: Eu poderia acrescentar que o Google Sites são realmente pesquisável wikis são um bom lugar para colocar o código, quer sob a forma de anexos ou colados.

Além disso, devo dizer que eu sou um fã de Código Completo e ter dado cópias para alunos de graduação software de gravação para a investigação científica, por vários anos.É um bom início, mas nenhuma bala de prata.Eu estou escrevendo um artigo agora sobre a utilização de frameworks open source para resolver científica de dados de gerenciamento de problemas e uma das conclusões é que alguns de engenharia de software, a perícia é essencial para a longa-sistemas em execução.Muitos projetos científicos provavelmente deve orçamento para isso desde o começo.

Answer 4

Comentários - Descreva o que você estava pensando e por que você escolheu implementar algo de uma certa maneira, incluindo quais alternativas você considerou. Provavelmente, existem todos os tipos de soluções sofisticadas, mas apenas comentando seu código corretamente no momento em que você está escrevendo, parece funcionar melhor.

Answer 5

Eu ecoaria o que os outros disseram no que diz respeito ao "por que" por que o código foi escrito e seu uso pretendido, mas eu também acrescentaria isso:

Core como se você estivesse planejando colocar isso em produção, mesmo quando estiver apenas brincando. Código para:

• Clareza e legibilidade
• Siga as convenções de codificação da época. (Convenções de nomeação, etc.). Embora essas convenções mudem com o tempo, se você seguir os padrões, é mais provável que seja capaz de entendê -lo mais tarde.
• Segurança (se aplicável)
• desempenho (se aplicável)

Particularmente, eu enfatizaria o primeiro ponto, mas os outros também são importantes. Acho que, se eu usar o "código de teste" mais tarde, tendem a usá -lo se funcionar, em vez de refatorá -lo.

Answer 6

Provavelmente perdi o objetivo de toda essa discussão, frequentemente, mas aqui vai, um convite para Brickbats e Vooting ...

Se for um código descartável, jogue -o fora!

Se você não quiser jogá -lo fora, siga os bons conselhos acima. Para mim, e escrevo uma boa quantidade de código descartável, a questão de se ele é jogado fora ou colocado em um estado reutilizável e mantido contra um dia chuvoso se resume à economia.

Posso prever circunstâncias em que esse código será útil novamente? Uma vez na lua azul, duas vezes por ano, todos os meses?

Serei capaz de reescrever esse código em menos tempo do que leva para torná -lo reutilizável? Se a resposta a essa pergunta for não, quantas vezes terei que reutilizá -la para fazer valer a pena melhorá -la agora? (De volta à pergunta anterior.)

Se eu tornar esse código reutilizável, poderei encontrá -lo novamente quando eu quiser? (Alguém já teve a experiência de saber, com absoluta certeza, que em algum lugar do seu repositório de código existe apenas o fragmento que você deseja, mas não tendo uma pista como foi chamado, nem onde procurar nem para o que grep?)

Finalmente, a abordagem de 3 etapas para tornar o código escrito rapidamente reutilizável. Pare depois de qualquer dessas etapas que você quiser:

1) Documente o código como uma caixa preta. Entradas, saídas, operação (s). Arquive este documento com cuidado.

2) Escreva instruções sobre como criar/interpretar/instalar o código, caso você precise portá -lo. Arquive essas instruções com cuidado.

3) Somente se valer o esforço - melhore a qualidade do código -fonte para tornar o código sustentável no futuro. Verifique se as fontes estão no sistema de controle de origem e encontradas.

Cumprimentos

Marca

Answer 7

Eu acho que a coisa mais importante (se você não refatorar, não vai acontecer) é comentar e documentar seu processo de pensamento no momento. Isso ajudará a tornar o código menos impenetrável e ajudará a encontrar os bons bits quando necessário.

Answer 8

Não não não não não!

Não escreva código descartável, mesmo em um ambiente de pesquisa. Por favor!

Atualmente, estou mexendo com um "código descartável", o projeto de explosão. O fato é que ele começou como um playground, mas depois se tornou um pouco bem -sucedido, agora é uma ferramenta interessante com muitos conceitos implementados, mas o código é praticamente impensável. Mas esse não é o ponto principal.

O ponto principal é que você pesquisa para os engenheiros se beneficiarem posteriormente de suas descobertas. Tendo feito um bom trabalho científico sobre conceito geral e escrevendo uma ferramenta que prova isso bem -sucedida, você pode esquecer facilmente que está fazendo isso não para publicação e apenas doutorado. Você faz isso para o benefício da humanidade. Seu código pode conter um monte de "casos especiais", que eram difíceis de depurar, um conjunto de peculiaridades e hacks que não se encaixam em nenhum artigo da conferência. É especialmente importante documentar e comentar essas coisas em todo o seu código.

Se um desenvolvedor decidisse implementar seus conceitos em um produto comercial, ele poderia ter estudado as peculiaridades e hacks do seu código e a implementação teria menos bugs do que poderia ter. Todo mundo diz "Uau, sua pesquisa sobre um realmente é útil!" Mas se você escreve "descartável", eles dizem "seu conceito parece bom no papel, mas X tentou implementá -lo e se afogou em um monte de insetos".

(EDITAR: retirado dos comentários abaixo) para ajudar futuros desenvolvedores da sua base de código, você não precisa de muito. Primeiro, Comente o que cada função faz. Segundo, Certifique-se de que todas as correções não óbvias de um bug complicado sejam colocadas em um compromisso separado no sistema de controle de revisão (com um comentário apropriado, é claro). Isso é suficiente. E se você tornar as coisas modulares (mesmo que não estiverem prontas para reutilização direta-três vezes mais caras, segundo Brooks), você será adorado por engenheiros que implementam sua pesquisa.

Eu acho que o mundo seria um lugar melhor se os pesquisadores jogassem fora sua arrogância e parassem de pensar que não são esses codificadores sujos que fazem um trabalho servil ao escrever um bom código. Escrever um bom código não é apenas um trabalho para esses programadores estúpidos. É uma coisa realmente valiosa que todos devem se esforçar. Sem isso, seu terreno experimental, seu código, sua ideia morrerá.

Answer 9

Algumas estratégias:

1. Bons comentários. Difícil reutilizar o que você não consegue encontrar ou entender mais tarde.
2. Salve todas as consultas em uma pasta que é backup ou está sob controle de origem.
3. Tenha uma biblioteca comum de funções úteis que você "promove" algo para que fosse reutilizado.

Answer 10

Você também pode emprestar a idéia de testes de unidade do pessoal do TDD (desenvolvimento orientado a testes). Você precisa garantir que o código descartável funcione bem de qualquer maneira, então por que não expressar o check Linke em um pequeno teste de unidade? Isso teria duas vantagens:

1. A leitura do código de teste comunica a intenção do descarte claramente: depois de tudo, expressa suas expectativas no mesmo idioma: código.

2. Também ajudaria com o quarto problema da sua auto-reforma: "ainda funciona?". Bem, é fácil: basta executar os testes da unidade e eles dizem o que e onde (e com um pouco de sorte) por que (ele) não funciona.