"O código perfeito não nasce do acaso, mas de um plano bem estruturado"
Durante meus estudos, algumas imersões, descobri que a maior revolução no desenvolvimento não está nas linhas de código, mas no planejamento estratégico que as antecede. Neste artigo, vou detalhar como organizar ideias, definir problemas e desenhar arquiteturas antes de codificar transformou um projeto simples (um sistema de cadastro de eventos) em uma experiência de aprendizado estruturada e eficiente.

Índice

  1. Antes do Código: A Arte de Definir o Problema
  2. Organizando ideias: Do caos à Clareza
  3. Desenhando a Arquitetura: O Blueprint do Projeto
  4. Codificando com Propósito: Do Diagrama à Prática
  5. Lições Aprendidas (e Como Você Pode Aplicar)
  6. Conclusão: Por que Planejar Vale a Pena?
  7. Bônus: Checklist Pré-Codificação

1. Antes do Código: A Arte de Definir o Problema

Muitos desenvolvedores que estão iniciando na carreira pulam esta etapa, mas é aqui que a mágica começa.

Escreva o problema claramente:

Exemplo: "Preciso de um sistema para cadastrar eventos, com datas, locais e participantes, garantindo que os dados sejam persistidos e acessíveis via API."
Isso evita escopo aberto e direciona as decisões técnicas.

Liste requisitos funcionais e não funcionais:

  • Funcionais: Cadastro de eventos, integração com banco de dados, endpoints REST.
  • Não funcionais: Performance (resposta em < 2s), segurança (autenticação futura), escalabilidade.

Valide com stakeholders:

Mesmo em projetos pessoais, simule perguntas como: "O que é essencial para a versão 1.0?"

2. Organizando Ideias: Do Caos à Clareza

Antes de abrir o IDE, organize suas ideias em camadas.

Separe responsabilidades:

  • Frontend: Interface do usuário.
  • Backend: Lógica de negócio, APIs.
  • Banco de Dados: Modelagem de tabelas.

Use ferramentas visuais (Draw.io/FigJam):

No projeto, desenhamos um diagrama com:

Image description

Isso ajudou a visualizar o fluxo de dados e como estruturar minhas pastas antes mesmo de codificar.

3. Desenhando a Arquitetura: O Blueprint do Projeto

Aqui entra o Spring Boot, mas com propósito!

Spring Boot vs Spring Framework:

  • Spring Boot: Foco em configuração automática (embedded Tomcat, starters),
  • Spring Framework: Controle manual de dependências (ideal para projetos complexos).

Camadas da aplicação (em detalhes):

1.Controller:

  • Responsável por receber requisições HTTP.
  • Anotações: @RestController, @RequestMapping

2.Service:

  • Lógica de negócio (validações, regras).
  • Anotação: @Service.

3.Repository:

  • Comunicação com o banco (JPA/Hibernate).
  • Anotação: @Repository

4.Model:

  • Entidades do banco (ex: Evento com id, nome, data).

MySQL + JPA:

  • Configuração simplificada via application.properties.
  • User @Querypara consultas personalizadas.

4. Codificando com Propósito: Do Diagrama à Prática

Com o plano pronto, codificar virou execução, não adivinhação.

Exemplo de fluxo:

// Model
@Table(name = "tbl_event")
@Entity
public class Event {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "event_id")
    private Integer eventId;

    @Column(name = "title", length = 255, nullable = false)
    private String title;
    @Column(name = "pretty_name", length = 50, nullable = false, unique = true)
    private String prettyName;
    @Column(name = "location", length = 255, nullable = false)
    private String location;

    @Column(name = "price", nullable = false)
    private Double price;

    @Column(name = "start_date")
    private LocalDate startDate;
    @Column(name = "end_date")
    private LocalDate endDate;

    @Column(name = "start_time")
    private LocalTime startTime;
    @Column(name = "end_time")
    private LocalTime endTime;
// Repository
public interface EventRepository extends CrudRepository {

    public Event findByPrettyName(String prettyName);
}
// Service
@Service
public class EventService {

    @Autowired
    private EventRepository eventRepository;

    public Event addNewEvent(Event event) {
        event.setPrettyName(event.getTitle().toLowerCase().replaceAll(" ", "-"));
        return eventRepository.save(event);
    }

    public List getAllEvents() {
        return (List) eventRepository.findAll();
    }

    public Event getEventByPrettyName(String prettyName) {
        return eventRepository.findByPrettyName(prettyName);
    }
}
// Controller
@RestController
public class EventController {

    @Autowired
    private EventService eventService;

    @PostMapping("/events")
    public Event addNewEvent(@RequestBody Event newEvent) {
        return eventService.addNewEvent(newEvent);
    }

    @GetMapping("/events")
    public List getAllEvents() {
        return eventService.getAllEvents();
    }

    @GetMapping("/events/{prettyName}")
    public ResponseEntity getEventByPrettyName(@PathVariable String prettyName) {
        Event event = eventService.getEventByPrettyName(prettyName);
        if (event != null) {
            return ResponseEntity.ok().body(event);
        }
        return ResponseEntity.notFound().build();
    }
}

5. Lições Aprendidas (e Como Você Pode Aplicar)

  • Documente decisões técnicas:
    Crie um README.md com porquês (ex: "Escolhemos Spring Boot para agilizar a configuração").

  • Refatore sem medo:
    O planejamento reduziu retrabalho, mas ajustes são normais. Ex: otimizamos queries após analisar logs.

  • Ferramentas que salvam:

  • Draw.io para diagramas
  • Postman para testar APIs durante o desenvolvimento

6. Conclusão: Por que Planejar Vale a Pena?

Planejar a arquitetura e organizar ideias não é "perda de tempo" – é ganho de eficiência. No projeto, evitamos:

  • Classes "Deus" (com responsabilidades demais).
  • Acoplamento excessivo entre camadas.
  • Surpresas na integração com o banco.

E você? Já usou alguma técnica de planejamento que mudou sua forma de codar? Compartilhe nos comentários! 👇

7. Bônus: Checklist Pré-Codificação

  1. Defina o problema por escrito.
  2. Liste requisitos funcionais e não funcionais.
  3. Desenhe a arquitetura (fluxo de dados e camadas).
  4. Escolha tecnologias com base no escopo.
  5. Documente decisões técnicas.