Arquiteto tem que ter mente aberta

       Me lembro muito bem de quando vi pela primeira vez um computador ao vivo, era um TK 85. Foi amor à primeira vista. Acho que era 85/86, não me lembro tão bem assim, mas eu sabia que era com aquela geringonça que eu iria fazer minha carreira profissional.
       Minha mente sempre foi muito lógica de modo que aprendi programar de forma bem natural. Basic (Argh!), um pouco de assembly pro z80, depois Basic pro CPM, Clipper já no mundo dos pcs, C, Visual Fox Pro, VB, C# .Net. Tornei-me perito em SQL Server 7.0-2008. Conquistei todas as certificações M$ disponíveis na época.
       Ao longo da minha carreira como desenvolvedor sênior e dba sql, sempre tive preocupação com padronização, reutilização, clareza de código e performance das aplicações que desenvolvi, dos projetos que participei ou os que liderei. Isso desde que trabalhava com clipper como freelancer.
      Pra todo problema eu sempre tinha uma solução, e como estava 'bitolado' ao mundo Microsoft achava que essa era a única e com certeza melhor maneira de fazer as coisas. É claro que a visão radical de muitos do mundo open source contribuiu para eu pensar assim.

       Minha visão começou a mudar quando assumi o cargo de arquiteto de sistemas numa multinacional com um parque de aplicativos espalhados por sistemas operacionais heterogêneos, desenvolvidos nas mais diversas tecnologias.

       De início minhas soluções quase sempre direcionavam o uso de tecnologia Microsoft, de forma natural. Com o tempo porém ficou claro que um arquiteto de soluções não pode ficar limitado a uma visão míope ou preconceituosa. Ao contrário, é nosso papel ter visão ampla, desapaixonada, para poder decidir pela tecnologia mais apropriada para cada cenário. Não existe fórmula mágica, nem existe padrão universal. Portanto, para ser um bom arquiteto que se preocupa com a corporação para a qual trabalha é essencial deixar a visão de desenvolvedor, que tem preferência por linguagem, banco, etc. É preciso ter perspicácia, ver além do óbvio, é preciso saber quando pesquisar outros meios de fazer a mesma coisa. Saber usar o legado a seu favor e não como um estorvo as iniciativas de melhoria sistêmica. É claro que tudo isso não se aprende do dia pra noite. Por isso não existe um curso para arquiteto de soluções, se existir caia fora, é balela. Arquiteto é experiência, é saber ser humilde pra reconhecer quando você erra e que aquela solução que pensava ser a mais adequada, agora depois que você testou, fuçou, esgotou as possibilidades e viu que não era bem como imaginava, precisa ser revista. Se for teimoso e orgulhoso por medo que outros digam: "mas você recomendou a tecnologia A ou B e agora mudou de opnião?", neste caso irá em frente em detrimento da melhor escolha para a sua organização.

         Há uma diferença abismal entre um arquiteto de soluções, que deve ter a visão da organização, conhecer muitas tecnologias diferentes (mas não necessariamente ser especialista em tudo), de um arquiteto de aplicação, que conhece a tecnologia que ele domina e tem visão e expectativas limitadas ao seu escopo.

         Nem um dos dois está errado. O problema é quando um quer fazer o papel do outro. Se você se intitula "Arquiteto" pense nessas considerações, reflita sobre como desempenha seu papel e você saberá responder pra si mesmo se você é mesmo um arquiteto ou não.

Abraços e até a próxima,

Paulo Barros

Overview do Visual Studio 2005

Muitas melhorias e novas características foram implementadas na nova versão do Visual Studio .Net.
Analisaremos algumas das mais importantes, são muito abrangentes para listar todas num único documento.

Integração da Equipe numa única ferramenta

Um grande problema existente hoje é falta de real integração entre todos os envolvidos num projeto de software. Isto se dá basicamente porque a atualização dos diversos modelos e documentos depende de disciplina, ter um processo (metodologia) e segui-lo de fato, o que muitas vezes acaba ficando em segundo plano, pois outras prioridades quase sempre impedem que as coisas funcionem como deveriam. Isto ocorre na maioria das equipes independente do tamanho, visto que Gerentes de Projeto usam o Project Server, Arquitetos e Analistas usam Visio e Word, Desenvolvedores usam Ferramentas de desenvolvimento, apenas para exemplificar.

O Visual Studio Team System introduz um verdadeiro arsenal para sanar ou reduzir ao mínimo essa lacuna.

No centro temos um aplicativo servidor que controla todo o processo: Team Foundation Server que é responsável entre outras coisas por:
Controle de versão
Tracking de Itens de trabalho
Relatórios sobre o projeto
Builds programados
Comunicação dos membros do projeto

O Visual Studio Team System conta com versões distintas, uma para cada membro do projeto:

Architect
Developer
Tester
Database (novo)

O VSTS – Team Suite abrange todas as features num só produto.

