Bibliografia sobre Agile

Recebi de um amigo uma lista de livros interessnates sobre Agile e resolvi publicar:

The Object Primer: Agile Model-Driven Development with UML 2.0 (Paperback)
by Scott W. Ambler
http://www.amazon.com/Object-Primer-Agile-Model-Driven-Development/dp/0521540186/ref=sr_1_1?ie=UTF8&s=books&qid=1251737576&sr=8-1

Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (Paperback)
by Scott Ambler
http://www.amazon.com/Agile-Modeling-Effective-Practices-Programming/dp/0471202827/ref=pd_sim_b_1

Extreme Programming Explained: Embrace Change (2nd Edition) (Paperback)
by Kent Beck
http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_2?ie=UTF8&s=books&qid=1251737638&sr=1-2

Planning Extreme Programming (Paperback)
by Kent Beck
http://www.amazon.com/Planning-Extreme-Programming-Kent-Beck/dp/0201710919/ref=sr_1_5?ie=UTF8&s=books&qid=1251737638&sr=1-5

Test Driven Development: By Example (Paperback)
by Kent Beck
http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ref=sr_1_3?ie=UTF8&s=books&qid=1251737638&sr=1-3

O Mitico Homem-Mês
Ensaios Sobre Engenharia De Software
FREDERICK P. BROOKS JR
http://www.livrariacultura.com.br/scripts/cultura/resenha/resenha.asp?nitem=2843186

Por favor, ajudem a complementar essa lista!

Abraços!

Profissionais de TI pioram com o tempo

Essa é uma realidade na área de software, com o passar do tempo desempenhando as mesmas atividades ou participando sempre de projetos semelhantes o profissional tende a desenvolver vícios e manias que o atrapalham (ou até o impedem) a encarar novas metodologias, paradigmas ou até linguagens.

“Na área de informática você precisa estar sempre atualizado!”, essa frase batida (que até minha vó de 80 anos já disse) não tem a devida atenção dos profissionais de TI. Vejo muitas pessoas saírem de uma graduação de quatro anos e pensarem que estão prontas pro mercado, mas a realidade da área muda praticamente a cada ano (sendo otimista) o que faz com que o profissional recém formado já seja inserido no mercado desatualizado.

Acredito que um profissional de desenvolvimento deva sempre olhar pros seus projetos passados e pensar: “Eu não sabia trabalhar naquela época!”. Se o mesmo avaliar um projeto de seis meses atrás e achar que nada pode ser melhorado (ou completamente substituído) é hora de repensar a carreira e os estudos.

Entendo perfeitamente que é difícil alocar tempo para uma atualização constante, porém, toda área de atuação tem seus prós e contras, no caso de TI é a quantidade de novidades inseridas em um curto espaço de tempo, mas como estamos na era do conhecimento (com o apoio do Google) isso não é tão complicado como a dez anos atrás, e afinal de contas foi a área que você escolheu.

Se você reclama todos os dias das dificuldades do seu trabalho e/ou passa o dia suspirando pensando no final do expediente é sinônimo que escolheu a área errada. A área de TI (assim como outras) necessita de pessoas que tenham paixão pelo trabalho e sejam comprometidas com o mesmo (perfil raro hoje em dia).

A quanto tempo você usa a mesma plataforma de trabalho? Como você procura se manter atualizado? Seus métodos de trabalho mudaram nos últimos seis meses? Boa reflexão.

O objetivo desse texto é explicar de forma rápida o que considero a área e o profissional de TI, e espero ajudar a direcionar reflexões sobre a carreira profissional, evitando equívocos e incentivando mudança de atitudes, porém, vocês também podem considerar como um desabafo de alguém que acabou de sair de uma prova .

Abraços!

Escopo variável em projetos de software

Quantos projetos de software você conhece que foram entregues no prazo e não sofreram alteração de escopo durante o seu desenvolvimento?

