quinta-feira, 10 de abril de 2014

Modularizações e soluções com Factories

OMMMMMMMMMMMMMMMMMM ("Chubaca gritando porque a coisa realmente é soda povo.").

Estando a quase a 15 anos na área de desenvolvimento, ainda me espanto com a falta de planejamento e de reaproveitamento de códigos utilizadas pela T.I brasileira. Independente de linguagens, ou soluções de paradigmas das mesmas, ainda me enlouqueço quando vejo que as pessoas gostam de reescrever os mesmos códigos e gerar vários erros, sem nem mesmo pensar numa simples solução de bibliotecas, ou comunização de códigos.

As linguagens ao longo desse tempo evoluíram demais, temos hoje linguagens com paradigma orientação a objetos, que acaba facilitando e muito a vida dos desenvolvedores, nelas temos várias facilidades tais como: Garbage Colector, Herança, Polimorfismo, Camadas, Modularizações desacopladas, Factories de acesso a camada de dados, Frameworks ORM, entre outras coisas. O que verificamos no mercado é uma verdadeira precariedade de códigos, isso ocorre devido, a: falta de tempo, as definições erradas de escopos, por requisitos mal levantados. O fato é que realmente eu não consigo entender e aceitar as propagações de xunxos e soluções péssimas, que normalmente vão precisar de várias manutenções e muitas das vezes acabam transformando os códigos em colchas de retalhos. Afinal para que contratar um arquiteto de software? O meu vizinho faz, ele sabe: "formatar a máquina".

Creio que a solução para nosso mercado é bem aquilo que vem de encontro ao título do meu post, isto é, a utilização de Modularizações e Factories na construção dos sistemas. Esses tem seu procsso de criação  tão complexos quanto a fabricação carros, ou a construções de prédios. Os sistemas requerem muito conhecimento técnico, e uma profunda análise do seu "business", para que o sua formulação seja feita de forma estável e escalonável, atendendo a demandas crescentes. Tenho absoluta certeza que muitos que lerem esse texto, vão recordar algumas pérolas nos códigos que já tiveram que fazer, ou ajustar.

Quero em outro post colocar o tema de forma mais abrangente, mas nesse fica essa essa questão tão enfadonha, Porque não adotar metologias? Porquenão adotar formas de construção padrão para o desenvolvimento de software? Será que é tão mais caro assim? Eu realmente tenho certeza que não.

Abraços até o próximo post.
Rafael Sandim Krezschmar

2 comentários:

  1. Infelizmente o POG ainda reina em grande parte dos casos - isso sem falar do Extreme Go Horse. É aquela: compilou e funcionou tacam o foda-se.

    ResponderExcluir
    Respostas
    1. Exatamente, aquela máxima "em time que está se ganhando não se mexe", é o cumulo do ridículo, não somos ainda reconhecidos da forma profissionalmente que devemos e isso se deve a esse mercado e esse jeitinho de fazer software BR.

      Excluir