Para ilustrar:
O Gerente de Projeto cria “Work Items” (tarefas) e atribui aos membros da equipe;
O Arquiteto desenho modelos do projeto e a ligação entre as partes, a ferramenta gera o esqueleto da aplicação. Qualquer mudança no código é refletida no modelo e vice-versa;
Os Desenvolvedores trabalham de acordo com as especificações e modelos e atualizam o status do work item;
Os Testadores geram código de teste em vários níveis;
O Gerente acompanha o andamento de todas as etapas e verifica relatórios gerenciais prevendo possíveis problemas de tempo, qualidade ou custo;
Todos são constantemente informados sobre os eventos relacionados consigo;
Releases (entregáveis) podem ser programados para dias específicos, incluindo os artefatos que se deseja;
Todos os itens do projeto são salvos no Version Control integrado ao Team Foundation Server;

Esta iniciativa da Microsoft embora não resolva 100% dos problemas existentes hoje, certamente chega próximo.


Versão 2.0 do .Net FrameWork

A nova versão é 100% backward compliance, ou seja todo o código existente nas versões 1.0 e 1.1 são totalmente compatíveis, sem necessidade de conversão. Mesmo assemblies já compilados (DLL’s e EXE’s) podem interagir com código 2.0 sem problemas. Melhoria de performance.

Existem várias novas classes e conceitos introduzidos nas linguagens C# e VB.Net que facilitam o desenvolvimento, entre elas:

Generics
Classes parciais
Compressão de arquivos nativamente
Porta Serial

ADO .Net 2.0 (Acesso a Dados)

Aqui as novidades são consideráveis, pois existem novas classes como: DataSet.GetDataReader que retorna uma DataTableReader, proporcionando jogar num DataTable o conteúdo de um DataReader; Cache na tabela, o qual permite atribuir um cache diretamente a uma tabela do SQL Server; Serialização binária. O System.Data.Commom provê DataTable com Enum dos Providers, DataTable com GetSchema DbProviderFactory, DataAdapter.FillLoadOption e a propriedade AcceptChangesDuringUpdate, DataRow com as propriedades SetAdded e SetModified, ReadXml, ReadXmlSchema, WriteXml, WriteXmlSchema, Clear, Clone, Copy, Merge, GetChanges, System.Data.SqlTypes.SqlXml. Enfim, toda a parte de manipulação de XML tornou-se mais fácil por ter classes prontas. Mas, o destaque ocorre por conta de atualizações em Batch, ou seja, você pode determinar que operações como Insert, Delete e Update pode ser feita em Batch em horários que não compromete o desempenho da aplicação.


ASP .Net 2.0 (Desenvolvimento Web)

Se o ASP.NET 1.1 já é produtivo, a versão 2 é muito melhor. Com os novos controles de acesso à dados como GridView, FormView e DetailsView tornaram a criação de páginas e a manutenção de registros extremamente simples, rápida e o melhor, sem nenhum código escrito. Cerca de 70% dos códigos digitados no ASP.NET 1.1 deixarão de existir, pois estão encapsulados diretamente nos controles. É importante ressaltar que existem mais de 50 novos controles como: Login, Segurança, TreeView, Themes, etc.

Windows Forms (Desenvolvimento Windows)

Além de novos controles, a integração com dados ficou extremamente simplificada e eficiente. Um destaque é a introdução do Click Once, um conceito novo de deployment que reduz a um click toda a distribuição, instalação e futuras atualizações de versão do aplicativo para os clientes. A aplicação pode ser disponibilizada no site HTTP, FTP ou File Share.

Produtividade

A IDE do Visual Studio 2005 trouxe vários recursos que auxiliarão os desenvolvedores no seu trabalho, reduzindo o tempo de escrita de código padrão, deixando mais livre para se concentrarem nas regras de negócio propriamente ditas. Estas são apenas algumas das novas features:

Line Revision – Tracking de alterações para fácil visualização de diferenças entre código salvo e não salvo;
Refactory – Melhorias na legibilidade do código;
Snipets – Blocos de código pré-definidos e customizáveis;
Smart Tags – Recurso que permite a customização de controles, extensível;
FxCop – Análise do código criado, mostra sugestões de melhoria na escrita de código visando performance, padronização e aderência a modelos predefinidos;Debugging – Ficou muito mais fácil o processo de depuração, com recursos Edit e Continue, Intellisense;

Diagnosticando Aplicações .Net (Performance e Exceptions)

Por Mauricio Medina e Paulo Barros

Muito raramente se encontra uma equipe de desenvolvimento que realmente se preocupe com a saúde da aplicação ao longo do tempo. O que comumente se vê é o ciclo: desenvolvimento, testes/homologação e deployment (suprimimos aqui as fases de concepção). Depois de algum tempo de implantada, geralmente de 1 a 3 meses, a aplicação é dada como finalizada e estável. Nada está mais longe da verdade.

Existem uma série de fatores internos e externos que “conspiram” para desestabilizar a aplicação. Por exemplo: a aplicação está constantemente sofrendo modificações em seus dados, que podem crescer rapidamente afetando o desempenho, o ambiente no qual a aplicação está não é de modo algum estático, o tráfego de rede pode aumentar devido a um maior número de usuários, a performance de resposta do banco de dados pode ser afetada por outras aplicações que agora utilizam o mesmo servidor, uma nova aplicação está demandando mais CPU, um novo componente instalado no servidor está interferindo e assim vai. As possibilidades são inúmeras para que uma aplicação entregue como OK venha a dar pau meses depois e isso acontece com maior frequência do que imaginamos. Até aqui nenhuma novidade.

