Categoria
A complexidade ciclomática, formalmente definida por Thomas McCabe em 1976, é uma métrica que quantifica o número de caminhos linearmente independentes em um código-fonte. Ela é calculada como: M = E - N + 2P, onde E é o número de arestas, N o número de nós no grafo de fluxo de controle e P o número de componentes conectados.
Padrões de projeto são soluções reutilizáveis para problemas recorrentes no desenvolvimento de software. Popularizados pelo livro "Design Patterns: Elements of Reusable Object-Oriented Software" (GoF) em 1994, os padrões surgiram da necessidade de catalogar boas práticas que arquitetos e desenvolvedores já utilizavam empiricamente.
Muitos times acreditam que documentação técnica ideal é aquela que cobre cada detalhe do sistema. Na prática, documentação "completa" vira rapidamente um peso morto. Cada funcionalidade nova exige atualização em múltiplos lugares, e o custo de manutenção supera o valor gerado. O resultado? Documentos enormes, desatualizados e que ninguém lê.
Documentação de código é todo material textual que acompanha um sistema de software para explicar seu funcionamento, propósito e uso. Ela vai muito além de simples comentários // ou # espalhados pelo código. Inclui desde comentários inline (explicações pontuais em linhas específicas) até artefatos mais elaborados como wikis internos, manuais do desenvolvedor, guias de API e diagramas de arquitetura.
O padrão Repository existe para isolar a lógica de acesso a dados do restante da aplicação, permitindo que o domínio permaneça puro e testável. O problema é que muitos desenvolvedores transformam essa intenção nobre em uma camada de abstração genérica que não agrega valor real.
A Programação Orientada a Objetos (POO) é um paradigma de desenvolvimento que organiza o código em torno de "objetos" — entidades que combinam dados (atributos) e comportamentos (métodos). Diferentemente da programação procedural, que se baseia em funções e sequências de instruções, a POO busca modelar sistemas computacionais de forma mais próxima ao mundo real.
APIs internas são a espinha dorsal da comunicação entre serviços em qualquer organização de médio a grande porte. Diferentemente de APIs públicas, onde a documentação frequentemente se limita a contratos e exemplos de uso, APIs internas exigem um nível adicional de profundidade: o registro explícito das decisões de design e dos trade-offs envolvidos.
Um histórico de commits bem organizado é a espinha dorsal de qualquer projeto de software de longo prazo. Imagine tentar entender as mudanças em um sistema complexo apenas por mensagens como "correções" ou "atualizações" — isso rapidamente se torna um pesadelo.
O Model-Based Testing (MBT) é uma abordagem de teste de software onde casos de teste são gerados automaticamente a partir de modelos formais que descrevem o comportamento esperado do sistema. Diferente dos testes tradicionais — onde o testador manualmente escreve scripts baseados em requisitos — no MBT o foco está na criação e manutenção de um modelo comportamental.
Refatoração é o processo de modificar o código-fonte de um sistema sem alterar seu comportamento externo observável. A definição formal, cunhrada por Martin Fowler em seu livro clássico, estabelece que refatorar significa aplicar pequenas transformações que preservam a semântica, melhorando a estrutura interna.