Aqui eu registro de forma resumida os aprendizados, frases, lições, exemplos de código, tecnologias que aprendi e tive contato durante o dia a dia de trabalho.
📖
💻
😎
Clique aqui para visualizar os conteúdos separados por dia.
- .NET Core
- C#
- Code Review
- DevOps
- Métodos Ágeis
- Padrões de projeto e Código Limpo
- Testes automatizados
Deixe o código mais limpo do que estava antes de você mexer nele
A regra do escoteiro diz que um escoteiro sempre deve deixar o acampamento mais limpo do que encontrou. Em uma conversa com @vpteruel e @mvmjacobs, o @mvmjacobs comentou sobre a Regra do Escoteiro, no desenvolvimento. Desenvolvedores devem aplicar a regra no seu trabalho, onde todo código em que mexer, deve deixá-lo mais limpo do que encontrou.
Encontrei um texto interessante no blog Be code que fala sobre isso
É possível realizar uma integração de seus repositórios do GitHub e criar pipelines no Azure DevOps que sejam ativados a partir de pull requests criados no GitHub.
Para isso, abra seu Azure DevOps e: - clique em seu projeto, na tela inicial do Azure DevOps - clique no menu Pipelines - clique em new - na opção where is your code, selecione GitHub - autentique com sua conta do GitHub
Não se pode depender de um serviço externo em um teste de integração ou de unidade no qual você não tem controle.
Por exemplo:
Temos uma API que disponibiliza a temperatura de um equipamento. Uma aplicação se conecta nessa API para obter a temperatura do equipamento, e dependendo do valor da temperatura, define um comportamento esperado.
Os testes automatizados da aplicação não devem utilizar a chamada da API de temperaturas, pois caso ela esteja fora do ar, os testes não irão passar, e não teremos controle sobre isso, pois o código da API é externo. O que devemos testar, é se a chamada será realizada da forma correta.
O que podemos fazer então para resolver isso?
- Utilizar técnicas de mocking
- Criar serviços falsos para implementar o mocking
Em .NET, usando a biblioteca FakeItEasy é possível criar instâncias fakes das classes facilmente. Com isso, se criarmos uma interface com assinaturas dos métodos que são utilizados para obter os valores, podemos criar um serviço verdadeiro para realizar as chamadas da API e um falso implementando a interface criada, e nos testes da aplicação podemos criar uma instância fake, para testar a chamada.
Também em .NET, podemos usar a biblioteca MockHttp for HttpClient ou a Wiremock.NET e podemos criar um servidor http falso, podendo ser utilizado nos testes.
Em repositórios do GitHub que tiverem seus pipelines configurados no Azure DevOps é possível colocar o badge do Azure Pipelines para sinalizar o status de suas builds.
Para colocar o badge siga os passos: - clique no pipeline que deseja - clique na opção "..." - clique no menu status badge - copie o valor informado - cole no seu README.md
Um detalhe importante, é que seu projeto no Azure DevOps deve estar público para que o badge funcione.
o pipeline de build de uma aplicação no Azure DevOps deve gerar um artefato para o pipeline de release. Para isso, em aplicações .NET Core, existe uma task para gerar o artefato:
- task: PublishBuildArtifacts@1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'your-artifact-name'
A partir do C# 7.0 foram criados os discards, que são variáveis temporárias que não são usadas em seu código. Elas não possuem valor, e não possuem memória alocada e nem espaço de armazenamento. Para indicar um discard basta usar um "_" como o nome da variável.
Alguns exemplos:
var pessoa = new Pessoa("Carlos", "Henrique", "São Paulo", "SP", "Brasil");
var (primeiroNome, _, cidade, _, _) = pessoa;
Console.WriteLine($"Olá {primeiroNome} de {cidade}!");
objeto switch
{
Tipo1 _ => _servicoTipo1,
Tipo2 _ => _servicoTipo2,
Tipo3 _ => _servicoTipo3,
_ => throw new InvalidOperationException(
$"Tipo inválido")
};
Nos pipelines de build do Azure DevOps, quando seu projeto utiliza pacotes NuGet de um feed externo, você pode usar uma task específica para realizar o restore:
- task: NuGetCommand@2
inputs:
command: 'restore'
restoreSolution: '**/*.sln'
feedsToUse: 'select'
vstsFeed: 'chave-do-feed'
Em um projeto web em .NET Core é possível adicionar um endpoint para Health Checks padrão. Para isso, basta adicionar o seguinte código na sua classe Startup, no método ConfigureServices:
public void ConfigureServices(IServiceCollection services)
{
services.AddHealthChecks();
}
E no método Configure:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseHealthChecks("/health");
}
Após isso, você pode implementar testes de API apontando para o endpoint criado.
Em repositórios do GitHub que tiverem boards sendo gerenciados no Azure DevOps é possível colocar o badge do Azure Boards para sinalizar o status do seu backlog.
Para colocar o badge siga os passos: - clique no board do seu projeto - clique na opção da engrenagem - na seção boards, clique no menu status badge - copie o valor informado - cole no seu README.md
Um detalhe importante, é que seu projeto no Azure DevOps deve estar público para que o badge funcione.