Refatoração

Visão Geral

Melhore a estrutura e a legibilidade do código sem alterar o comportamento externo. Refatoração é uma evolução gradual, não uma revolução. Use isso para melhorar código existente, não para reescrever do zero.

Quando Usar

Use esta habilidade quando:

• O código é difícil de entender ou manter
• Funções/classes são muito grandes
• "Code smells" precisam ser corrigidos
• Adicionar funcionalidades é difícil devido à estrutura do código
• O usuário pede "limpe este código", "refatore isto", "melhore isto"

Princípios de Refatoração

As Regras de Ouro

1. O comportamento é preservado - Refatoração não muda o que o código faz, apenas como
2. Pequenos passos - Faça mudanças minúsculas, teste após cada uma
3. Controle de versão é seu amigo - Commite antes e depois de cada estado seguro
4. Testes são essenciais - Sem testes, você não está refatorando, está editando
5. Uma coisa de cada vez - Não misture refatoração com mudanças de funcionalidade

Quando NÃO Refatorar

- Code that works and won't change again (if it ain't broke...)
- Critical production code without tests (add tests first)
- When you're under a tight deadline
- "Just because" - need a clear purpose

"Code Smells" Comuns e Correções

1. Método/Função Longa

# BAD: 200-line function that does everything
- async function processOrder(orderId) {
-   // 50 lines: fetch order
-   // 30 lines: validate order
-   // 40 lines: calculate pricing
-   // 30 lines: update inventory
-   // 20 lines: create shipment
-   // 30 lines: send notifications
- }

# GOOD: Broken into focused functions
+ async function processOrder(orderId) {
+   const order = await fetchOrder(orderId);
+   validateOrder(order);
+   const pricing = calculatePricing(order);
+   await updateInventory(order);
+   const shipment = await createShipment(order);
+   await sendNotifications(order, pricing, shipment);
+   return { order, pricing, shipment };
+ }

2. Código Duplicado

# BAD: Same logic in multiple places
- function calculateUserDiscount(user) {
-   if (user.membership === 'gold') return user.total * 0.2;
-   if (user.membership === 'silver') return user.total * 0.1;
-   return 0;
- }
-
- function calculateOrderDiscount(order) {
-   if (order.user.membership === 'gold') return order.total * 0.2;
-   if (order.user.membership === 'silver') return order.total * 0.1;
-   return 0;
- }

# GOOD: Extract common logic
+ function getMembershipDiscountRate(membership) {
+   const rates = { gold: 0.2, silver: 0.1 };
+   return rates[membership] || 0;
+ }
+
+ function calculateUserDiscount(user) {
+   return user.total * getMembershipDiscountRate(user.membership);
+ }
+
+ function calculateOrderDiscount(order) {
+   return order.total * getMembershipDiscountRate(order.user.membership);
+ }

3. Classe/Módulo Grande

# BAD: God object that knows too much
- class UserManager {
-   createUser() { /* ... */ }
-   updateUser() { /* ... */ }
-   deleteUser() { /* ... */ }
-   sendEmail() { /* ... */ }
-   generateReport() { /* ... */ }
-   handlePayment() { /* ... */ }
-   validateAddress() { /* ... */ }
-   // 50 more methods...
- }

# GOOD: Single responsibility per class
+ class UserService {
+   create(data) { /* ... */ }
+   update(id, data) { /* ... */ }
+   delete(id) { /* ... */ }
+ }
+
+ class EmailService {
+   send(to, subject, body) { /* ... */ }
+ }
+
+ class ReportService {
+   generate(type, params) { /* ... */ }
+ }
+
+ class PaymentService {
+   process(amount, method) { /* ... */ }
+ }

4. Lista de Parâmetros Longa

# BAD: Too many parameters
- function createUser(email, password, name, age, address, city, country, phone) {
-   /* ... */
- }

# GOOD: Group related parameters
+ interface UserData {
+   email: string;
+   password: string;
+   name: string;
+   age?: number;
+   address?: Address;
+   phone?: string;
+ }
+
+ function createUser(data: UserData) {
+   /* ... */
+ }

# EVEN BETTER: Use builder pattern for complex construction
+ const user = UserBuilder
+   .email('test@example.com')
+   .password('secure123')
+   .name('Test User')
+   .address(address)
+   .build();

5. Inveja de Funcionalidade (Feature Envy)

# RUIM: Método que usa mais dados de outro objeto do que os seus próprios
- class Pedido {
-   calcularDesconto(usuario) {
-     if (usuario.nivelAssinatura === 'ouro') {
+       return this.total * 0.2;
+     }
+     if (usuario.idadeConta > 365) {
+       return this.total * 0.1;
+     }
+     return 0;
+   }
+ }

# BOM: Mova a lógica para o objeto que possui os dados

…