Muito ja li sobre padrões de como os métodos devem ser feitos , ja vi muito código de outros programadores e também os meus códigos antigos, com base nessa experiência vou listar os pontos positivos e negativos que ja vi nesses quase 10 anos de profissão:
Métodos com mais de 100 linhas, porque:
Nunca Faça
- Nem você vai entender o código direito depois de duas semanas
- Dificil entendimento , terrível para dar manutenção
- Mais dificil de evoluir
- Está fazendo mais do que o nome do método Diz …
Tente Fazer
- Métodos que possam ser lidos na resolução de 1024 sem precisar de scroll
- Crie métodos auxiliares para decompor o código, assim fica facil de melhorar e debugar problemas
- O código do método deve fazer o que o nome sugere assim o código fica de facil entendimento , ficando quase auto documentado
Métodos com 30 parametros
Nunca Faça
- Fica complicado de ver todos os parametros. Provavelmente você esteja fugindo da orientação a objeto
- Fica facil inverter a ordem de algum valor e daí haja debug para achar o erro
Tente Fazer
- Procure criar objetos e passar os objetos para o método ou trabalhar com propriedades
Duplicação de código Ctrl + C , Ctr + V
Nunca Faça
- Código duplicado significa dois lugares para corrigir e/ou melhorar
- Torna o código mais extenso do que o necessário
- Aumenta em muito as chances de bug na aplicação, pois qualquer alteração tem que mapear os lugares onde o código esta duplicado
Tente Fazer
- Quando precisar de uma funcionalidade que esta embutida em algum método, extraia a mesma para um método separado
- Métodos com poucas linhas tendem a ser reutilizados, pois são bem especializados numa tarefa
Regra de Negócio utilizando exception
Nunca Faça
- Utilizar exception para regra de negócio degrada a performance
- Falta de planjemanento
Tente Fazer
- Trabalhe com o envio de mensagens
- Planeje a troca de mensagens, para facilitar tanto a camada de negócios como a interface da aplicação
Arquitetura e Desenvolvimento de Software 