Tirada do d00dz.org

Solução clássica de desenvolvedor.

O cara implementa uma caixa-dágua daí um dia um usuário reclama de uma poça em baixo.

O desenvolver detecta que há um vazamento  e começa a limpar todo dia.

Quando enche o saco ele implementa um balde, quando cansa de descarregar o balde, ele implementa uma bomba que suga água do balde e joga de vola na caixa-dágua.

Pronto!

Problema permanentemente solucionado.

Sistemas engessados são uma das piores pragas de TI. Custam rios de dinheiros para os clientes.

Às vezes construir um sistema engessado (hardcoded) é bem rapidinho e funciona na hora. Mas ai acontece que aquela regrazinha de validação de um campo mudou. Por exemplo agora pode aceitar números e letras e não apenas letras.

Ai você pensa: Beleza, vamos apenas reconfigurar esta regra de validação. Mas é neste ponto que os sistemas engessados cobram seu preço.

Fazer qualquer alteração envolve mexer em código e por isso tem custos mais altos porque tem analise de impacto, desenvolvimento, testes e validações. E tudo isso com os enormes riscos de mexer em código de péssima qualidade (sistemas engessados geralmente têm péssimo código).

Por outro lado querer fazer um sistema super ultra mega flexível custa caro e demora. E nem sempre este custo pode ser justificável. Vi muito disso em arquitetura J2EE de alguns anos atrás que queriam ser super flexíveis, que os tornavam extremamente complexos e em 90% das vezes esta flexibilidade não era necessária.

Então qual o caminho?

O do bem senso. Apenas não tente engessar seu sistema. Se tiver alguma coisa que pode ser configurado em runtime, deixe esta configuração em runtime. Nunca, mas nunca mesmo coloque magic number ou magix strings em código. Nem mesmo com constantes ou #defines.

E o pior é que tem fornecedores, que por pura mesquinharia, engessa o código a fim de manter o cliente em sua mão.

Você sabe que alguma coisa mudou na sua carreira de desenvolvedor quando seu desktop tem 256Mb (e isto não é problema), suas principais ferramentas de trabalho são o Outlook e o Excel e você faz esta compra.  

Este começo de ano de 2008 vai ter muita coisa nova para mim, literalmente.

Estou mudando de emprego, pela primeira vez vou sair da linha de frente de desenvolvimento e vou para a linha de frente na análise de requisitos e negócios full time. Em outra palavras, não vou ser mais pago para codificar.

Sabe aquela histórinha de "novos desafios"? Então, desta vez, para mim, vai acontecer literalmente.

Sei que não vai ser fácil, mas o amadurecimente não é facil, e é isto que eu estou procurando: amadurecimento profissional.

Eu, internamente, me vejo uma pessoa de muitas facetas. Não necessáriamente tenho planos para diversas carreiras, mas eu me vejo com interesses em muitas áreas *.

E tenho um especial interesse na área de desenvolvimento de softwares, que é minha praia faz alguns anos. E sei que o desenvolvimento de software não se resume a codificar, e é justamente estas outras praias do litoral do desenvolvimento de softwares que eu quero não só conhecer, mas pegar algumas ondas também.

 Espero manter os textos sobre desenvolvimento aqui no Blog, mas acho que com o tempo eles se tornaram menos técnicos. Ou não ;-)

* Especialmente música, especialmente Rock. Eu sempre brinco (mas com um grande fundo de verdade) que seu eu tivesse o minimo de dom para música eu não seria outra coisa a não ser músico. Mas minhas habilidades para musica são muito abaixo de pifias. :-)

Um pouco mais sobre o Pattern Repository, discutido aqui no blog mesmo aqui. Não diria que é uma continuação sobre o assunto, mas uma evolução.

Desta vez vamos criar um Interface especifica para o repositórios de forma que ela seja mais próxima com a defilição de um Repository descrita pelo P of EAA.

Estas diferenças entre DAO e Repository as vezes são um pouco dificeis de pegar, e na verdades estes meus textos são uma ajuda para eu mesmo entende-las. :-)

Ler mais...