Os contratantes de software tem uma falsa idéia de que com um escopo bem definido eles estarão seguros com relação ao produto final que será entregue, e os fornecedores por sua vez de que estarão resguardados contra alterações de requisitos durante o desenvolvimento do software, o que na prática é equivalente ao “Até que a morte os separe” de alguns casamentos.

Quando um contratante decide implantar um software na empresa, ele quer agilizar seus processos e/ou resolver seus problemas, porém, em muitos casos ele acaba gerando novos problemas com os quais não contava. Um projeto de software que dure 1 ano certamente sofrerá alterações de escopo por que é impossível definir todas as nuances de uma implantação antes de começar seu desenvolvimento, então, por que não criar contratos mais flexíveis que permitam novas implementações durante o desenvolvimento? Afinal de contas, se um fornecedor quiser quebrar um contrato, não é um pedaço de papel que irá impedi-lo, na verdade, esse pedaço de papel só vai criar mais problemas.

Os fornecedores por sua vez não deveriam encarar uma prestação de serviço como um contrato comum, mais sim como uma parceria, o objetivo de um profissional de TI é simplificar e viabilizar e não discutir requisitos em contratos cobrando preços absurdos por alterações.

A grande questão é que o mercado como um todo desde o início tratou contratos de softwares de forma equivocada, comprar um software não é comprar uma cadeira, você está pagando o desenvolvimento de algo intangível, o ideal seria pagar o tempo de desenvolvimento e acompanhar todo o processo de construção de perto verificando sempre se o projeto está alinhado com suas necessidades.

Acredito que aceitar que projetos de software são problemáticos é muito cômodo, por que não tentar um novo modelo de contratação? O modelo atual de contratação funciona?

O artigo que escrevi sobre comunicação com o cliente complementa essa visão de trabalho.

Abraços!

O que vale mais, experiência profissional ou faculdade?

A resposta a essa pergunta varia de acordo com a vivência de quem você pergunta. Conheço várias pessoas (minha mãe sendo uma delas) que sem faculdade venceram na vida e estão muito bem obrigado. Por outro lado, existem no mercado pessoas boas recém formadas esperando a oportunidade aparecer.

Bom, no meu ponto de vista se a pessoa está esperando a oportunidade aparecer algo já está errado, pois no mercado de trabalho nada cai do céu, principalmente na área de TI onde você tem que sempre estar buscando atualizações. O bom estudante inicia seus estágios na área (nem que seja não remunerado) logo no início do curso, posso parecer um pouco radical, mais investir 4 anos da sua vida em um curso onde você não vai tirar o máximo proveito é jogar dinheiro e principalmente tempo fora.

A faculdade que eu estudo sempre promove palestras interessantes com empresários e profissionais da área de TI, porém, vejo vários alunos não entendendo a riquesa das palestras, e isso se deve ao fato do aluno nunca ter sentido na pele o que é o mercado de trabalho referente ao seu curso. Quando faço processos de seleção e recebo pessoas do sétimo e oitavo período fico frustrado com a falta de experiência profissional dos candidatos.

Falando um pouco dos empresários que não cursaram faculdade, acho que as melhores características de uma pessoa eles já provaram que possuem que é coragem, audácia e principalmente, ter o seu negócio no coração. A questão é que sem faculdade é mais difícil lidar com algumas situações do dia-a-dia onde você teria estudado técnicas de como contorná-las, porém, esse não é o maior problema, qualquer empresa sem conhecimento teórico só cresce até certo ponto, por quê? Por que a faculdade ensina a você que era o melhor nadador da sua rua a competir com nadadores profissionais do outro lado do mundo. A faculdade expande os horizontes do empreendedor e muda sua visão perante o negócio.

A última empresa que dei consultoria é a típica empresa que pra atingir Brasil só faltam acertar alguns detalhes, mas sem esses detalhes é arriscado investir no mercado nacional e dar um passo maior que as pernas. O fundador dessa empresa não cursou faculdade, porém, ele tem o dom de saber ouvir e não achar que está certo sempre, o que é uma ótima característica pra quem precisa de apoio.