Quais são então as boas práticas que deveríamos adotar afim de minimizar os possíveis problemas que uma solução venha a apresentar durante a sua vida?
Este artigo mostrará algumas dicas úteis.

Procurando uma agulha num palheiro

Uma difícil tarefa sempre que se fala que uma aplicação “está lenta” é responder às seguintes perguntas:
· O quão lenta está?
· Lenta em relação a quê?
· O que exatamente está causando o gargalo?
O problema reside muitas vezes na falta de um baseline, ou métricas básicas de referência, que serviriam pra dizer o que é aceitável para cada aplicação. Sem algo em que nos basear, teremos apenas o usuário que na semana passada usou a mesma funcionalidade e “percebeu” que agora está muito pior. Como argumentar com ele? Como dizer que está tudo bem e que ele está vendo coisas? E se ele tiver razão? (por mais incrível que pareça, às vezes esses espécimes estão certos) Bem, se você não tem um baseline fica sem parâmetros.
Outro fator preocupante é a maneira como a maioria realiza os testes a fim de diagnosticar os defeitos da aplicação. Sem ferramentas automatizadas os testes são no mínimo imprecisos e fornecem pouca ou nenhuma informação para se chegar ao cerne da questão. A saída é usar gambiarras paliativas que mascaram a situação. Sem os instrumentos apropriados, identificar o verdadeiro culpado (sistêmico, não humano) fica tão difícil quanto encontrar uma agulha num palheiro.

Acertando o passo

Para irmos na direção certa é preciso criar uma cultura organizacional que envolve disciplina e encontra muita resistência por parte das equipes de TI, mas que tem-se provado benéfica a longo prazo.
O primeiro passo é ter em mente que a aplicação é passível de mudanças mesmo que seu código fonte permaneça inalterado durante meses (desejo utópico dos desenvolvedores) devido aos fatores já citados. Daí temos que estabelecer um baseline para cada aplicação.
A cada mudança de qualquer natureza devemos refazer os testes para verificar preventivamente como está a saúde da aplicação. Isso tem um custo e por isso muitas vezes é descartado como sendo desnecessário. No entanto corrigir um problema imprevisto em produção pode sair muito mais caro.

Preparando os testes

Neste artigo demonstraremos como testes de performance e de tratamento de exceções em aplicações .Net podem nos ajudar a cuidar bem das aplicações das nossas empresas, preparando-nos para as mudanças inevitáveis com um mínimo impacto. Para isso usaremos o Intercept Studio da AVICode.

Testes de performance

Sem entrar em detalhes sobre a instalação e configuração da ferramenta no ambiente, vamos direto à preparação do agente para capturar problemas de performance numa aplicação web específica. Definimos o que consideramos aceitável e habilitamos o monitor. Todas as ações que excederem o tempo configurado serão interceptadas, analisadas e enviadas para um banco de dados central (Access ou SQL Server).

Poderíamos detalhar melhor o que desejamos monitorar como um método, namespace, assembly, etc:


No módulo de visualização filtramos o tipo de problema que queremos analisar, em que máquina, qual aplicação e em qual período. Vemos no exemplo abaixo páginas aspx com problemas de performance na execução de stored procedures SQL Server:

Podemos visualizar os detalhes de cada ocorrência como erro de SQL, tipo de acesso (neste caso um DataReader), parâmetros usados, tempo de resposta:

Comparar com outros eventos similares:

Verificar os pontos mais críticos do sistema e compará-los com outras aplicações:

Ou ver os tipos de origem do erro por aplicação e quanto isto representa em percentual:




Desta forma temos informações suficientemente precisas de onde está a raiz do problema e portanto não sairemos atirando pra todo lado sem ter certeza do sucesso. No caso exemplificado o problema estava na execução da procedure, foge do escopo deste artigo descer nesse nível, que poderia envolver uma modelagem mal-feita, problemas de rede, hardware, ou o estagiário de infra que mexeu no agendamento do job de reindexão do banco. O ponto é: sabemos agora onde cavar.

A ferramenta já vem por default configurada para capturar os principais vilões responsáveis por problemas de performance como providers de acesso a dados, serviços de mensagem, chamadas remotas de procedimentos, entre outros. Além disso é possível customizar seu alvo:



Capturando erros inesperados

Da mesma forma configuramos o agente para capturar erros da aplicação, entradas no event log ou manipuladores customizados de erro criados pelo desenvolvedor.

Visualizamos a lista filtrada:

E os detalhes:

Podemos identificar onde exatamente no código o erro aconteceu e com o auxílio do plug in para o Visual Studio já abrir o fonte para a correção:

Vimos aqui que é possível com um mínimo esforço conseguir diagnosticar problemas muitas vezes complexos. Se tomarmos por alvo desenvolver e manter aplicações que sobrevivam às intempéries do dia-a-dia começaremos hoje mesmo a medir e periodicamente testar como andam nossas “crianças” para que não virem “monstrengos”.