De Freddy Krueger à Brad Pitt. Como melhorar o seu código e fazê-lo ficar lindo
De Fred Krueger a Brad Pitt como melhorar o seu código e fazê-lo ficar lindo
Jan 10, 2017
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
De Freddy Krueger à Brad Pitt. Como melhorar o seu código e fazê-lo ficar lindo
Analista de Desenvolvimento & ex-Infra (fora do SERPRO) & @rubyonrio & curiosa & hiperativa & tentando dominar o mundo
Quem sou eu?
O que vamos ver?
• SOLID (Boas práticas)
• Código Limpo
O que vamos ver?
• SOLID (Boas práticas)
• Código Limpo
Tá mas porque isso é importante?
● Mais fácil para compreender
● Mais fácil de encontrar e resolver bugs
Ou seja, melhora (e muito) a MANTENABILIDADE do código
O que contribui para um código feio?
Eu quero é terminar rápido!!!
Pra que fazer direito? Tô de saco cheio desse projeto já!
Tenho que começar a fazer agora!!!
Depois refatoro!
Todo mundo faz assim!!!
O que contribui para um código feio?
Eu quero é terminar rápido!!!
Pra que fazer direito? Tô de saco cheio desse projeto já!
Tenho que começar a fazer agora!!!
Depois refatoro!
Todo mundo faz assim!!!
Porque o código continua feio?
● Desenvolvedores saem do projeto● Novos desenvolvedores entram no projeto e
tem medo de modificar algo● Mito de que demora muito mais tempo
O poder de mudar isso é nosso!
Respire fundo e....
Sobre o uso de comentários:
Não use!
Sobre o uso de comentários:
Não use!
Calma calma calma! Não criemos pânico!!!
O código deve ser o máximo possível auto-explicativo
Comentários podem e devem ser usados, mas principalmente nas seguintes condições:
● Se não dá pra fazer nada melhor.● Para alertar sobre algo importante sobre
aquele trecho de código.● TODO / FIXME
SOLID
ingle Responsibilitypen-Closediskov Substitutionnterface Segregationependency Inversion
Single Responsibility
Cada classe ou método deve ter apenas uma responsabilidade, ou seja, mudar por apenas um motivo
Single Responsibility
Cada classe ou método deve ter apenas uma responsabilidade, ou seja, mudar por apenas um motivo
Objetivo:
● Classes ou métodos pequenas e coesas
Single Responsibility
Single Responsibility
Open-Closed
As classes devem ser abertas para extensão, mas fechadas para modificação.
Open-Closed
As classes devem ser abertas para extensão, mas fechadas para modificação.
Objetivos:
● Evolução do código mais fácil e rápida● Melhorar a testabilidade
Open-Closed
Open-Closed
Liskov Substitution
Uma classe pode ser substituída por uma classe derivada dela sem a alteração de funcionamento de um método.
Liskov Substitution
Uma classe pode ser substituída por uma classe derivada dela sem a alteração de funcionamento de um método.
Objetivos:
● Reaproveitamento de código mais eficiente● Melhorar a testabilidade
Liskov Substitution
Liskov Substitution
Interface Segregation
O cliente de uma classe não deve ser obrigado a herdar métodos que ele não utiliza.
Interface Segregation
O cliente de uma classe não deve ser obrigado a herdar métodos que ele não utiliza.
Objetivo:
● Interfaces menores, mais coesas e mais estáveis
Interface Segregation
Interface Segregation
Dependency Inversion
Módulos de alto nível não devem depender de módulos de baixo nível e sim de abstrações e estas não devem depender de detalhes e sim os detalhes dependerem delas.
Dependency Inversion
Módulos de alto nível não devem depender de módulos de baixo nível e sim de abstrações e estas não devem depender de detalhes e sim os detalhes dependerem delas.
Objetivos:
● Diminuir a coesão entre os diferentes módulos
● Aumentar o reuso de classes
Dependency Inversion
Dependency Inversion
Related Documents
