Arquivo mensais:dezembro 2010

Arquitetos devem saber programar o seu design

97ThingsOlá pessoal!

No meu primeiro post neste blog eu falei sobre um capítulo do livro “97 Things Every Software Architect Should Know”. O capítulo tratava de um comportamento bastante comum e, no entanto, bastante repugnável, a arrogância. Neste post eu falo sobre três capítulos deste mesmo livro, porém, desta vez o tema é relacionado às habilidades de programação de um arquiteto.

O livro citado é composto por diversos capítulos curtos, onde cada um deles traz conselhos e experiências de diversos arquitetos renomados, de diversos lugares do mundo. A ideia geral do livro é que cada capítulo trate de um assunto distinto, formando assim um conjunto de coisas distintas que todos nós deveríamos saber. No entanto, notei que três capítulos deste livro tratam de um mesmo tema, denotando a sua importância. Veremos então a seguir a ideia geral dos três capítulos e também algumas passagens.

Architects Must Be Hands On – página 38 – John Davies

Neste capítulo, John Davies diz que um arquiteto deve ser capaz de preencher qualquer posição em um time, desde o cabeamento de rede, até a configuração do processo de compilação e a execução de testes unitários, por exemplo. Para enfatizar, ele ainda diz: “Without a good understanding of the full range of technology, an architect is little more than a project manager”. Ele diz ainda que os desenvolvedores devem ver um arquiteto como um líder, capaz de dar exemplos que possam ajuda-los a se desenvolver. Arquitetos que não possuam conhecimento sobre uma determinada tecnologia empregada em um projeto não podem esperar que os desenvolvedores tenham confiança nele.

Before Anything, an Architect Is a Developer – página 126 – Mike Brown

Neste capítulo Mike Brown faz uma associação entre a carreira de um arquiteto e outras carreiras de outras áreas, porém, que requerem o mesmo nível de senioridade. Ele diz, por exemplo, que nenhum juiz nunca foi um advogado e que nenhum chefe de cirurgia nunca foi um cirurgião. Ele diz ainda que as pessoas que ocupam estas posições devem continuar a se atualizar e a se desenvolver em suas respectivas áreas. Isso não é diferente para nós arquitetos. Outro ponto bastante interessante colocado pelo Mike é que o código de um arquiteto é a sua moeda, sendo esta a forma mais eficiente para ganhar a confiança dos desenvolvedores. E para finalizar, Mike ainda diz: “Part of knowing what is feasible in a solution is having knowledge of the effort involved in developing the elements of the solution".

If You Design It, You Should Be Able to Code It – página 150 – Mike Brown

Neste capítulo Mike Brown diz que é muito tentador para nós arquitetos criarmos designs bem elaborados e abstrações que endereçam os problemas de forma bastante elegante. Ele diz ainda que é ainda mais tentador experimentar novas tecnologias em um determinado projeto. Porém, Mike diz que temos que pensar que no dia-a-dia, quem implementará o que ele chama de acrobacias arquiteturais, são os desenvolvedores e que isso normalmente traz impacto para o projeto. Mike ainda aconselha:

“Don’t use a pattern in your design that you haven’t personally implemented before. Don’t rely on a framework that you haven’t coded against before. Don’t use a server that you haven’t configured before. If your architecture depends on design elements that you haven’t personally used, there are a number of negative side effects:

  • You will not have experienced the learning curve that your developers will have to face;
  • You will not know the pitfalls to avoid when using the elements;
  • You will lose the confidence of your developers;
  • You will introduce unecessary risk.”

Quick Dev: Melhorando a performance de aplicações ASP .NET

Olá pessoal!

Quem nunca se incomodou com o tempo levado para a recompilação de aplicações ASP .NET já publicadas? Pois é, cada vez que um arquivo “top-level” é alterado em sua aplicação ASP .NET, por padrão, toda a compilação do site feita no seu primeiro acesso é invalidada, causando uma recompilação no próximo acesso. São considerados arquivos “top-level” os arquivos global.asax e todos os arquivos da pasta bin e app_code. Isso pode se tornar um problema para grandes aplicações, pois, o tempo de recompilação pode se estender além do desejável, podendo chegar a mais de dez minutos, dependendo do tamanho da aplicação, conforme registrado na documentação da Microsoft (veja o link no final deste post).

Para contornar este problema, a Microsoft incluiu um recurso no .NET que nos permite habilitar o que é chamado de compilação otimizada. Esta compilação é um pouco mais inteligente do que a padrão, de forma que, ao invés de recompilar o site inteiro quando um arquivo top-level é alterado, apenas os arquivos afetados pela sua alteração são recompilados, diminuindo o tempo total da recompilação e por consequência, o tempo de espera do primeiro acesso após a modificação.

Para ativar a compilação otimizada, basta incluir a configuração a seguir dentro do elemento system.web do arquivo web.config da sua aplicação. O recurso já está disponível no Windows 7, Windows Server 2008 Service Pack 2 e Windows Server 2008 R2. Para o Windows Vista Service Pack 1 e Windows Vista Service Pack 2, é necessário instalar o seguinte hot-fix: http://code.msdn.microsoft.com/KB967535.

Problema resolvido? Não totalmente. Com este recurso habilitado, é preciso ficar muito atento aos tipos de alteração que são feitas na aplicação. Isso porque, se apenas os arquivos afetados diretamente pela modificação são recompilados, podem ocorrer erros quando um arquivo da versão antiga precisar acessar algum recurso não mais compatível na versão nova. Por exemplo, imagine uma página que acessa um método de uma determinada classe, que teve sua assinatura alterada na modificação realizada. A classe publicada é recompilada, porém, a página não, o que causa um erro quando da sua execução.

Para mais detalhes sobre o assunto veja a documentação completa a respeito no artigo: Understanding ASP.NET Dynamic Compilation. Não deixe de considerar também a opção de utilização da pré-compilação: ASP.NET Precompilation Overview.