O que OOP práticas de codificação que você deve sempre tempo para fazer?

https://stackoverflow.com/questions/314241

10-07-2019
|

Pergunta

I tendem a fazer um monte de projetos em prazos curtos e com lotes de código que nunca serão usados ??novamente, por isso há sempre pressão / tentação de cortar cantos. Uma regra que eu sempre manter é o encapsulamento de acoplamento / solto, por isso tenho muitas turmas pequenas, em vez de uma classe Deus gigante. Mas o que mais devo nunca comprometer a?

Atualização - graças à grande resposta. Muitas pessoas têm sugerido testes de unidade, mas eu não acho que isso é realmente apropriado para o tipo de interface de codificação que eu faço. testes de aceitação de usabilidade / Usuário parece muito importante. Para reiterar, eu estou falando sobre o BARE MÍNIMO de padrões de codificação para projetos prazo impossível.

Solução

Não OOP, mas uma prática que ajuda tanto a curto e longo prazo é seco, Do not Repeat Yourself. Não use copiar / colar herança.

Outras dicas

Nem uma prática OOP, mas o senso comum; -).

Se você está com pressa e tem que escrever um hack. Sempre adicionar um pedaço de comentário com as razões. Assim, você pode rastreá-lo e fazer uma boa solução mais tarde.

Se você nunca teve o tempo para voltar, você sempre tem a comentário para que você saiba, por isso a solução foi escolhida no momento.

controlar o uso da fonte .

Não importa quanto tempo leva para configurar (segundos ..), será sempre facilitar a sua vida! (Ainda não é OOP relacionado).

Naming. Sob pressão você vai escrever o código horrível que você não terá tempo para documento ou até mesmo comentários. Nomeando variáveis, métodos e classes tão explicitamente quanto possível leva tempo quase nenhum adicional e fará a leitura confusão quando você deve corrigi-lo. De um ponto de vista OOP, utilizando substantivos para classes e verbos para métodos naturalmente ajuda a encapsulação e a modularidade.

Os testes de unidade - ajuda a dormir à noite: -)

Este é bastante óbvio (eu espero), mas pelo menos eu sempre certificar-se de minha interface pública é a mais correcta possível. Os internos de uma classe sempre pode ser reformulado mais tarde.

nenhuma classe pública com variáveis ??públicas mutáveis ??(struct-like).

Antes que você perceba, você se refere a esta variável pública em todo o seu código, e no dia que você decidir neste campo é um computadorizada e deve ter alguma lógica nisso ... a refatoração fica confuso.

Se esse dia é antes de sua data de lançamento, ele fica mais confusa.

Pense nas pessoas (pode até ser o seu próprio futuro) que têm de ler e compreender o código em algum ponto.

A aplicação da única responsabilidade principal. aplicar eficazmente este princípio gera uma grande quantidade de externalidades positivas.

Como todo mundo, não como práticas OOP muito, tanto quanto práticas para a codificação que se aplicam a OOP.

teste de unidade, teste de unidade, teste de unidade. testes unitários definidos têm o hábito de manter as pessoas na tarefa e não "errante" sem rumo entre os objetos.
definir e documentar todas as informações hierárquica (namespaces, pacotes, estruturas de pastas, etc.) antes de escrever código de produção. Isso ajuda a concretizar relações de objeto e expor as falhas em premissas relativas a relacionamentos de objetos.
Definir e documentar todas as interfaces aplicáveis ??antes de escrever código de produção. Se feito por um líder ou um arquitecto, esta prática pode também ajudar a manter mais desenvolvedores de nível júnior na tarefa.

Há provavelmente outras incontáveis ??"deveria", mas se eu tivesse que escolher o meu top três, que seria a lista.

Editar em resposta ao comentário: É precisamente por isso que você precisa fazer essas coisas na frente. Todos esses tipos de práticas de fazer a manutenção contínua mais fácil. Como você assumir mais risco no pontapé inicial de um projeto, o mais provável é que você vai gastar mais e mais tempo manter o código. Concedido, há um custo inicial maior, mas construindo sobre uma base sólida se paga. É a sua falta de obstáculos de tempo (ou seja, ter que manter outras aplicações) ou de uma decisão do mais alto? Eu tive que lutar ambas as frentes para poder adotar esses tipos de práticas, e não é uma situação agradável para se estar.

É claro que tudo deve ser unidade testada, bem desenhado, comentou, verificado no controle de origem e livre de bugs. Mas a vida não é assim.

A minha classificação pessoal é esta:

Use o controle de origem e realmente escrever comprometer comentários. Desta forma, você tem um pouco de documentação que você deve sempre se perguntar "o que diabos eu acho que quando eu escrevi isso?"
código limpo Write ou documento. código escrito pelo bem limpo deve precisar de pouca documentação, como de significado pode ser compreendido de lê-lo. Hacks são muito diferentes. Write porque você fez isso, o que você faz eo que você gostaria de fazer se você tivesse o tempo / conhecimento / motivação / ... para fazê-lo direito
Teste Unitário. Sim, é baixo em número de três. Não porque é sem importância, mas porque é inútil se você não tem os outros dois, pelo menos, metade do caminho completo. Escrever testes de unidade é um outro nível de documentação que você código deve estar fazendo (entre outros).
Refactor antes de acrescentar algo. Isto pode soar como um típico "mas não temos tempo para isso" ponto. Mas como acontece com muitos desses pontos que normalmente salva mais tempo do que custa. Pelo menos se você tem pelo menos alguma experiência com ele.

