egomesbrandao, blog

Antes de postar o próximo post do ABC App eu quero comentar sobre dois acontecimentos.

Dia 26 de setembro aconteceu mais uma reunião do grupo DNA (.NetArchitects), o tema foi PMI X Scrum. O objetivo era fazer uma mesa redonda em que cada um dos lados tivesse defensores em que apresentassem a sua defesa pelo uso de um ou do outro. Infelizmente,  do lado do PMI nossos convidados não apareceram, o nosso grupo DNA, é praticamente 100% a favor do Scrum, então dois se ofereceram para defender a visão do PMI:  André Dias (http://blogs.msdn.com/andredias/, siga @andrediasbr) e Victor Cavalcanti (http://www.cavalcante.net, siga @vcavalcante), do lado do Scrum ficou o Giovanni Bassi (http://unplugged.giggio.net, siga @giovannibassi).
Fora a frustração evidente do André e do Victor, de ter que defender o PMI o papo foi muito legal. O que tirei da conversa:

• O PMI é velho! Hoje estamos cada vez mais dinâmicos, aplicações são escritas por pessoas que não são desenvolvedores em suas horas vagas, arrancando pedaços de participação de mercado de empresas, e por conta disso,  precisamos de mais velocidade; então por quê continuar com algo que é lento? Onde precisamos de controle vamos controlar, onde não precisamos de controle não vamos controlar! (do manifesto ágil: Individuals and interactions over processes and tools)
• Se precisamos cada vez mais de velocidade , é por que precisamos de software pronto o mais rápido possível, tanto para atender uma demanda de mercado, como uma mudança de negócio de uma empresa; então por quê perder tempo com o que não é essencial? Com o que não vai trazer ROI? Vamos entregar! (do manifesto ágil: Working software over comprehensive documentation)
• Se precisamos de software rápido e funcionando, precisamos de pessoas capacitadas, treinadas, focadas, interessadas para desenvolver. Então por quê não valorizamos esses profissionais? Por quê esprememos deles coisas inúteis como cumprimento de horário, vestuário, entre outras coisas? Vamos deixar as pessoas trabalharem confortavelmente, vamos investir nos bons profissionais, vamos recompensar quem traz ganhos para a empresa! (do manifesto ágil: Individuals and interactions over processes and tools)
• Para isso tudo acontecer precisamos ser dinâmicos, não nos fechar, não entrarmos em uma bolha, tratar funcionários e clientes como parceiros; Por quê então tornamos eles nossos inimigos? Vamos construir pontes, ao invés de derrubá-las! (do manifesto ágil: Responding to change over following a plan)

Scrum é isso, nada mais que isso, o que falta aí é documento Product Backlog e as cerimônias de planejamento, reunião diária, e de finalização do Sprint. Precisamos mais do que isso para entregar um software? Não precisamos escrever extensos documentos que nunca serão lidos, não precisamos ficar montando cronogramas de coisas que não podemos prever, não precisamos ter alguém para mandar, só precisamos deixar que foi contratado para fazer o trabalho… trabalhar!

Quem quiser saber o que rolou na reunião veja pelo link do livemeeting, o André Dias também fez um post muito legal, tem até uma colagem de uma conversa com o @RenatoFerracini que rolou no twitter.

O outro assunto é sobre o mais novo episódio do podcast do .NetArchitects , que falamos sobre a profissão de Arquiteto, o assunto foi muito legal e vamos voltar a falar sobre ele com certeza! Assine o feed, ouça e comente!

Ainda essa semana sai o próximo post…

O desenvolvimento em 3 camadas, pedido em tantas vagas de emprego, em projetos de software, tanto discutido e difundido em fórums, livros e revistas de TI é uma verdadeira falácia!

falácia¹
fa.lá.cia¹
sf (lat fallacia) 1 Qualidade de falaz. 2 Engano, logro, burla. 3 Sofisma.

sofisma
so.fis.ma
sm (gr sóphisma) 1 Lóg Raciocínio capcioso, feito com intenção de enganar. 2 Argumento ou raciocínio falso, com alguma aparência de verdade. 3 pop Dolo, engano, logro.

Antes de começarmos a codificar alguma coisa, é bom um pouco de história para nos situarmos ! O termo foi difundindo erradamente. Vamos começar do começo e por partes, ou camadas , se preferir.

Tive um primeiro contato com o termo desenvolvimento em camadas por volta do ano 2000. Na época, uma das linguagens mais usadas era o Visual Basic 6.0, o Java estava crescendo, e o Delphi era bem usado. A Microsoft recomendava o uso de ADO, presente no pacote MDAC, em detrimento ao DAO. O objetivo era ir no banco o mais tarde possível, pegar os dados e fechar a conexão o mais cedo possível. Surgiu então o Win DNA (Windows Distributed interNet Applications Architecture), como o link diz é um nome marketeiro para tecnologias que já existiam mas foram agrupadas em uma arquitetura (COM, COM+, antigo MTS; ADO, ActiveX, ASP). Na época a minha bíblia era o livro Mary Kirtland, posteriormente li também o livro do Fábio Câmara.

A arquitetura Win DNA

A MS,  então,  comecou a divulgar a divisão de responsabilidades. A maioria dos programadores VB na época não usava nem o conceito de Classe, isso passou a ser mais demonstrado nos exemplos e no próprio livro, mas como o VB não era verdadeiramente OO não surtiu muito efeito. Até mesmo a divisão em DLL’s não era comum, o que mais se via eram executáveis gigantescos ou vários gigantescos por módulo!

O acesso aos dados era feito usando-se o RecordSet do ADO, criava-se um, ia no banco de dados, populava ele, fechava-se a conexão e usava na aplicação. A arquitetura,  então, era os Formulários (Form) no EXE e DLL’s;  A escrita do CRUD ficava em uma DLL. Na época,  a MS incentivava o uso massivo de Stored Procedures. E começou um movimento para tirar a lógica de negócios da camada de apresentação, ainda na fase dessa arquitetura era muito comum ter regras no banco de dados, mas falava-se em colocar essas regras em DLL’s também, então a camada de apresentação chamava uma DLL que continha algumas regras, que chamava a DLL de CRUD, que populava um RecordSet e retornava pela cadeia até a tela do usuário.

As coisas mudam no .Net

Com a vinda do .Net tivemos uma migração de algumas aplicações de maneira automática por meio de Wizards, alguns programadores também começaram a programar em VB.Net ou foram para o C#, uma linguagem mais de “gente grande” por ser mais parecida com Java. Porém,  o paradigma é diferente! VB 6.0 não é puramente OO, VB.Net sim! Aliás, o VB.Net é somente a sintaxe do VB 6.0, ele é uma linguagem em cima de outra plataforma.

Mas as pessoas são acostumadas a hábitos e,  o desenvolvimento em .Net foi feito da mesma maneira que vinha sendo feito no VB 6.0: lógica separada dos dados.

O paradigma OO nos diz: Cada classe determina o comportamento (definido nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. (fonte: Wikipedia)

Na arquitetura Win DNA os dados ficavam em um RecordSet e o comportamento em funções de uma classe em uma DLL, o RecordSet passeava pela aplicação e,  se ela fosse um controle de Estoque uma função recebia o RecordSet, percorria ele para ver se algum item estava zerado para gerar um novo pedido.

Na arquitetura OO não existe essa separação, o que eu quero mostrar com os próximos posts é que ao termos objetos de domínio, estamos facilitando o desenvolvimento por deixarmos tudo agrupado (comportamento + estado), a facilidade de manutenção será muito maior. Outra coisa, o uso de DataSet’s deixa o código também mais confuso, usando classes POCO o código será muito mais fácil de entender e leve.

Continue acompanhando!