Posts Marcados White Fox

Azure DevOps

Oi pessoal! Iniciando a sequência de artigos sobre tecnologias e plataformas citadas aqui, vou começar pelo básico: configuração de ambiente DevOps no Azure.

Embora DevOps esteja em adoção crescente há vários anos, sua adoção em larga escala só se tornou possível com o foco da Microsoft no Azure DevOps. A migração do antigo TFS para o GIT, a integração de todas as ferramentas em https://dev.azure.com/[suaempresa] e  a automatização via pipelines de CI (Continuous Integration) e CD (Contiunous Deploy) tornou todo o processo simples de ser implementado.

Bom, vamos assumir que estamos começando do zero e montar um ambiente de DevOps no Azure e mostrar todos os passos necessários. O único requisito é ter uma assinatura Azure válida para se registrar os artefatos.

O primeiro passo é criar a empresa no DevOps. Isto pode ser feito em https://dev.azure.com, bastando seguir os tutoriais. O primeiro artefato que temos que criar é o projeto inicial. O termo projeto aqui pode gerar confusão, pois há a tendência de se tratar um projeto como projeto Visual Studio. Mas, na nossa experiência, é mais produtivo tratar um projeto DevOps como sendo todo o contexto de um cliente. Assim, todas as solutions, projetos visual studio, artefatos etc. relativos a um cliente normalmente são armazenados em um único projeto DevOps. Abaixo a tela de gestão do projeto no Azure.

Dentro de um projeto podemos ter múltiplos repositórios GIT. Usualmente é criado um repositório para cada projeto do tipo bibliotecas, serviços ou sistemas. Já vi algumas defesas de se ter um repositório único para tudo (nós até já chegamos a usar este formato por algum tempo), mas isto complica a geração dos pipelines de CI. Assim, preferimos usar repositórios separados mesmo. Como é típico em um repositório GIT, temos o branch master, que armazena a versão de produção e branchs de desenvolvimento, usados para gerar as versões para testes e homologação. Em organizações que precisam de um compliance mais forte, pode ser criada uma política que impeça o commit direto no branch master, exigindo um pull request do desenvolvimento para ele. Este pull request pode também exigir aprovadores, o que garante um alto controle do que segue para o master. Claro que isto tem um impacto negativo em produtividade. Como na White Fox o objetivo é agilidade, nós não temos estes controles ativados.

Outro ponto importante para configurar no projeto é um feed de artefatos (último elemento na barra lateral esquerda). Este feed tem como finalidade a publicação dos pacotes Nuget das bibliotecas utilizadas naquele projeto DevOps. Embora o feed seja para uso interno (ele exige autenticação), dá para se configurar acesso para outros projetos ou mesmo para outras empresas. Na White Fox, estamos migrando todos os nossos pacotes Nugets de um servidor público para um feed de projeto, simplificando nossa infra e facilitando o processo de CI/CD.

Com o feed de artefatos criado, o próximo passo é criar os pipelines de CI para cada projeto utilizado. Ao se criar um pipeline, temos duas opções: utilizar pipelines clássicos ou baseados em arquivos yaml. Em geral, o pipeline clássico atende os cenários típicos, enquanto que os baseados em arquivos yaml permitem uma maior flexibilidade e customização das tarefas. A figura abaixo mostra a tela de criação. Inicialmente se escolhe o repositório de origem e aí basta seguir o assistente que vai gerar o arquivo yaml. Para escolher criar um pipeline clássico, basta usar o link no final da tela.

Usualmente nossos pipelines de CI fazem as seguintes tarefas: 1 – baixar artefatos nuget; 2 – compilar projetos; 3 – executar testes unitários; 4 – publicar artefato no próprio pipeline. Abaixo um pipeline clássico web e um de arquivo yaml.

Um alerta: apesar da Microsoft já ter recentemente permitido o desenvolvimento de Azure Functions em .NET Core, ainda não é possível fazer um pipeline para deploy deste tipo de Function. Se alguém tiver este cenário, é necessário por enquanto ainda fazer uma publicação manual – o que não é nada complexo, dá pra fazer direto do Visual Studio. Creio que em breve este tipo de pipeline também estará disponível.

Após termos os pipelines de CI funcionando, o último passo é criar os pipelines de release – CD. Usualmente o pipeline de release é criado baseado em um trigger de pipeline de CI bem sucedido. O pipeline de CD simplesmente baixa os artefatos e, caso seja uma aplicação web, publica direto no Web App; caso seja um Nuget, publica direto no feed de artefatos. Abaixo exemplos de pipelines Nuget e web app. Abaixo um pipeline web.

Finalizando os pipelines de release, voi-la, temos todo o nosso ambiente operacional em DevOps CI/CD. Um commit no master irá iniciar o pipeline de CI, que irá compilar, testar e deixar pronto pra publicação. Quando o CI finalizar, o pipeline de CD irá pegar os artefatos e automaticamente publicar no servidor Nuget ou direto no Web App.

Um último item que gostaria de apontar é sobre notificações. O DevOps por padrão já envia e-mails no sucesso ou falha do CI para quem fez o commit. É tranquilo também configurar o envio de e-mails para um grupo no caso de sucesso ou falha – dá até pra criar automaticamente workitems em falhas, se for desejado. No nosso caso, como somos usuários do Microsoft Teams, nós preferimos receber as notificações por ele.

Existe um bot público chamado Azure Pipelines – basta buscar em aplicativos no Teams. Ao instalar, ele permita que façamos assinaturas dos pipelines e publiquemos notificações em canais específicos. Assim, toda vez que um Release é feito com sucesso, todos nós da White Fox recebemos uma notificação no Teams automaticamente.

É isto pessoal. Uma vez configurado, o Azure DevOps funciona impressionantemente bem. Todos os nossos artefatos principais já estão em CI/CD e isto tem poupado muito tempo nosso em testes e deploys. Recomendo a qualquer empresa de software que passe a usar o Azure DevOps com CI/CD, se ainda não o faz!

No próximo artigo vou falar um pouco de services .net core usando NoSql. Até breve!

, , , , , , , ,

Deixe um comentário

Casa de Ferreiro…

Olá pessoal! Como estão de quarentena, com quase 5 meses de isolamento? Neste tempo muita gente aproveitou para aprender novas habilidades como cozinhar, pintar etc. No meu caso, resolvi empregar o tempo em algo que estávamos precisando fazer há muito tempo. Como prega o ditado, “casa de ferreiro, espeto de pau”, os sistemas utilizados internamente na White Fox já tinham passado da hora de serem atualizados. Ainda tínhamos sistemas em tecnologia antiga, hospedados em formatos que não recomendaríamos para ninguém.

