Desenvolvedores, programadores e adeptos, ao desenvolver aplicações e sistemas, há algumas guias que nos ajudam a criar um bom código, fácil de manter, de entender e que outros programadores vão poder mexer caso necessário. O primeiro passo para isso é o uso de Orientação a Objetos. Mas mesmo dentro deste, há alguns conceitos importantes de serem colocados. Eis alguns pontos, ainda rascunhados, que é bom ter em mente:
- Tempo
- Fácil manutenção
- Fácil de entender: O código é semântico, sem confusões e se auto-explica. Comentário apenas onde é necessário. O Código se auto-documenta.
- Fácil de testar: Unidades simples, reuso, testes automatizados. É mais fácil testar pequenas unidades.
- Modularidade
- Acoplamento: Baixo acoplamento, permite melhores testes mais independência do código e maior reuso.
- Dependência: Use apenas onde necessário.
- Isolar mudanças: Segurança com testes. Mudanças de framework, de infraestrutura.
- Não se exponha muito
- Independência de implementação: Mudanças na implementação, no código de um método, não afeta o comportamento de onde usa este método.
- Privado / Público: Propriedades privadas, assessores públicos. Protege as informações.
- getters e setters: Muda a implementação, a fonte de dados, a regra de negócio. Ficam os assessores, a interface.
- Responsabilidade
- Sempre retorne algo significante: Evitar retornar null. Interface encadeada. No mínimo, retorne boleano.
- Trate entradas inválidas: Não confie no resto do código. Valide sempre. Trate Nulos. (Especial foco em linguagem de tipo dinâmico/fraco)
- Cuide de seus erros internamente: Use exceções com significado.
- Interfaces
- Exponha suas interfaces: Maior reuso, maior independência. Evitar acoplamento especifico.
- Use interfaces com significado: Código é documentação.
- Padrões
- Pense em padrões: Resolver problemas de forma padronizadas. Nem sempre são os "Padrões de Projetos"(design patterns).
- Use herança corretamente: Cuidado com armadilhas por facilidade de uso. Herança tem que fazer sentido. Evite BigFuckingClasses.
- Use composição corretamente: Composição sobre herança. Corrente de responsabilidade, interfaces e acoplamento.
Ficou bem confuso...e ainda existe muito mais. Eu uso a seguinte métrica para saber se a modelagem esta legal: Se eu consigo explicar de forma clara o por que de ser assim, é por que esta no caminho. Se complicar para explicar/desenhar o modelo, é por que esta ruim.
- Comments
-
|2009-01-08 10:10:13 Chris BenselerBati o olho na imagem e tive faniquitos: precisei colocar 2 assistentes meus pra fazer documentação de controllers e services de uma aplicação java (e olha que minha equipe nem trabalha com isso, cuidamos da parte de interface/front-end) em javadoc...d e código de, tipo, 2 anos atrás. Pq os programadores java não o fizeram e um cliente preciava. Foi bom meu Natal/Ano-novo... hehe
-
|2009-01-08 12:46:56 adminDocumentar enquanto desenvolvemos é normal, mas documentar(doc-comentar?) depois que o sistema esta pronto, sem ser manutençao e tal, é uma ME***! Nem imagino em um sistema que nem foi feito por vcs. Mas que presentão hein, hehe.
-
|2009-01-08 15:29:15 Chris BenselerO bizarro na verdade é ter que documentar algo que você não fez, que não é nem da tua área, só pq o dono da empresa precisa dessa documentação ASAP... hehe
Powered by !JoomlaComment 4.0alpha3
