• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Qualidade de Código
 

Qualidade de Código

on

  • 143 views

Apresentação para a equipe .NET na empresa Dual.

Apresentação para a equipe .NET na empresa Dual.

Statistics

Views

Total Views
143
Views on SlideShare
143
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Qualidade de Código Qualidade de Código Presentation Transcript

    • QUALIDADE DE CÓDIGO
    • Test Driven Development  Por que é importante?  Código de produção testável  Refatoração sem medo  Código melhor estruturado  O que não testar?  Cadastros  Leitura/Gravação de arquivos  Independência  Banco de dados  Arquivos do sistema  Arquivos de configuração
    • Mocks  Então como testar?  Mocks  Exemplo DataAccess  Testar a conversão dos Feriados do SIAP em DateTime  Biblioteca Moq.  Testes Unitários  Deve testar um único método. Todas as outras dependências que esse método usa devem ser mockadas.  Evitar métodos estáticos  Não é possível mocká-los  DateTime.Now  Exemplo Business & DateTime.Now  Mostrar código do SIGEP (ApontamentoServicoDeve)
    • Exemplo: classe não testável  Classe não testável:
    • Refatoração  O código de produção deve ser escrito o mais simples possível para passar  Depois de escrever vários testes e códigos de produção, pode-se perceber que há códigos duplicados ou que poderiam ser melhores escritos  Então chegou a hora de refatorá-los
    • Refatorando ConsultaArquivo  Temos que testar a regra de obter o texto SQL sem depender de um arquivo do sistema, como?  Dependency Inversion 1º • Vamos fazer a classe ConsultaArquivo não depender mais dos métodos estáticos da classe File 2º • ConsultaArquivo exigirá no construtor uma interface IFileHelper 3º • IFileHelper conterá 2 métodos: Existe(...) e LeTodoTexto(...) 4º • Mockamos o IFileHelper para testar o método ObterConsultaPorNome(...)
    • ConsultaArquivo Refatorada
    • Testes de Integração  Poderíamos testar o FileHelper, mas seria um teste de Integração e não um teste de unidade.  Seria um teste de Integração com o sistema de arquivos do windows  Testes de Integração se caracterizam por necessitarem de um ambiente preparado para o teste funcionar  Acesso a arquivos  Acesso ao banco de dados  Acesso a WebServices  Testar unidades em conjunto (integradas)
    • Nomenclatura  Nome classe de teste:  NomeClasseTestadaDeve  NomeClasseTestadaNomeMetodoDeve  Nome dos métodos do teste:  Deve ser uma ação que a classe testada deve fazer  Exemplos:  PedidoBusinessDeve  Quebrar_Pedidos_Por_Representante_Quando_Parametro_Estiver_ Setado  Retornar_Apenas_Pedidos_Faturados_Da_Conta_X  Totalizar_Itens_Pedidos_Corretamente  Lancar_Excecao_Quando_Pedido_Estiver_Bloqueado  Por quê?  Facilita o entendimento sobre o que está sendo testado  Facilita para o desenvolvedor escrever o teste
    • Nomenclatura - AAA  Arrange  Organiza os objetos antes de executar o teste  Act  Executa o método que está testando  Assert  Verifica as condições para que o teste passe  Por quê?  Testes mais organizados  Testes mais limpos  Bater o olho e saber o que e como certa funcionalidade está sendo testada
    • SUGESTÕES DE MELHORIA Opiniões e Debates
    • Muitas dependências  Classe recebe vários parametros no construtor  Talvez essa classe deva ser quebrada em mais classes  Agrupar os parametros em outra classe e fazer o construtor receber essa nova classe.
    • Business  Acho que não devíamos ficar presos as Business.  Regra de negócio deve ser na Business, ok.  Mas também poderíamos criar outras classes que a Business usa.  Exemplo: validação do Pedido é complexa  Talvez criar uma classe ValidadorPedido(Pedido)  Passar tudo o que é preciso para validar o Pedido  Na Business de Pedido chamar essa classe.  Atualmente os métodos das Business possuem muito código e as regras estão obscuras
    • Business  Acho que poderíamos ter mais Business ao invés de apenas Business relativas ao Model.  Exemplo CRM: CampanhaBusinessComplement  Possui método CriarAgendamentos  Poderia ser criado uma Business relativa a Agendamentos, pois a criação de Agendamentos é complexa e poderia ser isolada.
    • Parametros out  ReadComplete  Por que não retornar apenas uma classe e nessa classe colocar todos os parametros out?  CreateComplete  Por que não receber essa mesma classe que foi criada no item anterior ao inves de vários parametros out?  Acho que não devíamos ficar presos aos Models.  Mais classes poderiam ser criadas para que as responsabilidades sejam divididas.
    • Factories  São classes que funcionam como uma fábrica de objetos.  Às vezes para instanciar uma classe, é requerido vários parametros ou algumas regras especificas.  Essas regras poderiam estar encapsuladas em uma Factory  Exemplo CRM:
    • AtividadeFactory  Poderia ser criado uma classe Factory que recebesse os objetos destacados e retornasse uma instancia de AtividadeInfo.
    • Dependência de Web Services  Acho que não devíamos usar o Schema gerado pelo wsdl  Se o schema mudar, toda a aplicação terá que ser alterada  Solução  Criar nossas próprias classes  Criar camada intermediária entre nossas classes e o schema  Converter nossas classes para o schema  Converter o schema para nossa classe  Se schema mudar, precisamos mexer apenas nessa camada de conversão  Exemplo ruim: DualNFe usa os schemas  Exemplo bom: PortalTiss usa classes próprias
    • Referências  Software Practices, Pluralsight  Principles of Object Oriented Design  Design Patterns  Clean Code A Handbook of Agile Software Craftsmanship, Robert C. Martin  DDD Quickly, Abel Avram & Floyd Marinescu  Resumo de DDD por Eric Evans