Desconhecer a Tecnologia Pode Custar Caro

16 respostas
danieldestro

Caros,

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 dica!

16 Respostas

RaulCarlin

Hehehe, é verdade…

Ah, eu colocaria um toUpperCase() ali também…

T

O código que você encontrou tem dois problemas:

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 :stuck_out_tongue:

T

RaulCarlin:
Hehehe, é verdade…

Ah, eu colocaria um toUpperCase() ali também…

A rotina “cleanup” que o Daniel invocou deve ser algo como :

public static String cleanup (String str) {
    return str.trim().toUpperCase().replaceAll("[^A-Z0-9]", "");
}

mas não sei exatamente como ela deveria ser.

RaulCarlin

Não esqueça do @author

T

Muita gente desaconselha usar o “@author” se há um sistema de controle de versões como o CVS ou o Subversion. É melhor não ficar repetindo informação.

danieldestro

Por simplicidade… o código original é bem documentado.

Eu tirei o cleanup, mas era mais ou menos isso o que você fez.

RaulCarlin

Como assim repetir?

T

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.

Ironlynx

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.

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. :slight_smile:

Tem alguns casos (acredito que não seja esse aí no exemplo) que saímos do uso da API convencional buscando performance.

Ironlynx

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).

T

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).

albertongai

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. :slight_smile:

Tem alguns casos (acredito que não seja esse aí no exemplo) que saímos do uso da API convencional buscando performance.

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

Fui

peczenyj

Existe uma flag para trabalhar com expressões regulares em ignorecase: (?i)

Fazer toUpper pode incorrer em erros, principalmente se vc estiver trabalhando com ambientes globalizados (como algumas letras Turcas).

T

peczenyj:
Existe uma flag para trabalhar com expressões regulares em ignorecase: (?i)

Fazer toUpper pode incorrer em erros, principalmente se vc estiver trabalhando com ambientes globalizados (como algumas letras Turcas).

bush

É difícil escrever até o menor fragmento de código corretamente.

Criado 11 de outubro de 2007
Ultima resposta 11 de out. de 2007
Respostas 16
Participantes 8