terça-feira, março 20, 2007

OOA&D é Perigoso

Quando a gente faz análise e projeto orientado a objeto (OOA&D, para quem gosta de sopa de letrinhas), normalmente tem de fazer opções: que base de dados usar? Postgres? MySQL? MSSQL Server? Oracle? Todas? Nenhuma?

Dentro da mesma linha de raciocício, precisamos escolher e tomar decisões sobre que formas de autenticação utilizar (password? challenge-response? chaves criptográficas?), que arquitetura geral nosso sistema vai ter (MVC? Client-Server? Ambas? Outras?), e, lentamente, de escolha em escolha, vamos definindo um contrato, uma interface para o sistema, que vamos ser obrigados a seguir sem alterações por muito tempo depois do projeto ter terminado.

Este "projeto por contrato" é o que eu acredito ser o maior perigo do OOA&D. Quando a gente começa a estabelecer contratos sem muito critério, nos comportamos como crianças que jogam aqueles jogos de embaralhar mãos e pés sobre um tabuleiro no chão, conforme se sorteiam cores, numeros ou formas. E, eventualmente, todas as crianças vão perder o equilíbrio e cair no chão, umas enroladas nas outras.

A diferença é que, quando um engenheiro de software incauto faz isso, não tem graça nenhuma, e, normalmente, não é possível desembaralhar mãos e pernas e começar novamente o jogo.

Assim, quando eu digo "tomem cuidado com OOA&D", é por que, em determinada altura da vida, eu comecei a reparar que a gente toma decisões e implementa coisas que são nojentas, simplemente por que é a única forma "lícita" de se fazer isso sem quebrar os contratos que foram estabelecidos até o momento.

Claro, seu chefe nunca quer saber de nenhum contrato quebrado: se você não implementar as coisas em tempo, ele simplesmente te joga na rua e coloca outro incauto ali, que vai xingar, criticar, adaptar, escrever, pesquisar, tentar reformar, e... aderir ao contrato. Pelo menos, desta forma, não quebramos o "software legado" vão te dizer. Não é preciso fazer força, já veio quebrado "de fábrica"...

Nenhum comentário: