Apresentação WTM

37
De Freddy Krueger à Brad Pitt. Como melhorar o seu código e fazê-lo ficar lindo

Transcript of Apresentação WTM

De Freddy Krueger à Brad Pitt. Como melhorar o seu código e fazê-lo ficar lindo

Analista de Desenvolvimento no SERPRO & ex-Analista de Infra & @rubyonrio &

@hackinrio & WTM & 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....

E os comentários????

Não use!

Palma palma palma! Não priemos câ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

Ou seja...

Ou seja...

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 e fracamente acopladas

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

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

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

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 o acoplamento entre os diferentes módulos

● Aumentar o reuso de classes

Dependency Inversion

Vamos lembrar sempreIsso são apenas boas práticas, não resolvem todos os problemas...