O Guia Prático para Escrever Menos Código

09/01/2013

Esta é a tradução de parte da apresentação Minimalism – A practical guide to write less code de Kevlin Henney.

Refatoração, Reparação e Recuperação do Controle

0. Siga a Forma

• Adequar o idioma no código deve ser seguido para melhorar a comunicação. Dialetos reduzem a compreensão geral.
• Mas expressões não devem ser seguidas servilmente se fizerem pouco sentido ou prejudicarem a qualidade.

1. Não Quebre Contratos

• Métodos têm um contrato para seu uso. Afirmações podem ou não serem suficientes para executar o contrato totalmente.
• Subclasses e interfaces implementadas devem seguir a substitutabilidade. Operações não suportadas ou operações que fazem um pouco menos ou esperam por mais adicionam complexidade.

2. Inclua apenas o que precisa

• Uma classe tipicamente define uma interface apoiada por uma implementação. Separa-se o tipo de uso do tipo de criação.

3. Expresse idéias independentes, independentemente

• Normalize dependências. Consolide listas de argumentos comuns e papéis dissociados dentro das interfaces.
• Cuidado com as camadas porosas e código avulso acoplado. Wrapping fraco e dependências de pacotes cíclicos propagam dependências desnecessariamente.

4. Parametrize Sobre

• Pacotes globais, singletons e pacotes de constantes devem ser racionalizados ou eliminados. Eles introduzem acoplamento coincidêntes, portanto, o código é menos adaptável e mais difícil de testar.
• Use argumentos e interfaces para inverter dependências.

5. Gerencie os Recursos Simetricamente

• Garbage collection é insuficiente para qualquer outro recurso além da memória. E mesmo assim, ele pode ser menos do que perfeito.
• Gestão dos recursos deve ser explicitamente equilibrada ou totalmente encapsulada. Considere o uso de objetos de bloco para envolver o uso de recursos.

6. Encapsule

• Encapsulamento é mais do que apenas esconder dados. Auto-contenção inclui segurança de exceção, segurança de thread, facilidade de uso, transparência, etc
• Encapsulamento reduz as possibilidades.

7. Flua não pule

• Salto no controle de fluxo deve ser usado com moderação. É fácil ficar viciado em break e returns – e continue o goto (quando existe). Throw é uma exceção.
• Controlar o fluxo que não flui pode ser difícil de compreender e refatorar. Programação estruturada não é completamente morta.

8. Afie a Lógica Difusa

• Muitas práticas de codificação verbosa são justificadas por simplificarem a depuração. Isto é resolver o problema errado.
• Álgebra booleana não é ciência de construir foguetes. Embora você possa usá-la para esse fim.

9. Código Redundante é um Aviso

• Código pode ser menos do que a soma das suas partes. Código redundante é um código que não tem nenhum efeito real.
• O ato do código redundante é como uma lombada para a compreensão – remova-o. Código inacessível, sincronização non-thread, código afetado, código não utilizado, etc.

10. Deixe o Códido Fazer as Decisões

• Não há necessidade de explicar tudo nos mínimos detalhes. Fluxo de controle torna-se uma colcha de retalhos de casos especiais.
• O código pode também parecer para fazer mais do que a soma das suas partes. Polimorfismo, tabelas de pesquisa, ações agrupados em collections, double dispatch, etc

11. Considere Código Duplicado como um Engano

• Um monte de programadores sofrem de um caso persistente do código repetido. Código duplicado é capim onde os erros prosperam.
• Duplicação visível é um problema melhor resolvido por refatoração comungada. Em uma classe, um método ou um bloco evidente por lógica mais clara.

12. Prefira Código à Comentários

• O código que não é o código precisa de um papel claro. A maioria dos comentários não se qualificam.