Indignado, crio este tópico, para os javas iniciais não cometerem os erros que postarei neste tópico.
Estes códigos são tirados de “profissionais” que cobram de uma empresa a quantia de R$ 80,00 hora.
Vamos para a primeira:
Geracao de xml com StringBuffer (Showww!!!), acredito que eles não conheçam Jdom, jaxb… e milhares formas. Mas o que chamou a atenção é que o arquiteto disse que o sistema é internacionalizado e esta atendendo as linguas portugues Brasil e Ingles, mas encontrei a seguinte linha:
Esse tipo de tópico é bom para que não só iniciantes, mas todos possamos aprender boas práticas de programação…
além da acentuação, o que mais preocupa é o nome da variável ser variável… 50 linhas de código depois, alguém se perderia facilmente nesse código (quem sabe até quem o escreveu também)…
Uma dessas práticas que vejo com bastante frequência é a repetição de código, também chamada de “Reutilização por Ctrl+C,Ctrl+V”.
Exemplo 1:
Uma aplicação em que trabalhei (na época nem era em Java), tinha esses métodos:
fazAlgumaCoisa(byte[] parametro)
fazAlgumaCoisa(String parametro)
fazAlgumaCoisaLigeiramenteDiferente(byte[] parametro)
fazAlgumaCoisaLigeiramenteDiferente(String parametro)
Cada par fazia a mesma coisa - apenas com outro formato de entrada - e os de baixo também faziam quase igual aos de cima, só uma chamada diferente. A implementação desses métodos estava inteirinha copiada em cada um deles.
Exemplo 2:
Em um sistema web, havia duas páginas do tipo: exibePedidoPessoaFisica.jsp e exibePedidoPessoaJuridica.jsp
A diferença entre elas estava na área de “Dados do cliente”, que apresentava alguns campos diferenciados.
Acontece que as duas páginas foram inteiramente duplicadas, inclusive seus backing-beans com todo o código.
Os juros do débito técnico continuam sendo pagos até hoje, pois todas as manutenções tem que ser replicadas.
isso mesmo, um projeto com previsão de chegar a 500 user simultaneos em uma empresa de capital aberto.
O projeto é para ser o sistema de ciclo de vida de produtos da empresa e acreditem
Sem a devida validação da variável ainda terá usuário digitando 1.000,50 (Nunca dúvide da capacidade dos usuários) a variável dele ainda continuará dandos erros. O mais engraçado é que isso foi feito provavelmente com a idéia de que estaria ganhando tempo. (rapidin… cagadin…)
[quote=ViniGodoy]http://www.guj.com.br/posts/list/30384.java
E evitem duplicar tópicos. [/quote]
Vini,
Na minha opinião os tópicos são diferentes, aquele mais antigo fala de erros grotescos, as chamadas “pérolas”, é mais pra rir mesmo…
Já esse aqui trata de situações comuns, erros que qualquer um - especialmente os pouco experientes - pode acabar cometendo.
Acabaram surgindo posts do primeiro tipo, mas acho que o objetivo do tópico não era esse.
Eu já ví em um sistema Java variáveis com nomes $0, $1, $_ e mais umas coisas malucas. É bem coisa do tipo: complique o código para que nunca outro possa dar manutenção. E mesmo que vocês duvidem o compilador javac aceita esses nomes.
Mas em um grande banco gaúcho ví um método efetuarTransação(), hahahahaha.
[quote=gomesrod][quote=ViniGodoy]http://www.guj.com.br/posts/list/30384.java
E evitem duplicar tópicos. [/quote]
Vini,
Na minha opinião os tópicos são diferentes, aquele mais antigo fala de erros grotescos, as chamadas “pérolas”, é mais pra rir mesmo…
Já esse aqui trata de situações comuns, erros que qualquer um - especialmente os pouco experientes - pode acabar cometendo.
Acabaram surgindo posts do primeiro tipo, mas acho que o objetivo do tópico não era esse.[/quote]
É, tem razão… heheheheh
Na verdade, tem alguns erros bastante cabulosos, e muito comuns, só para citar alguns:
Em Java 2D, usar a classe Graphics recebida por parâmetro diretamente, sem se preocupar com as alterações de estado feitas na própria classe;
Em BDs, fechar a Connection esperando que isso feche os Statements;
Em BDs, não fechar connections e statements em blocos finally;
Em Swing, usar qualquer model iniciado pela palavra “Default”: DefaultTableModel, DefaultComboBoxModel, DefaultListModel, DefaultMultableTreeNode;
Criar arquivos texto usando as classes de OutputStream, ao invés das Writers;
Usar ObjectOutputStream para sockets;
Passar “this” como parâmetro no método de alguma classe, sendo que esse this está no construtor;
public class Xyz {
public Xyz() {
Abc abc = new Abc(this); //this não foi completamente construído ainda!
}
}
8. Usar sets ou gets não finais no construtor;
9. Atribuir diretamente objetos a atributos em sets, sem fazer sua cópia (especialmente listas);
Quanto a usar xml através do StringBuilder. Para xmls simples, pode ser uma boa alternativa, caso ele tenha que ser gerado rapidamente. As vezes também é necessário gerar SQL através do PrintWriter diretamente quando o seu conteúdo for enorme. A maior parte das APIs de xml trabalha diretamente em memória, o que pode restringir muito a geração.
Gostaria também de lembrar sobre as classes HIGHLANDER - SÓ PODE HAVER UMA. Aqueles códigos onde existem classes monoliticas onde praticamente tudo teoricamente é feito nelas, view, componentes, acesso ao banco de dados, validação etc…