Então, de março para cá, gastamos muitas horas para atualizar 100% do nosso parque tecnológico. E não só atualizar, aproveitamos para colocar tudo no estado-da-arte da que existe hoje. Como já citei várias vezes, estar atualizado é parte fundamental de nosso trabalho. Mas, principalmente por falta de tempo, a gente foca em empregar novas tecnologias e práticas nos nossos clientes e deixa de lado os nossos sistemas internos. Bom, não mais! Depois destes meses, estamos novamente orgulhosos de nossos sistemas! Eles estão utilizando o que há de melhor e mais moderno, tanto em boas práticas quanto em tecnologia. Neste artigo, vou fazer uma sinopse de como ficou a estrutura completa e, nas próximas semanas, detalhar melhor algumas das tecnologias e plataformas empregadas.

Para começar, fizemos uma refatoração e uma separação de camadas, isolando todas as nossas regras de negócios em APIs REST. Estas foram hospedadas em um API Gateway com o uso o Microsoft Azure Api Gateway – que é fantástico, com certeza teremos um artigo só para ele. O Api Gateway age como fachada para a cada API, gerenciando o acesso através de assinaturas e implementando as regras que se fazem necessárias. A figura abaixo mostra o uso do nosso API em uma semana normal.

Uso do White Fox Api Gateway

Aproveitamos que queríamos ter um caso de estudo de banco de dados NoSql e convertemos todo nosso sistema de autenticação e segurança para usarmos um banco de dados deste tipo. Fizemos testes com o Cosmos Db mas acabamos utilizando mesmo o Azure TableStorage padrão. O resultando ficou muito bom, detalho isto em artigo futuro.

Cada uma das APIs foi documentada em swagger usando o swaggerhub – que é completamente integrado ao Azure Api Gateway. Todas as APIs foram implantadas com o uso do Microsoft DevOPs, com Continuous Integration (CI) e Continuous Delivery (CD). Assim, após o commit, todos os testes unitários são automaticamente executados e, quando aprovados, atualizados diretamente no API Gateway, ficando disponível para aplicações web, móveis ou outras.

The API gateway pattern versus the direct client-to-microservice ...
Aplicaçoes usando API Gateway

O uso de APIs Rest nos sistemas Windows e Web ficou bem simples com o uso do Unchase Open API Connected Service (que pode ser instalado no Visual Studio). Ele se usa das especificações swagger para gerar um proxy local, similar à uma referência WCF.  O primeiro sistema que atualizamos foi o sistema interno de gestão, com o uso de um site Angular 10. Um ponto que tivemos cuidado de implementar no sistema web foi a utilização de chamadas de APIs de ação de forma 100% assíncrona. Isto melhora o tempo de resposta para o usuário e a escalabilidade do sistema. Mais sobre isto em artigos futuros

Dashboard White Fox Web

O segundo sistema que atualizamos foi o nosso aplicativo Windows. Ele é utilizado por alguns desenvolvedores que preferem ter algo sempre ativo no desktop. Com o uso do Unchase, também foi super simples migrá-lo para utilizar o Api Gatway.

Agora a “jóia da coroa” deste período foi a Lana. Já éramos usuários do Microsoft Teams há um bom tempo, e tínhamos ouvido que o Microsoft Bot Framework 4 estava valendo a pena, especialmente integrado ao Teams. Assim, mergulhamos a fundo e o resultado foi excelente. Construímos um bot, chamado Lana, para o Teams da empresa, que age como interface para todas as nossas APIs. E por ser um bot, comunicamos em linguagem natural escrita de maneira rápida e intuitiva. O resultado ficou tão bom que poucos ainda usam o sistema web ou aplicação Windows. Com certeza farei um artigo sobre a Lana.

Tudo tem lados positivos e negativos e esta pandemia não foi diferente. Sem ela não teríamos todo este tempo disponível para atualizar e avançar nosso conhecimento sobre as mais recentes plataformas e tecnologias. Podemos afirmar com certeza que agora em casa de ferreiro, temos um espeto de aço inoxidável da melhor qualidade! Nos próximos artigos detalho um pouco mais cada um destes componentes. Até breve!

, , , , ,

2 Comentários

Produtividade – Camada de Domínio – Revisão

Olá pessoal! Em 2009 (nossa!), eu escrevi uma série sobre produtividade, onde a ideia era colocar as técnicas que usamos no nosso dia a dia na White Fox para o desenvolvimento de sistemas. Embora os princípios continuem todos válidos, a tecnologia evolui. Assim, a ideia é fazer uma série atualizando cada uma destas postagens, de acordo com a linha que usamos atualmente.

A primeira delas é sobre a camada de domínio. Nesta camada, tivemos um amadurecimento de tecnologias que hoje tornam mais fácil a vida de quem precisa utilizar um ORM. No entanto, cresceram as dúvidas e questionamentos teóricos sobre que mecanismo utilizar para acessar dados. A linha do NoSQL ganha força e é o padrão para muitos tipos de sistema, especialmente agora, com um uso maior de sistemas baseados em PAAS como Azure ou Amazon.

Mesmo para os sistemas com domínio orientado à objeto e banco SQL, há vários questionamentos sobre se faz sentido o uso de um ORM. Existem várias pessoas que apontam os problemas de se tentar usar um (exemplo aqui) e nós mesmos já sofremos bastante com problemas oriundos deste mapeamento; recentemente fiz até um post sobre isto. Existem até aqueles que questionam o uso de OO em si, ou os que estão partindo para linguagens funcionais como o F#.

Mas, para quem usa bancos SQL, o uso de ORM ainda é a melhor alternativa. Claro que isto pode gerar problemas e definitivamente há casos em que é melhor não usar. Mas em termos de produtividade e manutenabilidade, ainda é a melhor opção. Temos usado consistentemente em todos nossos sistemas e, salvo algumas exceções em pequenas áreas, o resultado tem sido excelente.

Em termos de tecnologia, temos mais alternativas do que o nHibernate, que reinava absoluto em 2009. Vários pequenos frameworks como o nPoco tem um uso mais difundido. E o Entity Framework (EF) da Microsoft amadureceu e hoje compete de igual para igual com o nHibernate. Nossos sistemas usam predominantemente o nHibernate, até porque temos grandes sistemas em operação que começaram com ele. Mas, para novos sistemas, estamos preferindo o EF, principalmente por sua excelente integração com o LINQ do .NET. Utilizamos o database-first, com a declaração fluente de mapeamento e ainda usamos arquivos .TT para gerar todos os artefatos como repositórios, containers etc.

Quando o sistema é muito pequeno ou quando desempenho é um requisito especialmente severo, criamos uma versão de ORM que utiliza stored procedures diretamente. É claro que isto tem sérias restrições, mas para estes tipos de sistemas conseguimos otimizar removendo quase todas as camadas e utilizando o máximo poder do servidor SQL.

Para tentar minimizar a manutenção, criamos bibliotecas comuns a todos os ORM que utilizamos. Assim, trabalhar em sistemas que usam ORMs diferentes é uma experiência similar da camada de negócios para cima. Temos caso até de, em um mesmo sistema, termos diferentes áreas usando diferentes ORMs. Claro que nestes casos, temos que ter uma camada de comunicação para garantir integridade, muitas vezes baseadas em microservices.

Em termos de regras de negócio, continuamos utilizando um modelo anêmico. Esta continua sendo uma guerra santa na comunidade técnica, mas no nosso caso, não temos como negar todos estes anos de sucesso. O modelo anêmico facilita o isolamento de regras de negócio, simplifica o treinamento de novos desenvolvedores e a manutenção de todos os nossos sistemas. E estamos ainda colhendo alguns bônus adicionais, pois este tipo de modelo tem facilitado o isolamento de porções de regras de negócio para encapsulamento em micro-serviços, o que nos tem permitido evoluir nossos sistemas mais antigos de maneira viável. E, na inevitável migração para a nuvem, que deve ocorrer ao longo dos próximos anos, vamos poder também fazer uso de recursos avançados como Azure Servless Functions, graças a esta arquitetura.

Nos próximos posts devo comentar sobre a camada de interface, onde tivemos as maiores mudanças e as maiores evoluções tecnológicas. Até lá!

, , , , ,

Deixe um comentário

ORM e Concorrência

Olá pessoal! Há algum tempo atrás sofremos um pouco na manutenção de um dos grandes sistemas da White Fox. Quero compartilhar a experiência para que outros não tenham que passar pelas mesmas dificuldades!

Só relembrando, conforme meu antigo post sobre a camada de domínio, nós utilizamos ORM (nHibernate ou Microsoft Entity Framework) para fazer o mapeamento de entidades para o banco de dados, de modo a abstrair os mecanismos de persistência. Isto tem funcionado muito bem para nós – utilizamos ORM em praticamente todos nossos sistemas de maior porte há mais de 10 anos com sucesso. Claro que por mais que tentemos compartimentalizar, ao longo do tempo os domínios acabam crescendo. Hoje temos sistemas com domínios de mais de 300 objetos e milhares de linhas de código de regras de negócio.

Pois bem, neste sistema em particular, começamos a perceber há algum tempo, problemas de dados somente no ambiente de produção. Valores que aparentemente ficavam errados do nada. E, obviamente, nenhum destes problemas aparecia em homologação ou durante a execução de testes unitários. Claro que, como todo acidente, nenhum erro mais grave tem uma única causa. Neste caso em específico, também temos uma sequência de eventos que levaram à falha. Olhando agora, são até que óbvios, mas gastamos um bom tempo no diagnóstico e solução.

O primeiro componente começou com uma prática usual de ORM. Quase todos possuem uma proteção para evitar que a persistência ocorra em um registro que foi alterado por outrem. Por exemplo, se o ORM carrega um objeto em memória, faz nele alguma alteração e ao salvar, detecta que o registro no banco não é o mesmo de quando o objeto foi carregado, ele gera uma exceção. Porém, este mecanismo deixa tudo lento, já que para implementá-lo, o ORM acaba tendo que fazer uma query a cada UPDATE. E como usamos transações, os LOCK do banco de dados acabam garantido a atomicidade da operação, assim esta proteção acaba ficando redundante. No nosso caso ela sempre é desligada.

O segundo componente é a criação de campos para contadores ou totalizadores. Sim, claro, isto é algo que se deve evitar, especialmente como atributo de uma entidade de domínio. Por exemplo, colocar o total de uma nota fiscal como atributo ao invés de calcular o total através da soma de seus elementos. Usualmente evitamos isto, mas, em algumas entidades, calcular o valor toda hora pode ser complicado, seja porque existe alguma regra de negócio muito complexa envolvida ou um número muito grande de elementos para compor o total. Então, em algum momento, alguém resolve que manter o totalizador oferece uma melhor razão custo/benefício. Obviamente que se usam transações para manter os totais e se criam testes unitários para garantir que os totalizadores funcionam em todos os cenários.

O último componente do problema é a concorrência. Dificilmente teste unitários são criados para simular uma carga de múltiplos usuários simultâneos, pela complexidade de se simular este tipo ambiente. Assim, no teste unitário, quase não há concorrência. Porém, em produção os nossos sistemas são usados por centenas de usuários simultâneos. Apesar dito, tipicamente um usuário faz transações em uma única grande “entidade” por vez (p. ex., vendendo um produto). Assim, mesmo vários usuários em paralelo dificilmente mexem na mesma entidade, simultaneamente, ao mesmo tempo.

Mas as exceções é que fazem a coisa desandar. Se desligamos a proteção de dados alterados, usarmos totalizadores em entidade e usuários alteram esta mesma entidade quase ao mesmo tempo, temos o nosso problema acontecendo! Para detalhar, vejam a figura a seguir. Imaginem 2 processos executando em paralelo, em tempos muito próximos um do outro.

image

Em um momento 1, ambos carregam a mesma entidade em memória, uma delas com um atributo totalizador. Como neste momento ainda não houve nenhuma transação, ambos conseguem carrega-la simultaneamente, e ambas possuem o mesmo valor para o atributo. No momento 2, ambos fazem algum processamento em que vão atualizar o campo totalizador. No momento 3, o primeiro processo abre uma transação, salva os objetos e faz o COMMIT. O segundo processo tenta fazer o mesmo, porém como o primeiro fez o LOCK, ele é bloqueado e fica em espera. Se não cair por timeout, quando o primeiro processo acabar, ele é liberado, começa sua transação, salva os seus objetos e faz o seu COMMIT. Como não há proteção para alteração, ele não vai perceber que o objeto foi alterado pelo primeiro processo e vai completar a ação achando que tudo correu bem.

Mas percebam que o segundo processo partiu objetos com totalizadores incorretos! Como o ele carregou os objetos no mesmo momento que o primeiro processo, ele não vai contemplar as alterações feitas por ele e vai salvar um total incorreto. Um exemplo, ambos carregam um atributo com um valor total de 10, ambos somam 1, o primeiro salva 11, o segundo também vai salvar 11, incorretamente!!!

Uma vez diagnosticado, o problema também não é simples de resolver. Não há solução trivial com o uso de ORM. Soluções como ativar a proteção de alteração, usar LOCK pessimista ou usar singletons, possuem pontos extremamente negativos e foram rejeitadas por nós. No final, a solução que adotamos foi, para campos totalizadores, ignorar totalmente o ORM e ir direto ao banco. Fizemos isto com o uso de um repositório especialmente projetado para este fim e com o uso de stored procedures para garantir que as alterações sejam feitas com as proteções adequadas. Esta solução conseguiu até mesmo melhorar o desempenho da aplicação, pois evitamos a manipulação de totais pelo ORM e transferimos todo o trabalho para o banco. O ponto negativo é que o sistema fica bem mais complexo de manter e uma porção das regras de negócio saiu do domínio e foi para o banco. Mas de todos os males possíveis, este foi o que achamos de menor impacto.

Moral da história é: conheça seu ORM, evite a todo custo campos totalizadores e, se tiver que usá-los, não se esqueça que poderá ter graves problemas em um ambiente com concorrência.

Este e outros eventos tem nos feito repensar o uso de ORM como um absoluto. Acho que já está na hora de refazer minha série sobre produtividade, atualizando-a com as tecnologias e práticas que temos adotado nos últimos anos. Tudo muda e TI muda ainda mais rápido. Acho que até que conseguimos ter uma relativa estabilidade nos nossos ambientes por muito tempo. Mas obviamente a evolução é necessária e tem hora que mudar paradigmas é essencial para mantermos nossa produtividade. Mais sobre isto em breve!

Até a próxima!

, , ,

1 comentário

Novidades!

Olá pessoal, há quanto tempo!! :)…. Estive ontem no Visual Studio Summit 2015 e continuo achando este o melhor evento da Microsoft para desenvolvedores. Este ano esteve especialmente bom já que temos muitas tecnologias e plataformas a caminho, tais como o Visual Studio 2015, o ASP.NET 5 e o C# 6.0. Foi bom poder conversar como os early-adopters e colher opiniões sobre o que temos de bom em cada novidade destas. Sem entrar muito em detalhes, é suficiente dizer que fiquei positivamente impressionado, fazia tempo que não via a Microsoft engajada em disponibilizar tantos recursos para os desenvolvedores. E é perceptível também o esforço em começar a integrar os produtos Microsoft com as outras plataformas, como o Visual Studio Code para Mac e Linux e nos novos recursos de integração do Visual Studio 2015 RC com o melhor do mundo open source, tais como Node.js NPM, Grunt e Bower. Para quem ainda não baixou o Visual Studio 2015 RC, recomendo fazer isto logo, vale a pena no mínimo para se preparar para estas mudanças.

Na White Fox, continuamos firmes na nossa transição de desenvolvimento MVC clássico para um modelo baseado em MVC REST APIs e uma interface rica baseada em AngularJS. Praticamente todos os nossos sistemas já possuem telas desenvolvidas com esta tecnologia e novos sistemas estão sendo feitos exclusivamente neste formato. É cada vez mais comum também expormos estas APIs para interfaces desenvolvidas para dispositivos móveis, o que faz com que nossas APIs tenham que ser desenvolvidas com um agnosticismo completo com relação às interfaces que a vão utilizar. Se por um lado isto é uma boa prática, por outro significa migrar centenas de telas de legado para este novo formato, o que muitas vezes é bem custoso.

Na parte de ORM, continuamos sem um norte claro. A maior parte de nossos sistemas continua usando a versão antiga do nHibernate com o Castle ActiveRecord. Porém a idade está começando a pesar nesta plataforma, começando a tornar difícil algumas evoluções que precisamos fazer. Fizemos algumas tentativas de migração para o Entity Framework com relativo sucesso usando o Entity Framework 6. Porém, como nossos sistemas são muito complexos (centenas de entidades), o esforço de mapeamento é considerável, e temos bugs sérios no designer do EF6 com relação a defaults de banco de dados, o que torna a atividade ainda mais complicada. E, para detonar de vez este cenário, o EF7 vai remover o modelo “database-first”, o que inviabiliza o que fizemos até agora.

Esta questão do EF7 me intriga. Conversando ontem com outros desenvolvedores, percebi que muitos têm problemas similares. O uso do EF com sucesso acontece quando o sistema é novo e tem um único “dono” para banco de dados. Porém isto não é comum na nossa realidade (e, pelo que vi, de muitas outras), pois o banco é compartilhado entre vários sistemas legados e não há um único responsável pela evolução do mesmo. Neste aspecto, até a proposta da Microsoft para substituir o modelo database-first pelo code-first com migrations não resolve, pois temos alterações que não viriam do EF. Parece que não teremos alternativa a não ser codificar os objetos na mão (e voltamos 10 anos no tempo!!). Pelo menos o uso do Power Tools para o EF deve ajudar um pouco. E estamos de olho em ferramentas de terceiros, como as da DEVART, que também podem ser uma alternativa. Mantenho vocês informados da nossa evolução.

Outro tópico muito interessante ontem foi o relativa à Microservices. Percebi que outras pessoas estão com o mesmo problema que o nosso, que é manter a agilidade em sistemas de grande porte, onde o processo de deploy é amarrado por inúmeros problemas: demoras em homologação, sistema monolítico etc. Microservices podem ser uma solução para isto, a ideia é decompor o sistema em componentes de serviço e com isto podermos substituir um ou outro sem afetar a aplicação como um todo. Em teoria, a ideia é boa, mas, na prática, ainda não temos uma plataforma definida para implementarmos isto. As implementações de Microservices normalmente fazem uso de filas de mensagens, o que gera problemas para sistemas que exigem uma resposta síncrona. Além disto ainda temos que escolher uma boa plataforma para implementar este barramento de serviços/mensageria. O Microsoft Azure tem uma implementação interessante, porém ele não é uma opção para sistemas internos. Estamos analisando possibilidades como o Service Broker do próprio SQL Server ou soluções open source como o RabbitMQ, vamos ver como fica isto nos próximos meses.

Até a próxima!

, , , ,

2 Comentários

De volta 2!

Oi pessoal!! Depois de um looooongo tempo sem postar, finalmente consegui um tempinho. Olhando o último post, dá pra notar que estávamos extremamente ocupados no início do ano passado. Mal podíamos imaginar o que viria pela frente. Do ano passado para cá, iniciamos um enorme projeto com um de nossos clientes, o Sistema de Ensino Poliedro, que nos tomou praticamente 1 ano de contínua dedicação e deve ainda prosseguir por bastante tempo.

O projeto foi participar da construção de aplicativos móveis, iOS (iPhone e iPad) e Android (smartphones e tablets), para disponibilizar para alunos uma grande parte das informações até então só existentes no site, como agenda, notas, resultados de simulados etc. Nossa parte foi expor em serviços toda a infraestrutura do domínio que tínhamos em sistemas, de forma a funcionar tanto para os aplicativos móveis quanto para uma nova versão web, também a ser desenvolvida. Trabalhamos com empresas parceiras, que ficaram responsáveis pela construção das interfaces móveis e web.

O maior desafio foi a definição desta API de serviços, para ser o mais reusável possível sem comprometer a facilidade e uso pelas interfaces. E tinha que ser extremamente escalável, já que o número de alunos previstos para os aplicativos era superior a 30.000.

A nossa opção foi utilizar a ASP NET MVC Web API. Uma das grandes vantagens desta arquitetura foi que o Web API já é capaz de retornar dados em vários formatos, como XML e JSon, o que foi providencial para nossa meta de reusabilidade. E por ser bem leve, atendeu bem também a necessidade de escalabilidade.

Como o sistema é, em quase todas as telas, somente leitura, optamos por otimizar o acesso a dados com a criação de banco de dados construídos especialmente para este fim. Assim, desenvolvemos procedimentos para trazer dados dos nossos bancos transacionais e produzir uma informação desnormalizada, pronta para consumo pela interfaces. Embora isto tenha exigido uma grande capacidade de processamento para gerar esta informação consolidada (optamos por executar isto durante as madrugadas), o acesso de cada uma das interfaces ficou extremamente rápido e escalável.

O resultado foi um sucesso completo. Os aplicativos iOS e Android tiveram centenas de downloads nos primeiros dias e hoje, menos de 6 meses após o lançamento, já temos mais de 10.000 aparelhos, entre tablets e smartphones, com acessos de alunos. O resultado foi tão positivo que já continuamos no mesmo ritmo para construção de mais aplicativos, agora voltados para professores e gestores. Nosso cliente provavelmente é hoje uma das instituições mais modernas do país, em termos de software. Ficamos super orgulhosos de termos participado deste projeto!

Em paralelo a isto, outros clientes nossos estão nos demandando bastante. Com isto, a White Fox está totalmente ocupada e estamos em busca urgente por bons desenvolvedores. Se você quer saber mais ou se candidatar, envie-nos seu currículo para rh@whitefox.com.br

Espero não demorar mais um ano para o próximo post! Até breve!

P.S.: Para quem ainda não se inscreveu e está no rio, não percam o DNAD 2013, nestes dias 2 e 3 de agosto. A grade de palestras está excelente e a White Fox é uma das patrocinadoras!

, , , , , , , , ,

Deixe um comentário

White Fox: Ano I

Oi pessoal! Este mês comemoramos um ano de White Fox… Nem parece que já se passou um ano desde o início! Acho que o tempo passa mais depressa quando estamos fazendo algo que gostamos. Depois de definirmos o conceito do que buscávamos e iniciar a empresa, passamos este ano consolidando e definindo processos de trabalho e refinando nossos objetivos e áreas de atuação.

Na parte interna, conseguimos evoluir muito mais do que esperava. Nosso framework está extremamente maduro, conseguimos atingir o que eu sempre buscava em termos de produtividade, para manutenção e sistemas novos. Claro que ainda tem muita coisa a evoluir, especialmente nas partes mais complexas, ligadas à interface. Mas nas áreas de infra-estrutura, de suporte ao domínio (repositórios, serviços) e de serviços horizontais (segurança, log, agendamento), atingimos um nível ótimo. Atualmente, quando iniciamos uma nova aplicação, perdemos muito pouco tempo até termos algo básico no ar, com todas as funcionalidades mínimas necessárias (login etc.). Vamos continuar evoluindo, mas ele está tão maduro que hoje precisamos gastar muito pouco tempo na sua manutenção e evolução.

Outra área que evoluiu muito mais do que esperava foi a parte de gestão de processos de desenvolvimento. Graças ao esforço do Christian (que gosta muito desta área), conseguimos definir, implantar e criar ferramentas de gestão dos processos de desenvolvimentos ágeis que usamos nos nossos projetos novos e de manutenção. Ainda tem muita coisa a ser feita, queremos automatizar mais, termos uma ferramenta mais robusta (e talvez até um produto derivado dela) e dar ainda mais transparência para nossos clientes. Estamos criando algo muito interessante para a gestão de projetos de manutenção no formato ágil. No decorrer deste segundo ano, com certeza teremos novidades neste aspecto.

Refinamos um pouco os objetivos da empresa. Continuamos a buscar uma excelência técnica e um local de trabalho extremamente agradável para o desenvolvedor. E preferimos manter uma equipe pequena, mantendo nossa maneira de trabalho, do que crescer e sacrificar qualidade. Hoje o software White Fox é utilizado principalmente quando o cliente quer algum diferencial de qualidade e velocidade de construção. Continuamos a selecionar também nossos projetos, preferindo clientes que possuam experiência na contratação de desenvolvimento ágil e que consiga identificar um ROI nos projetos que necessita.

Consolidamos também nosso programa de novos integrantes. Hoje a White Fox possui somente 3 posições: estagiários, sócios juniores e sócios sêniores. O programa de estágio é utilizado para identificar e treinar novos talentos. Sócios júniores são pessoas que possuem um talento excepcional, estão identificados com os nossos valores e estão em um momento de transição até ter todo o necessário para ser um sócio sênior. E os sócios seniores participam da gestão da empresa e são convidados a atuar como investidores em todos os nossos empreendimentos. O modelo enxuto e claro facilita a conversa com novos interessados e auxilia na identificação do que é necessário para se fazer para ser parte dela.

As perspectivas para o segundo ano são ótimas. Continuaremos a atuar nas melhorias do nosso processo interno de desenvolvimento, buscando cada vez mais inserir o cliente com o uso de ferramentas automatizadas. Continuaremos a buscar projetos onde o software seja o diferencial competitivo. E continuaremos a trabalhar pra fazer produtos cada vez melhores, de maneira rápida e com um custo adequado. Vou mantê-los informados de como isto está evoluindo aqui por este blog. Até a próxima!

, ,

2 Comentários

Autenticação e Segurança

Olá pessoal! Esta semana quero falar de um assunto de infra-estrutura, mas extremamente crítico em nossas aplicações: a parte de autenticação e segurança de usuários. Quando fazemos uma aplicação Web, temos que definir como nossos usuários serão autenticados. Os desenvolvedores felizes são aqueles que utilizam autenticação integrada em suas aplicações e deixam a cargo da rede e do Active Directory (AD) a tarefa de identificar quem está logado. Claro que isto funciona bem em ambiente de Intranet. Na Internet é até possível, mas em geral é uma alternativa que não é utilizada por consumir uma banda excessiva e ser estranho para o usuário, abrindo aquela tela de login Windows cada vez que se acessa um site. Existe ainda a autenticação básica, utilizada em sites HTTPS e que basicamente mapeia o usuário logado para um usuário de rede. Esta alternativa também consome bastante banda e é pouco amigável para o usuário.

Nos cenários comuns, a autenticação é feita diretamente pela aplicação e o usuário se depara com campos de “login/senha” em alguma página da aplicação Web. Nestes casos, o mecanismo mais usado no .NET é o FormsAuthentication, com cookies. Nesta modalidade, após fornecer uma combinação login/senha válida, o sistema cria um cookie que é utilizado para autenticar as requisições subsequentes do usuário. Este cookie é associado à web session do usuário (na verdade, ele serve para “amarrar” a sessão, identificando-a a partir de sua criação) e permanece válido pelo tempo definido de expiração – normalmente 30 minutos. É possível ter FormAuthentication no formato cookieless, mas é menos utilizado por ser menos seguro.

Usar o FormsAuthentication (com cookies) no .NET é algo relativamente simples, todo o trabalho é feito pelo próprio framework. Para a maior parte dos sistemas, isto atende completamente a necessidade de autenticação. Em sistemas um pouco maiores, é possível também incluir uma implementação do security membership provider (ver estes excelentes posts aqui sobre o assunto), e ter a definição de perfis por usuário, resolvendo também as necessidades de autorização. É possível encontrar na web vários exemplos de implementação até com algumas customizações destes providers, como esta aqui fazendo uso de WCF.

Os problemas começam a surgir quando a aplicação cresce ao ponto de ter que ser integrada a outros sistemas e plataformas ou ter que coexistir com outras, ou ainda ter que suportar múltiplas formas de acesso (Windows Forms p. ex.). Nestes casos, temos que ter maneiras alternativas para identificar usuários e até fazer transferências de uma aplicação para outra. Em grandes empresas, surgem necessidades como definir uma política de segurança de expiração de senhas, um banco de dados único para os usuários entre as aplicações e até a necessidade de fazer login integrado ao AD em algumas situações. Aplicações de maior porte podem também necessitar de melhor desempenho na infra-estrutura de segurança, já que isto é utilizado em praticamente todos os requests. Finalmente, em aplicações corporativas é usualmente necessário ter coletas de estatísticas de uso e usuários ativos, para efeito de monitoramento e planejamento de carga. Nestes casos, a implementação padrão de segurança pode não atender completamente e é necessário desenvolver uma própria.

No nosso caso, desenvolvemos uma solução de segurança que já está em uso há mais de 12 anos. É uma solução WCF bastante simples, com um banco de dados de usuários, perfis e aplicações, classificados por empresa. Os serviços expõem mecanismos de autenticação direta por senha e por integração ao AD. A senha não é armazenada, utilizamos um hash gerado pelo próprio .NET. A integração ao AD é algo simples ainda, baseado no ID de rede (só liberamos para algumas poucas aplicações, onde o ambiente é controlado e os riscos baixos), há planos de se utilizar o Federated Services para algo mais avançado. Todo o acesso aos serviços são feitos por um intermédio de um agente de segurança, que implementa as classes de segurança e faz a tradução para os DTOs do WCF. O sistema suporta políticas de segurança, complexidade e expiração de senhas e coleta todas as estatísticas de uso das aplicações.

A solução possui ainda métodos para suportar a geração de tokens de segurança. Este tokens são identificadores (guid) que são passados, via querystring ou qualquer outro mecanismo, de um aplicação para outra. Eles possuem uma expiração rápida e podem ser utilizados apenas uma vez. Cada token está associado à sessão do usuário que o criou e pode ser utilizados para permitir o login rápido em outra aplicação. Com isto, conseguimos fazer a transferência de uma aplicação para outra de maneira transparente para o usuário.

Todos os nossos sistemas fazem uso da mesma solução de segurança, sempre através da utilização do agente. O FormsAuthentication continua sendo usado, a diferença é que a identificação do usuário é feita por nossa solução, não utilizando o membership provider. A única coisa que fazemos na aplicação é implementar classes para encapsular as chamadas ao agente e utilizar a session do ASP.NET para armazenar o usuário ativo e as respectivas permissões. Isto garante um melhor desempenho, evitando que a cada request os dados do usuário e respectivos perfis tenham que ser obtidos via chamadas WCF.

Aplicações Windows também utilizam o agente de segurança. A diferença é que como não temos um SessionID, como na Web, acabamos por simular um criando uma chave guid cada vez que a aplicação é inicializada. Esta chave é utilizada como se fosse o identificador daquela sessão Windows e pode também ser usada para se gerar tokens de autenticação. Assim é possível, por exemplo, clicar em um botão de uma aplicação Windows Form e se abrir um browser, com uma página de uma aplicação Web, já autenticada.

É isto, espero ter dado uma idéia de como lidamos com autenticação e autorização em nossos sistemas. Se alguém tiver alguma dúvida específica, basta entrar em contato. Até a próxima!

, ,

4 Comentários

Como eu Desenvolvo Software – Conclusão

Olá pessoal, este é último post desta série. No post anterior descrevi como construo software até o ponto onde desenvolvemos as telas do sistema que vão de fato gerar valor para o cliente. Estas telas são a própria razão do software sendo construído e são elas que geram o retorno para o custo de desenvolvimento. No fundo, estas telas são a razão de ser do sistema.

A mesma idéia de telas complexas pode ser aplicada para itens como serviços ou aplicações Windows. Um serviço normalmente é feito para atender uma necessidade de integração, seja com outros sistemas, com outras plataformas (mobile, por exemplo) ou para ser parte de um barramento corporativo. Para os serviços, eu sigo praticamente os mesmos passos utilizados em telas complexas. Primeiro identifico o que é desejado do serviço. Aí isto é descrito na forma de interfaces e objetos de transporte – eu uso o excelente Web Service Software Factory, que é um plugin DSL para o Visual Studio 2010. Se a integração é complexa, eu tento simular o máximo antes de efetivamente integrá-lo aos serviços de domínio, para, da mesma forma, identificar todos os aspectos e evitar retrabalho. Finalmente, com todas as interfaces definidas, eu as “preencho” fazendo as implementações acionar os serviços de domínio. Aplicações Windows também seguem estes mesmos passos.

Claro que há situações de exceção. Isto é especialmente válido para requisitos não funcionais como segurança e desempenho. Embora hoje seja relativamente fácil atender a requisitos de segurança com a própria infra-estrutura da plataforma .NET, em algumas situações é necessário que criemos mecanismos específicos para atender um determinado requisito. Um exemplo disto são aplicações multi-tenant, onde é necessário um cuidado especial para que o usuário de um cliente não tenha acesso a dados de outro. Para estes casos, o recomendável é tentar ver a literatura existente e pesquisar outras situações similares e as soluções que foram empregadas.

Outro ponto que gera situações de exceção é a questão de desempenho. Um problema típico é fazer uma aplicação que roda bem em desenvolvimento e testes, mas que, ao ser colocada em produção com um número grande de usuários, falha por completo. Existem vários problemas que podem gerar este cenário e cuja solução às vezes não é simples. Às vezes não é simples nem detectar a causa ou simular o problema em ambiente de testes, portanto boas práticas na hora de desenvolver podem significar menos dor de cabeça no futuro. Agora, se por um lado é ruim pensar em otimização prematura, tentando fazer código pra evitar um problema de desempenho para o qual não se conhece a gravidade ou a frequência de ocorrência; é também ruim não pensar em desempenho durante o desenvolvimento, utilizando práticas que podem gerar problemas potenciais. Aqui o melhor caminho ainda é a experiência, se a aplicação sendo desenvolvida tem estas características, o melhor é ter na equipe alguém que já tenha tido oportunidade de lidar e desenvolver soluções para estes tipos de requisitos.

Acho que deu para dar uma idéia do processo que eu sigo. Mas, além do processo, acho importante reforçar o ponto mais importante que eu tentei passar no decorrer destes post: fazer software é entregar algo que funcione, dentro de custo e prazo que em que o cliente possa ter ROI. A maior parte das vezes esta medida se prolonga por toda a vida útil do software e o ROI continua sendo medido a cada atividade de manutenção e evolução. Se tudo correr conforme previsto, um cliente satisfeito vai ter seus objetivos atendidos com o software que possui e a empresa que o construiu vai ter lucro neste processo.

Eu acredito que fazer software é mais parecido com artesanato do que com uma linha de produção. No fundo, a qualidade do software que vai ser entregue e a questão de se conseguir cumprir prazo e custo em posteriormente, dar manutenção, tem uma relação direta com a qualidade das pessoas que o construíram. Assim, para se tornar um bom desenvolvedor, é necessária uma atualização e melhoria constante no processo de desenvolvimento. Isto não só em aspectos tecnológicos, mas em áreas como habilidade de comunicação, design, capacidade de trabalhar em equipe e até entendimento dos negócios da empresa onde se está inserido e do cliente. Tudo isto está obviamente muito ligado à maturidade e à experiência de quem desenvolve, mas são características que podem ser melhoradas em quaisquer estágios da nossa carreira. Como qualquer tipo de artesanato, fazer bom software significa ter uma boa combinação de talento, conhecimento e experiência. O talento é de cada um e a experiência vem com o tempo. O fator que está mais sob nosso controle é o aspecto técnico, que podemos sempre aprimorar com estudo.

Neste aspecto, apesar da tecnologia evoluir muito rápido, existem conceitos fundamentais e comuns a qualquer tipo de software que permanecem quase imutáveis ao longo do tempo. Assim, coloco a seguir uma relação bibliográfica que abordam estes aspectos mais fundamentais e que eu achei especialmente importantes pra mim:

Code Complete 2 – Acho este livro essencial para quem quer codificar bem. É sobre técnicas para melhorar o código que escrevemos, muito bom mesmo!

Clean Code – Na mesma linha do Code Complete, também muito bom!

The Mythical Man-Month – Este livro foi escrito em 1967, mas é incrível como o que ele apresenta é aplicável até hoje! Muitas vezes vemos conceitos defendidos por profissionais “atuais” que repetem os mesmos erros descritos há mais de 30 anos… Acho que é uma leitura indispensável para qualquer profissional da nossa área (é bem curtinho).

The Object Primer – Embora um pouco antigo, a parte de conceitos sobre programação orientada à objeto é fantástica. A parte de UML hoje nem é tão importante, mas mesmo assim vale – afinal quem não vai esbarrar com um diagrama UML em algum momento?

Refactoring – Os livros do Martin Fowler em geral são todos muito bons. Mas deles, o que eu mais gosto é este. Leitura obrigatória!

The Pragmatic Programmer – É um livro que eu gostei muito, sobre programação baseada em realidade, utilizando conceitos ágeis.

Domain-Driven Design – O assunto está na moda, mas independente de modismos, os conceitos colocados neste livro são muito bons. Não é um livro fácil de ler, mas definitivamente vale a pena.

Domain-Specific Development – Apesar de já desatualizado no que diz respeito ao Visual Studio, a parte inicial deste livro, que descreve o que é e qual o propósito de uma DSL, é muito boa. Não sei como este assunto vai evoluir no futuro, mas este livro influnciou bastante a nossa linha de construção de frameworks. E muitos plugins do Visual Studio 2010 e geradores de código .tt são derivações das idéias criadas por este time.

É isto pessoal. Até a próxima!

, , , , ,

1 comentário

Como eu Desenvolvo Software – Parte 5

Olá pessoal, um ótimo 2011 para todos! Apesar de muita gente estar de férias, o nosso ano começa a todo vapor, com um projeto grande em andamento e toda a manutenção usual. Continuando a série sobre desenvolvimento, fechei o último post com telas de CRUD já disponíveis no sistema.

Apesar de já termos o sistema com muitas telas operacionais até aqui, para mim isto é de pouco valor já que, para o cliente, o produto ainda não traz nenhum benefício de negócio. Ter um sistema que permita cadastrar dados de apoio não traz nenhum valor agregado e, portanto, possui um ROI nulo. Claro que é uma etapa necessária (e nem sempre muito rápida, dependendo do número de dados de apoio), mas é importante que o cliente e a equipe estejam sempre atualizados nesta visão.

Com os CRUDs prontos, podemos voltar às tarefas que geram valor. As telas construídas nestas tarefas normalmente são bem mais complexas do que um CRUD e são suportadas por regras de negócio que também podem ser complexas. É nestas telas e respectivos serviços (que implementam as regras de negócio) que iremos gastar a maior parte do esforço de construção (e posteriormente, de manutenção). A minha abordagem para estas telas é algo bastante top-down. Eu inicio pela definição do layout da tela. Normalmente uso algum produto para desenhar um protótipo e uso-o para conversar com o cliente e tentar identificar se aquilo atende o que ele espera da funcionalidade. As necessidades de negócio são identificadas e classificadas em métodos de classes da camada de serviços. Por exemplo, suponhamos que ao cadastrar uma despesa de aluguel de veículo, haja uma necessidade de se gerar cálculos consolidados por operadora de aluguel. Neste caso poderíamos criar uma área de serviço responsável por estas atividades (uma classe chamada “GerenteAluguelVeiculos”, por exemplo) e um método para aquele serviço (por exemplo, “RegistrarAluguel”). A partir daí isto é incorporado à linguagem e até o cliente vai saber que existe uma serviço de registro de aluguel no sistema que é responsável por gerar os dados consolidados. Durante a análise, estas necessidades são registradas em novas tarefas, que são cadastradas para priorização e implementação.

Esta separação em classes especializadas para serviços é algo que é bastante polemizado em listas de discussão, já que isto gera um modelo bem anêmico. Em uma abordagem DDD clássica, estes métodos de serviço ficariam nas próprias entidades (veículo?, aluguel?). Porém, na minha experiência e com a tecnologia atual, não há ganhos de produtividade em se fazer isto, muito ao contrário, aliás. Além da complicação gerada pela parte subjetiva, que é de cada desenvolvedor, de identificar qual a classe é responsável pelo quê, o posicionamento de regras de negócio em métodos específicos das entidades de domínio tornaria muito mais complicada a gestão dos aspectos não-funcionais das regras, tais como a necessidade ou não de log, aspectos de segurança, aspectos transacionais etc. Isto é uma particularidade do nosso framework, mas com as regras de negócio somente em classes de serviço, esta gestão fica muito mais simples e com isto temos uma maior produtividade escrevendo estas regras – mais sobre isto no posto sobre camada de serviços da série de produtividade.

Continuando em uma abordagem top-down, eu passo à criação da tela em si. Nesta parte temos um grande apoio do framework, mas ainda assim temos que criar artefatos como views e rotinas para preenchimento de dados. As etapas de criação dos componentes das telas, preenchimento dos dados da mesma e execução de regras de negócio ficam bem separadas, graças ao framework – ver mais no post sobre camada de interface. As ações da tela que irão acionar serviços são criadas, mas, inicialmente, sem executar nada (stubs). Eu tento fazer o máximo de comportamento da tela possível antes de iniciar a construção dos serviços. A idéia é tentar ter um protótipo com pelo menos a parte de navegação funcionando e mostrar isto para o cliente antes de continuar. Isto porque, na minha experiência, quando o cliente vê funcionando, pode acontecer dele se lembrar de algo que não foi incluído na análise inicial e pedir modificações. E também porque o esforço gasto nestas telas é tão grande (de longe, a maior parte do sistema) que é importante ter as definições o mais corretas possível antes de fechar para evitar retrabalho. Isto pode fazer até com que às vezes eu utilize mocks para gerar os dados que seriam retornados por serviços, para que a tela possa funcionar antes deles estarem prontos. Quando o serviço é muito simples, pode ser que eles sejam de fato implementados neste ponto. Algo que é muito comum ser feito nesta hora são consultas específicas de repositório. Coisas como “ObterFuncionariosEmViagem” podem ser criadas como métodos do repositório e já implementados. O framework fornece muitos mecanismos para facilitar a geração deste tipo de consulta, desde expressões lambda até uma fluent language para gerar consultas NHibernate e para manipulação de dados. Para isto eu também utilizo muito raramente testes, pois a linguagem de expressão de consultas é muito simples e raramente gera erros ou dúvidas. E por ser compilada, qualquer problema com alterações de entidades de domínio é rapidamente detectada e corrigida. Os casos que exigem testes são consultas complexas que são expressadas em HQL; como estas são baseadas em strings, podem quebrar muito facilmente com alterações em entidades, além de serem difíceis de escrever.

Quando a tela está praticamente pronta, aí sim começo a escrever a parte de serviços. Muita gente acha que a maior parte do esforço está aqui. Mas em geral, a maior parte do esforço está na tela. Escrever serviços, tirando algumas poucas exceções, é algo bastante simples, especialmente com todo o apoio fornecido pelo framework. Claro que existem regras de negócios complexas em muitos sistemas, mas ainda assim, o esforço gasto nelas não se compara com o de construir todas as telas que não são CRUD. O framework tira do desenvolvedor toda a parte de infra-estrutura, então ele não se preocupa com coisas como transações, gerenciamento de exceções, uso ou não de log, identificação do usuário corrente etc…. Ele praticamente escreve só a regra de negócio mesmo. A consolidação de regras de negócio em classes de serviço separadas por “áreas” facilita o reuso e a localização rápida de regras similares. E o uso dos repositórios para consultas mais complexas permite que o serviço seja basicamente direcionado para as alterações da transação.

Para as regras de negócio o ideal é ter pelo menos um teste unitário com o caminho mais usado da mesma. Não uso TDD por achar que, para o meu caso e para os desenvolvedores com quem trabalho, ele diminui produtividade – conheço pessoas que dizem ser o contrário, mas cada caso é um caso. Na criação de regras de negócio, o importante é ser eficaz e eficiente, ou seja, produzir regras que façam o previsto, no menor prazo possível, e que sejam fáceis de entender e manter. Acho que cada um tem um estilo pra atingir este objetivo, o meu definitivamente não é com TDD. Nunca trabalhei com alguém que usasse TDD de maneira consistente e produtiva em todos os casos, mas se alguém funcionar bem assim, nada contra. Um teste ao menos é importante porque regras de negócio são muito sensíveis a mudanças de negócio. Confesso que nem sempre eu mesmo sigo esta regra; muitas vezes a regra é tão simples (menos de 5 linhas é o típico para regras simples) que o esforço para produzir teste fica questionável. Mas acho que no geral faz sentido ter ao menos um teste por regra.

Finalmente, as regras são integradas à interface para que tudo funcione. Eu faço isto de maneira incremental, ou seja, conforme as regras vão ficando prontas eu já vou incorporando-as à tela. Eu gosto mais dos testes finais (integração), ou seja, de ver a tela funcionando e fazendo que ela foi projetada que fazer. No meu caso, é onde eu pego a maior parte dos erros de construção. E, quando acabo este processo, a tela está quase totalmente pronta.

Embora utilizemos uma fase de homologação pelo cliente, eu uso isto mais como um processo de validação/aceitação do que de testes. Acredito que um bom desenvolvedor deva entregar seu software pronto, e pronto significa sem erros. Assim, não acho que o usuário final ou cliente deva participar do processo de depuração. É claro que algumas vezes eles vão encontrar erros ou bugs; mas isto tem que ser exceção, não regra.

Durante todo este processo, o framework é também evoluído. Se for detectado algo que está dando algum excesso de trabalho braçal, ou alguma coisa que poderia ser feita pra aumentar produtividade, isto já é feito durante o desenvolvimento (desde, é claro, que não seja algo muito grande). É claro que isto não pode ser feito por desenvolvedores inexperientes, daí a necessidade que temos de termos somente equipes formadas predominantemente por seniores. Com isto, o objetivo é que nossa produtividade não só seja alta agora, mas que ela continue a aumentar com o tempo.

Em linhas gerais, é este o processo que eu sigo. No próximo e último post eu vou falar um pouco sobre casos de exceção e pontos como construção de serviços e exportação/importação de dados, muito comuns a todos os sistemas. Até breve.

, , , , ,

1 comentário