Como desenvolver softwares

sustentáveis com C# e .NET

Core
Mayke Rezende
- Carioca
- Software Engineer na Acesso Soluções
de Pagamento
- Pós graduando em Arquitetura de
Software
- Microsoft Certified Professional em
Programming in C#
- Um dos coordenadores da comunidade
DevelopersBR
- Péssimo em design

linkedin.com/in/mayke-medeiros-rezende
medium.com/@maykemrezende
 ● Introdução

Agenda ● Motivação

● Como proceder

● Como aplicar com C# e .NET

Core
○ SOLID
○ DRY
○ Clean Code
Quem nunca se sentiu assim?
Como esse troço funciona?
Por que softwares envelhecem mal?

● Código duplicado
● Muita interdependência e acoplagem entre
componentes do software
● Classes/métodos com responsabilidades
demais
● Alteração em um ponto impacta no sistema
inteiro
● Patternite aguda
● Muitos code smells
Code smells

● Cheirinho de “shit is gonna happen”

● Ou seja, é uma parte do código que tem um
grande potencial de causar estrago no sistema
● É agnóstico à linguagem
● Sintoma de um péssimo design de software
● Sintoma claro de software legado
● Sintoma de débito técnico
Problemas causados por Code smells
● Aumento de custos na manutenção
● Rigidez do software
● Complexidade desnecessária
● Configuração do software espalhada pelo código

O tempo salvo fazendo um código/design de software ruim será

cobrado no tempo de manutenção.
Como lidar com Code smells
● Refatoração de código
● Priorizar qualidade
● Entender o problema antes de pensar na solução
● Começar o desenvolvimento de forma correta
● Adotar uso de Code Review
● Utilizar ferramentas como Sonarqube e Sonarlint
Fonte: https://bit.ly/2J7N1Jn
Motivação
● Quem der manutenção no seu código pode ser o
Hannibal com seu endereço completo.
● Parábola da “Vaca na árvore”
● Desmotivação profissional e insatisfação do
cliente
● Queda de produtividade
● Código legado
● Não criar um novo Tiamat
● Faça da forma mais rápida, não da forma mais
correta
Tiamat,
mais conhecido
como software legado
Como proceder?
● Pense na arquitetura
○ Dividir para conquistar
○ Visão geral do software
○ Conhecimento prévio de possíveis
problemas
● Cuidado com a complexidade desnecessária
● Não exagere em Design Patterns
○ Patternite aguda
● Observe o contexto da sua aplicação
● Atenção e prioridade a Code Smells
Como aplicar
com C# e .NET Core
SOLID
Cinco regras criadas no início dos anos
2000 por Robert Cecil Martin, ou Uncle
Bob, no artigo “Design Principles and
Design Patterns”

Se tornou acrônimo SOLID por Michael

Feathers, anos depois
 SRP - Single responsibility principle
Princípio da Responsabilidade Única - Uma classe deve ter um, e
somente um, motivo para mudar.
OCP - Open/closed principle
Princípio do Aberto/Fechado - Você deve ser capaz de estender um
comportamento de uma classe sem a necessidade de modificá-lo.
LSP - Liskov substitution principle
Princípio da substituição de Liskov - As classes derivadas devem ser
substituíveis por suas classes bases.
SOLID

ISP - Interface segregation principle

Princípio da segregação de interfaces - Muitas interfaces específicas
são melhores do que uma interface única geral.
DIP - Dependency inversion principle
Princípio da inversão de dependência - Dependa de abstrações e não
de implementações.
Don’t Repeat Yourself - DRY

● Princípio criado por Andrew “Andy” Hunt e Dave

Thomas no livro “The Pragmatic Programmer”,
em 1999
● Escrever é perda de tempo
● Cada parte do sistema deve possuir uma única,
não ambígua, representação
● Depende do Princípio da Responsabilidade Única
Ex:
Ex:
O que é Clean Code?
● Filosofia apresentada por Robert Martin em seu
livro de mesmo nome.
● Código eficiente, elegante e legível
● “Um código bem-feito é como um texto bem
escrito, claro, direto, com mensagem efetiva” -
Grady Booch
● Lógica o mais simples possível
Como praticar Clean Code
em C# e .NET Core
● Nomes significativos, objetivos e buscáveis
● Poucas linhas de código em um método
○ Princípio da Responsabilidade Única
● Poucos parâmetros por método
○ Struct
○ Data Transfer Object - DTO
● Utilize Extension Methods
● Parametrize a aplicação
○ Não espalhe configuração pelo código!
○ Appsettings.json existe e merece ser usado!
Como praticar Clean Code em
C# e .NET Core
● Não comente o código
○ Se o código precisa de comentário, ele não está bem escrito;
● Não abstraia a abstração!
● Não reinvente a roda
○ Alguém com mais capacidade já criou uma solução para o
seu problema;
● Escreva testes de unidade
○ XUnit, NUnit, Bogus…
● Se o código não será utilizado agora, não codifique!
● Reutilize código na medida do possível.
Como praticar Clean Code
em C# e .NET Core
● Cuidado com números mágicos
● Utilize Design Patterns
○ Não abuse!
Nomes
significativos
Nomes
buscáveis
Dúvidas?
Críticas?
Comentários?
Bora fazer uma promessa pro
coleguinha de trabalho?

#Partiu