Resumindo a história, se você é estudante arrume um emprego ou estágio na sua área, sei que é difícil, porém, é a área que você escolheu. Se você é empresário, procure alguém que te ajude a encontrar o caminho das pedras, e tenha certeza que o mais difícil você já fez, porém, nunca é tarde pra estudar .

Mais uma vez me deparo filosofando no centro de vivência da faculdade tomando um cappuccino, me distraí várias vezes mais isso é outra história.

Hora da aula.

Abraços!

Pedindo feedback à colegas de trabalho

O maior inimigo do profissional de TI é o ego.

Sempre trabalhei em equipes de desenvolvimento pequenas (no máximo 10 pessoas) e a maioria dos profissionais dessa área acham que o bom profissional é aquele que bota o fone de ouvido, abaixa a cabeça e escreve código de 08:00 às 17:00, na verdade essa também é a visão de alguns gerentes (gerentes de empresas que trabalhei e não existem mais).

Há tempos não trabalho em ambientes desse tipo onde a diferença entre a máquina e o homem é o custo, porém, como nem tudo são flores outros problemas surgem, e um deles é a falta de comunicação entre os membros da equipe.

As pessoas acham que pedir ajuda ou pedir opinião de um colega de trabalho é sinônimo de franqueza ou amadorismo, e acabam resolvendo problemas simples de formas complexas ou usando soluções alternativas técnicas de emergência (gambiarras).

Sempre que termino uma tarefa no trabalho, mostro o resultado final para um colega de equipe, dessa forma faço uma validação de tudo que fiz e posso ganhar de bônus dicas de melhorias (que serão implementadas nessa tarefa e na próxima). Melhor do que o feedback do colega é a troca de informação, se todos os membros da equipe fizessem o mesmo o projeto teria uma codificação quase unificada, ou seja, um estilo único de trabalho e não o estilo do João ou do José.

Comunicação é a base para um ambiente produtivo e de qualidade, ou seja, pedir feedback ao colega de trabalho não é sinônimo de amadorismo e sim de profissionalismo.

E você? Quando foi a última vez que pediu um feedback à alguém do seu trabalho?

Agora vou terminar meu cappuccino e ir pra aula.

Abraços!

Comunicação com o cliente

Comunicação é a base para um bom relacionamento, seja ele qual for.

Eu estava esses dias olhando pra cima e pensando nos projetos em que trabalhei no ano passado e fazendo uma retrospectiva das metodologias que usava (graças a Deus eu vi a luz e passei a usar metodologias ágeis) e percebi que em alguns projetos a comunicação com o cliente foi o alicerce para que não houvesse traumas no serviço. O problema da área de software é que as pessoas não consideram a pessoa como o fator principal do projeto e isso implica em pouca comunicação e mais processos e contratos e contratos rigorosos.

Sempre procuro estar em contato constante com meus clientes, não só pra apresentar soluções inteligentes pra mostrar serviço mais também para mostrar problemas e solicitar a ajuda deles em tudo que for possível, afinal de contas é o meu cliente que tem o conhecimento do negócio . Já vi empresas de software tentando resolver problemas atrasando a entrega e depois descobrir que aquele requisito que estava atrasado poderia ter sido entregue separadamente e feito com mais calma (afinal de contas, nada que é feito as pressas é testado corretamente).

Apesar de ir contra o pensamento da maioria dos profissionais da área de desenvolvimento, acho que o jogo aberto com o cliente desde a negociação faz com que o mesmo se sinta parte da equipe, e é aí que o projeto ganha um dos parceiros mais importantes, o cliente.

Bom, essa é a minha visão de contato com o cliente, comunicação constante. Esse pensamento tem dado certo pra mim, afinal de contas tenho clientes que começaram a trabalhar comigo desde os 17 anos (nem sabia o que era software ainda, rs).