Estou ciente de que muito disso já foi mencionado, mas já que é uma questão bastante subjetiva, eu queria acrescentar a minha classificação.

[inserir clichê ressalva específica não-OOP aqui]

A separação de interesses, testes unitários, e aquela sensação de que se algo é complexo demais provavelmente não é muito certo ainda conceituada.
UML esboço: este esclareceu e salvo qualquer quantidade de esforço desperdiçado tantas vezes. Imagens são grandes não são? :)
Realmente pensando é-A e tem-um do. Obtendo este primeiro momento certo é tão importante.

Não importa quão rápido a empresa quer, eu praticamente sempre tentar escrever código para o melhor de minha capacidade.

Eu não acho que é preciso mais tempo e, geralmente, poupa muito tempo, mesmo no curto prazo.

Eu tenho não me lembro de escrever código e nunca olhar para ele de novo, eu sempre fazer alguns passes sobre ele para testar e depurar-lo, e mesmo naqueles poucos práticas passa como refatoração para manter a minha DRY código, documentação (até certo ponto), separação de interesses e coesão todos parecem para economizar tempo.

Isto inclui crating muitos mais turmas pequenas do que a maioria das pessoas (Uma preocupação por classe, por favor) e muitas vezes extrair dados de inicialização em arquivos externos (ou matrizes) e escrever pequenos analisadores para que os dados ... Às vezes até mesmo escrever pequenos GUIs em vez de edição de dados com a mão.

Codificação em si é bastante rápido e fácil, a depuração porcaria alguém escreveu quando eles estavam "sob pressão" é o que leva o tempo todo!

Em quase um ano no meu projeto atual eu finalmente configurar uma compilação automatizada que empurra quaisquer novos commit no servidor de teste, e o homem, eu gostaria de ter feito isso no dia um. O maior erro que cometi no início-on foi indo escuro . Com todos os recursos, realce, de correção de bugs etc, eu tinha um mau caso das "apenas uma mores" antes de eu deixar ninguém ver o produto, e literalmente em espiral em um ciclo de seis meses. Se cada mudança razoável tinha sido automaticamente empurrado para fora, teria sido mais difícil para mim esconder, e eu teria sido mais no caminho certo no que diz respeito ao envolvimento das partes interessadas.

Volte para o código que você escreveu alguns dias / semanas atrás e passar 20 minutos revendo seu próprio código. Com o passar do tempo, você será capaz de determinar se o seu código "off-the-cuff" é organizado bem o suficiente para os esforços de manutenção futura. Enquanto você está lá, olhar para refatoração e renomeando oportunidades.

Às vezes acho que o nome que escolhi para uma função no início não se encaixam perfeitamente a função em sua forma final. Com as ferramentas de refatoração, você pode facilmente mudar o nome início antes de entrar em uso generalizado.

Assim como todo mundo tem sugerido estas recomendações não são específicos de OOP:

Certifique-se de comentar o seu código e usar variáveis ??de forma sensata nomeados. Se você sempre tem que olhar para trás sobre o código rápido e sujo que você escreveu, você deve ser capaz de compreendê-lo facilmente. Uma regra geral que eu sigo é; se você excluiu todo o código e só tinha os comentários à esquerda, você ainda deve ser capaz de compreender o fluxo do programa.

Hacks geralmente tendem a ser complicado e não-intuitiva, de modo algum bom comentando é essencial.

Eu também recomendo que se você geralmente tem que trabalhar com prazos apertados, obter-se uma biblioteca de código construído com base em suas tarefas mais comuns. Isso permitirá que você para "juntar os pontos" em vez de reinventar a roda cada vez que você tem um projeto.

Saudações,

Docta

Uma prática OOP real eu sempre tempo para fazer é a Responsabilidade Individual Princípio , porque se torna muito mais difícil adequadamente refatorar o código mais tarde, quando o projeto é "ao vivo".
Aderindo a este princípio eu acho que o que eu escrevo código é facilmente reutilizados, substituído ou reescrito se não conseguir corresponder às exigências funcionais ou não funcionais. Quando você acabar com classes que têm múltiplas responsabilidades, alguns deles podem preencher os requisitos, alguns não podem, e toda pode ser inteiramente claro.
Esses tipos de classes são estressante de manter, porque você nunca está certo de que sua "correção" vai quebrar.

Para este caso especial (prazos curtos e com lotes de código que nunca serão usados ??novamente) Eu sugiro que você preste atenção à incorporação de algum mecanismo de script em seu código OOP.

Aprenda a "refatorar as-you-go". Principalmente a partir de um "método de extrair" ponto de vista. Quando você começar a escrever um bloco de código seqüencial, demorar alguns segundos para decidir se este bloco poderia stand-alone como um método reutilizáveis ??e, em caso afirmativo, fazer esse método imediatamente. Eu recomendo mesmo para projetos do throw-away (especialmente se você pode voltar mais tarde e compilar esses métodos em sua API caixa de ferramentas pessoal). Não demorou muito antes de você fazê-lo quase sem pensar.

Esperamos que você já faz isso e eu estou pregando para o coro.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow