Quando estamos desenvolvendo em equipe, precisamos tomar uma série de cuidados para sinalizar para os outros programadores o que fizemos ao longo da nossa jornada de trabalho, para que não ganhemos uma parcela de culpa quando as lambanças acontecem. É como dirigir um carro, para não correr riscos de que um acidente ocorra devemos estar atento não só ao que estamos fazendo como também contribuir de forma positiva para que os outros não errem, através de setas, piscadas de farol e buzinas.

Partindo deste princípio, veremos neste artigo como sinalizar para os clientes das nossas classes, detalhes que não podem passar despercebidos. Vale lembrar que deixar um bilhete sobre o teclado do colega de trabalho com instruções de como terminar o seu trabalho, após ter passado o final de semana na empresa resolvendo “quase tudo” pode não ser a melhor saída, especialmente se no local onde trabalha venta muito ou há funcionários da limpeza desatentos. O caminho correto seria recorrer ao email da empresa para comunicar ao restante da equipe o que ficou por terminar, mas como existe o risco do email estar fora do ar ou de ocorrer algum outro imprevisto, precisamos nos cercar de cuidados extras para garantir, por exemplo, que algo que não deve subir para testes ou para produção, acabe indo para o ar por descuido. Sei que muitos dirão que algo jamais deverá ir direto para produção sem ser testado, o que concordo plenamente e sempre defendo, mas todos sabem que quando a corda aperta, muitas empresas de consultoria passam a trabalhar de forma errada e as ordens vêm de cima para baixo.

A forma mais indicada de sinalizar que algo está incompleto, desatualizado ou que não deve ser compilado até estar pronto de fato, é no próprio código. Embora saibamos que os demais desenvolvedores provavelmente não irão inspecionar o nosso código em busca dos comentários a cada build, especialmente com o gerente grudado com pressa de colocar a última versão no ar, podemos forçar o Visual Studio a avisá-los. Isto é feito através de diretivas de compilação, que são palavras especiais usadas pelo seu código para manipular o compilador, e de comment tokens (como o //TODO:) sobre os quais falaremos em um artigo a parte.

Utilizamos as diretivas #warning e #error em C# para gerar alertas e erros de compilação respectivamente. Para vê-las em funcionamento, crie uma aplicação do tipo Console Application em C# e salve-a como TestaDiretivasCompilacao.

Inclua o seguinte código no arquivo Program.cs que foi gerado pelo template:

using System;

using System.Collections.Generic;

using System.Text;

namespace TestaDiretivasCompilacao

{

class Program

{

private static void metodo1()

{

#warning Este código ainda não foi testado

}

private static bool metodo2()

{

return true;

}

static void Main(string[] args)

{

metodo1();

bool resultado = metodo2();

}

}

}

Compile o exemplo e veja que apesar do código executar, foi gerado um alerta para o desenvolvedor, tal qual especificado pela diretiva #warning. Note que esse era o comportamento esperado, uma vez que alertas não impedem nem a compilação nem a execução de um programa.

Percebeu a utilidade deste recurso, especialmente em sistemas muito extensos que envolvem vários desenvolvedores?

Outra situação comum em que podemos recorrer a warnings é quando temos um método que se tornou obsoleto e não desejamos mais que as novas aplicações o utilizem. Sua permanência no código se deve a questões de compatibilidade retroativa por este estar sendo usado pelo código legado, mas o que combinamos internamente com a equipe foi o de fazer uso de uma implementação mais nova equivalente. Para este cenário, devemos adicionar o atributo Obsolete ao método. Vamos alterar o exemplo anterior, sugerindo que ao invés de chamar metodo1 o programador chame metodo2:

[Obsolete("Use o novo metodo2 no lugar de metodo1")]

private static void metodo1()

{

}

Confira o resultado que obtemos na janela de erro ao compilar o exemplo:

Novamente temos um programa que compila, mas perceba que o Visual Studio ainda assim nos avisa que há algo que não está como esperado...

Impedindo a compilação

Agora imagine que precisemos ir além e evitar que alguém da equipe chegue mais cedo e suba para o servidor de testes, homologação ou produção o código no qual você ainda está trabalhando. Para este caso, devemos usar a diretiva #error que impede que a compilação ocorra com sucesso. Experimente adicioná-lo ao método metodo2, conforme o exemplo a seguir:

private static bool metodo2()

{

#error Não disponibilizar para testes enquanto não finalizar metodo2

return true;

}

Uma vez mais, tente compilar o programa. Veja na janela a seguir que um erro ocorreu e já não é mais possível seguir o processo até o final.

MCP – MCAD – MCTS