Quando um profissional trabalha com uma tecnologia, dominá-la significa ser eficiente e eficaz. É isso o que as empresas e os clientes buscam. Eficiência e qualidade. Simples assim!
Quanto a maior ignorância que temos com a relação a algum assunto, menores são as chances e as possibilidadades e, no caso dos negócios, isso quer dizer SUCESSO ou até FRACASSO.
Exemplo prático do que digo.
Encontrei a seguinte rotina de validação do formato de placa de identificação de veículo (formato: XYZ1234).
public static boolean isValid(String placa) {
String letras = extrairLetras(placa);
String numeros = extrairNumeros(placa);
if (letras == null || numeros == null) {
return false;
}
if ( letras.length() != 3 || numeros.length() != 4 ) {
return false;
}
// verifica se a variável letras contém apenas letras [A-Z]
if (Character.isDigit(letras.charAt(0)) ||
Character.isDigit(letras.charAt(1)) ||
Character.isDigit(letras.charAt(2))) {
return false;
}
// verifica se a variável numeros contém apenas números [0-9]
if (!Character.isDigit(numeros.charAt(0)) ||
!Character.isDigit(numeros.charAt(1)) ||
!Character.isDigit(numeros.charAt(2)) ||
!Character.isDigit(numeros.charAt(3))) {
return false;
}
return true;
}
Sabe como eu resolveria este mesmo problema? Assim:
public static boolean isValid(String placa) {
return placa.matches("[A-Z]{3}[0-9]{4}");
}
Eficiência e eficácia em apenas 1 (UMA) linha de código. Melhor que cerca de 20 linhas.
Portanto, busquem conhecimento, busquem saber e aprender. Quanto mais sabemos, percebemos as possibilidades e conseguimos fazer mais, com menos.
a) Falta a documentação - para entender para o que serve (a parte mais importante da documentação, a meu ver) é necessário ficar debugando o código, se você não tiver confiança nas rotinas “extrairLetras” ou “extrairNumeros” - sabe como é que é, eu já me queimei ao confiar em rotinas cujo nome era enganoso. Quem disse que isso é para validar uma placa de carro :?:
b) Muito comprido e verboso.
Realmente quando a gente vê uma coisa dessas dá vontade de jogar tudo fora e pôr a seguinte coisa:
/**
* Uma placa de carro, com 3 letras e quatro dígitos. Exemplos: "ABC-1234", "ABC1234"
*/
private static Pattern placaCarroPattern = Pattern.compile ("[A-Z]{3}-?[0-9]{4}", Pattern.CASE_INSENSITIVE);
/**
* Valida uma placa de carro.
* @param placa Uma placa de carro, no formato "ABC-1234" ou "ABC1234"
* @return true se válida.
*/
public static boolean isValid(final String placa) {
return placaCarroPattern.matcher(cleanup(placa)).matches();
}
Adicionalmente deve ser bem mais rápido que o código original
Se você tem um sistema de controle de versões, você pode pode obter um relatório das alterações e os sucessivos autores e mantenedores do código. Pôr um tag “@author” é duplicar a informação.
Ah, boa Destro!O mesmo aconteceu comigo há um tempinho atrás: recebi um componente swing para tipos monetários com + de 500linhas que vez ou outra, travava legal(eram dezenas).Troquei por um(se não me engano, modifiquei um daqui do fórum mesmo) com umas 50 linhas, que além de fazer a mesma coisa, não travava.
Temos que analisar nesse caso o fator tempo de desenvolvimento.
Se fosse algo do tipo: “você tem 15min pra fazer isso funcionar” + “não conhece direito as APIs” + “tá trabalhando 12 horas por dia” aí acho que esse código aí se justifica.
Tem alguns casos (acredito que não seja esse aí no exemplo) que saímos do uso da API convencional buscando performance.
Infelizmente, eu tô vivendo isso “de perto”.Eu tenho um monstrinho em swing aqui com 5500 linhas(só de tela principal com tabbedpane de 6 abas).Refatorei, e dividi cada aba(JPanel) em classes menores, mas não obtenho a mesma performance do que o “Voltron”(o monstro unido).O chato, é que a app é para rodar em maquinas lentas(só há uma rapida de 256MB de RAM).
Houve caso que foi ao contrário.
Eu sabia exatamente que era mais fácil fazer com pattern matching, mas fui obrigado a fazer algo parecido (é claro que não tão tosco) por causa que eu tinha de usar Java 1.1 (applets) ou 1.3 (iPlanet).
[quote=boaglio]
Temos que analisar nesse caso o fator tempo de desenvolvimento.
Se fosse algo do tipo: “você tem 15min pra fazer isso funcionar” + “não conhece direito as APIs” + “tá trabalhando 12 horas por dia” aí acho que esse código aí se justifica.
Tem alguns casos (acredito que não seja esse aí no exemplo) que saímos do uso da API convencional buscando performance.[/quote]
Eu tenho a mesma linha de raciocínio, eu prefiro nunca criticar um código, porque eu dificilmente vo saber qual era a situação da pessoa naquela momento, além do mais eu sinto que refactoring e a melhora na qualidade de código é uma coisa cíclica e que nunca vai acabar, por mais que vc mexa sempre vai ter uma coisa ou outra pra se melhorar…isso pode ser ruim ou bom, depende do ponto de vista de cada um! rs