E você? Mantém comunicação constante com seus clientes?

Agora vou prestar atenção na minha aula da faculdade.

Abraços!

Faça mais com menos em qualquer área

Hoje estava lendo os twits da manhã e me deparei com a frase “Less is more”, a mesma havia sido dita no Digital Age, ela me diz muita coisa.

Iniciei no mês passado uma análise de negócio com uma empresa capixaba onde me propus a analisar os problemas da empresa e indicar soluções. Na reunião que fizemos levantamos vários problemas da empresa, porém, só nos preocupamos em indicar as soluções para os principais problemas, por quê? Se você cura o câncer de alguém acha que essa pessoa vai ligar pra uma dorzinha no dedo? Claro que não. A idéia aqui é fazer menos e conseguir os melhores resultados.

Em palestras e aulas que dou sobre desenvolvimento de software sempre ponho essa idéia, um código que é mais simples e menor resolve o problema do mesmo jeito que um código complexo com a vantagem que o estagiário entende, ou seja, não importa o quanto você digita, o resultado final que irá medir a sua eficiência.

Vejo muitos profissionais conhecidos achando que trabalhar mais é sinônimo de resultado, mais o erro mora aí, a idéia é fazer o mínimo possível (a quem diga que a idéia é fazer menos) resolvendo o problema ou atingindo o objetivo.

Quantas vezes já vi projetos atrasarem por que desenvolvedores querem perfumar a aplicação sendo que o que o usuário precisa já estava pronto, e aquele “a mais” acaba gerando contratempos que atrasam o projeto, o cliente não quer saber de perfumaria, ele quer saber de higiene pessoal.

Acho que a mensagem aqui é trabalhar muito não é sinônimo de resultado. Trabalhar o mínimo para resolver um problema, desenvolver um software ou atingir o objetivo é a saída para soluções diretas e de baixo custo.

Bom, acabou meu horário de almoço.

Abraços!

Complementos do Firefox

Olá,

Estou algum tempo sem escrever principalmente pelo fato de ter conseguido algumas coisas mais cedo do que eu previa e as mesmas estarem exigindo muito tempo.

Pretendo agora escrever artigos semanalmente, mesmo que mais breves, porém, mantendo a qualidade da informação.

A empresa que estou alocado em um projeto oferece semanalmente treinamentos para os colaboradores, o mesmo é oferecido pelos próprios, ou seja, uma troca que informações que ocorre no horário de trabalho. Apesar de não ser contratado da empresa, já dei um ou dois treinamentos lá, afinal de contas sou professor e gosto de fazer coisas do tipo (e também vale como atividade complementar na Faesa). Um desses treinamentos abordou um tema interessante, os complementos do Firefox que são úteis no dia-a-dia do desenvolvimento web, o treinamento foi ofertado pelo meu colega Osias.

Como sou fã assumido do Firefox e usuário assíduo do Firebug, dei uma conferida na lista e testei vários, realmente são muito úteis, vamos à eles então:

Firebug

Se você desenvolve pra web e não conhece esse complemento ainda não viu a luz no fim do túnel. O mesmo possibilita que você edite várias (se não todas) as características dos elementos de um documento html, permitindo por exemplo alterar css, html e depurar javascript. Desde de que aprendi a estruturar documentos usando os padrões w3c não vivo sem esse complemento.

Check4Change

Complemento que checa periódicamente se a página sofreu alguma alteração.

ShowCase

Permite visualizar todas as abas abertas e manipular as mesmas de forma mais amigável.

IETab

Abre uma aba para visualização da página no horrível popular IE. O ganho de produtividade é alto levando em consideração que pra desenvolver cross-browser você precisaria testar em ambos.

MinimizeToTray

Minimiza o Firefox para a bandeja do sistema.

Extended StatusBar

Várias informações sobre o carregamento da página no estilo Opera na bassa de status.

Lazarus

Recupera informações de formulários. Muito útil na maldita hora de realizar testes de interface.

Locationbar ao quadrado

Divide a url em pedações possibilitanto uma maior comodidade para usuários mais experiêntes.

NoScript

Desabilita o javascrit por páginas, ou seja, diminui o risco de acesso à alguns sites.

QuickRestart

Possibilita reiniciar o firefox sem perder as abas abertas (útil ao instalar complementos por exemplo)

FireGestures

Possibilita a navegação por gestos. Eu ainda não me acustumei com esse complemento, acho ele muito Harry Potter, porém, algumas coisas você só pode fazer com ele.

LinkAlert

Ao passar o mouse sobre um link o mesmo irá apresentar um ícone indicando o destino do mesmo.

TabScope

Mostra uma prévia da aba sem precisar abri-lá.

FEBE

Permite de forma rápida criar e recuperar backups dos complementos do firefox.

Stylish

Possibilita alterar permanentemente o estilo de uma página na sua máquina.

GreaseMonkey

Possibilita incluir javascripts poderosos em páginas.

Bom pessoal, acho que é isso. Agora vou pro trabalho concluir uma ferramenta que facilita (ou melhor, viabiliza) a utilização do Xaf da DevXpress e depois tem faculdade onde aprendo as novidades das metodologias usadas nos anos 80, show de bola.

Abraços!

Extensions Methods

Tecnologias

• Framework 3.5
• C# 3.0

MSDN

• Extension Methods (C# Programming Guid)
• How to: Implement and Call a Custom Extension Method (C# Programming Guide)

Introdução

Olá pessoal, hoje vou falar um pouco sobre essa novidade do C# 3.0 que são os Extension Methods. Minha motivação para escrever esse artigo foi uma discussão que tive com alguns colegas de trabalho sobre a padronização da utilização desse recurso e quando utilizar ou não o mesmo.

Os Extension Methods permitem que o desenvolvedor adicione métodos a um determinado tipo sem a necessidade de alterar o código fonte original ou criar tipos derivados. Os métodos que são adicionados têm as mesmas características de um método estático, porém, a utilização dos mesmos funciona como se eles fossem métodos de instância. Esse recurso foi largamente utilizado para disponibilizar os métodos que trabalham com LINQ na versão mais recente do framework .net.

Definição

A definição é relativamente simples, para criar um extension method siga os seguintes passos:

1. Crie um arquivo de código.
2. Defina uma classe estática.
3. A classe deve estar em um namespace acessível para os clientes.
4. Defina um método estático com o primeiro argumento sendo do tipo que você pretende estender, antes do tipo adicione a palavra “this”.
5. Escreva o corpo do método.

Ao final, você terá algo semelhante à imagem 01:

Imagem 01

Como podem ver na linha 1, defini que minha classe ficaria no namespace System, fiz isso por que a classe String também está nesse namespace, logo, quem estiver usando a classe também terá acesso ao método ToInt32.

Na linha 3 defini a classe StringExtensions como sendo pública e estática. Você pode usar o nome que quiser para a classe.

Dica
Eu adotei um padrão onde o nome da classe estática fica sendo sempre o tipo que estou estendendo seguido da palavra Extensions.

Na linha 5 declarei o método estático ToInt32, vocês podem reparar que a grande diferença aqui é a utilização da palavra this antes do primeiro parâmetro do método. O método tem que ter no mínimo um parâmetro sendo do tipo que você pretende estender.

Vejam como ficou a utilização do método na imagem 02:

Imagem 02

Como vimos, a utilização do método fica bem prática, como se o mesmo fosse de instância, e não estático.

Quando utilizar?

Apesar de ser um método estático, o mesmo será utilizado como um método de instância, logo, o ideal é utilizar esse recurso quando faça sentido que o método seja utilizado assim.

Vale a pena utilizar esse recurso, pois a sintaxe fica bem mais limpa do que um método utilitário normal.

Imagem 03

A imagem 03 possibilita a comparação entre a utilização convencional, e da utilização do extension method.

Dica
Métodos auxiliares nem sempre são bons candidatos a serem extension methods, exemplos de métodos que não deveriam utilizar esse recurso: FormatarCpf(), FormatarCnpj(), EhEmailValido(). Nesses casos, continue utilizando os métodos estáticos convencionais no padrão de assistente.

Organização dos arquivos

A organização dos arquivos é um ponto crucial para trabalhar em projetos com vários desenvolvedores. Quando usamos extensions podemos confundir o time de desenvolvimento já que os métodos não ficam junto com a definição do tipo, logo, use um padrão que fique bem explícito que o projeto usa esse recurso.

Imagem 04

A imagem o4 mostra como organizei os arquivos do projeto de exemplo, notem que existe uma pasta específica para Extensions, onde ficam os métodos para tipos do sistema, como string, int, etc. No caso da interface IPessoa, seus métodos ficam em um arquivo de mesmo nome com sufixo “.sufixo”.

Dica
Defina o padrão que atende melhor as necessidades do projeto e da equipe de desenvolvimento, a regra não é usar o padrão que estou usando, mais sim usar um padrão que todos os envolvidos no projeto entendam.

Mixin

Um efeito colateral bom da inserção dos extension methods é o fato do desenvolvedor poder adicionar comportamentos a interfaces, esses comportamentos por sua vez poderão ser utilizados em todos os tipos que implementam a interface. As próximas imagens ilustram o cenário:

Imagem 05

Imagem 06

Imagem 07

Como podem ver, declarei uma interface IPessoa e duas classes que implementam a mesma. Adicionei um Extension Method à interface IPessoa e depois pude utilizar o método nos tipos que implementam a interface.

Veja mais sobre mixin.

Conclusão

Nesse artigo mostrei como utilizar os Extension Methods e quais são as melhores práticas envolvidas com o recurso. Espero que tenham gostado, e aguardo feedbacks.

Abraços,
Denis Ferrari

Download do projeto de exemplo.

Tratamento de erros em projetos asp.net

Introdução

Olá Pessoal, nesse meu primeiro artigo sobre desenvolvimento resolvi apresentar uma classe que sempre usei em meus projetos, a classe de rastreamento de erros. O objetivo desse artigo é fazer com que o desenvolvedor não dependa das informações do usuário para detectar onde o problema ocorreu e também estudar os recursos que o asp.net oferece para tratamento de erros.

Vamos aprender como utilizar a instrução try…catch e falar um pouco sobre programação defensiva. Veremos o que a classe de rastreamento faz e como configurar a mesma em seu projeto, e finalmente veremos como funciona a tag customErros do web.config e como configurar seu projeto para apresentar páginas de erro amigáveis.

Utilização do try… catch… finally

A instrução try cacth permite que o desenvolvedor possa gerenciar possíveis exceções em seu código fazendo com que a exceção possa ser tratada em tempo de execução de uma forma amigável.

O código acima mostra como utilizarmos a instrução em questão:

try: Nesse ponto você insere o seu código passível de erro.

catch (FileNotFoundException e): Caso o código do try dispare uma exceção do tipo entre as chaves, o trecho será executado.

catch (Exception e): A classe Exception é a mais genérica entre as classes de exceções do .net, logo, a mesma deve ser sempre a última na lista de catchs.

finally: Esse trecho é sempre executado, não importando se houve ou não erros durante a execução. Uma dica é utilizar esse trecho para liberar recursos utilizados pelo seu código, Ex.: Fechar conexões.

Dica -> Procure não disparar nos seus códigos exceções do tipo Exception, use sempre que possível uma exceção específica para o tipo do erro.

Você também pode usar o try…catch de forma aninhada como mostra a imagem à baixo:

Use sempre o try…catch em códigos suscetíveis a erros (ou seja, quase todos). Dessa forma você poderá instruir o usuário com uma mensagem mais específica para o problema que aconteceu.

Programação defensiva

Programação defensiva é um padrão de desenvolvimento que tem a Lei de Murph como uma preocupação constante. Programadores que utilizam esse padrão escrevem seus códigos tentando prever todos os erros antes que os mesmos aconteçam. Esse padrão aumenta a qualidade e a segurança do projeto como um todo.

Sou totalmente a favor desse padrão, e se tivéssemos mais adeptos os projetos de software teriam uma qualidade bem superior à atual no mercado.

Classe de rastreamento

A classe de rastreamento é uma ferramenta desenvolvida com o seguinte propósito: Armazenar todos os dados possíveis sobre a exceção para que o desenvolvedor possa rapidamente descobrir a causa da mesma e tomar as medidas de correção.

Como o código é relativamente simples, não vou posta-lo por motivos de espaço, porém, você poderá fazer o download do projeto de exemplo no final do artigo.

A classe Rastreamento possui 4 métodos privados e 1 método público:

Rastreamento.RastrearSessao: Método privado responsável por coletar todos os dados da sessão corrente.

Rastreamento.RastrearCookies: Método privado responsável por coletar todos os dados dos cookies escritos pela aplicação.

Rastreamento.RastrearServidor: Método privado responsável por coletar o valor de todas as variáveis de servidor.

Rastreamento.RastrearFormulario: Método privado responsável por coletar todos os dados que foram enviados pelo cliente via Post.

Rastreamento.RastrearExcecao: Método público que monta um relatório texto que irá contar as informações da exceções, e os dados referentes aos métodos anteriores. Esse método que será invocado para rastrearmos nossas exceções.

Para utilizar a classe em seu projeto, basta copiar a mesma para dentro da pasta App_Code.

Dica -> Você pode personalizar a classe para armazenar o relatório onde quiser, o projeto de exemplo guarda o relatório num arquivo texto, porém, o mesmo pode ser enviado por e-mail, para um sgbd, etc.

Application_Error

Para utilizar a classe de rastreamento de forma genérica é muito fácil, basta adicionar o arquivo Global.asax na pasta raiz do seu projeto e configurar o evento Application_Error como mostra a imagem:

O evento Application_Error é disparado sempre que ocorre um erro não tratado na aplicação, logo, é só pegar o último erro ocorrido e passar a exceção para o método de rastreamento.

Nesse ponto, você terá configurado seu projeto para dar um feedback de cada exceção não tratada, porém, isso ajuda somente o desenvolvedor, não é nada agradável para o usuário se deparar com a “tela amarela” do asp.net, então vou abordar como configurar páginas amigáveis de erro.

Dica -> Pratique programação defensiva, trate o maior número de erros possíveis antes de disponibilizar o projeto. Não é bonito quando o cliente se depara com uma tela de erro a cada 3 cliques.

Tag customErrors do web.config

O Asp.net oferece recursos para que possamos configurar rapidamente uma página de erros amigável para os usuários da aplicação. Veja a imagem a seguir:

Adicionando a tag customErrors na sessão system.web do web.config podemos realizar as seguintes configurações:

defaultRedirect: Página que será exibida quando uma exceção não tratado for disparada.

mode: Atributo que configura como os redirecionamentos vão funcionar. On Sempre redireciona, Off Nunca redireciona RemoteOnly redireciona quando o usuário estiver usando um endereço diferente de localhost para acessar a aplicação.

Você também pode configurar páginas de erro personalizadas para código de erro existente.

Veja o funcionamento das configurações vistas no projeto de exemplo no final do artigo.

Conclusão

De forma muito prática é possível se ter um feedback da aplicação sobre suas exceções e também poupar o usuário de “telas amarelas”, não disponibilizo nenhum projeto sem esses recursos.

Espero que tenham gostado da minha visão sobre tratamento de erros.

Estamos aí para qualquer dúvida ou sugestão!

Abraços,
Denis Ferrari

Download do projeto de exemplo.