Deep Modules: o Claude Code Skill que salva minha codebase

Deep Modules: o Claude Code Skill que salva minha codebase

Executei a skille improve-codebase-architecture em um projeto para o qual estou enviando desde novembro. O Soneto 4.6 passou onze minutos lendo meu código, abriu um relatório de redução em meu editor e listou seis coisas que achava que estavam apodrecendo silenciosamente debaixo de mim.

O primeiro eu descartei. O segundo com quem argumentei. O terceiro me fez estremecer, ir até a cozinha, servir um café que não queria e voltar para lê-lo novamente.

Ele encontrou duas implementações paralelas do mesmo conceito - uma em meu front-end e outra em meu back-end - em pastas totalmente diferentes, pertencentes a modelos mentais totalmente diferentes, sem nenhuma junção unificada entre eles. Eles estavam à deriva. Eu havia enviado um bug três semanas antes, cuja causa raiz era exatamente esse desvio. Eu não havia conectado os dois eventos. A skille os conectou em um parágrafo.

Esse foi o momento em que parei de tratar essa skille como outro repositório GitHub e comecei a tratá-la como a única coisa entre mim e a base de código que estou buscando se continuar enviando na velocidade AI sem pressão arquitetônica.

Se você tem codificado no Claude Code até o primeiro trimestre de 2026 e sua base de código está começando a parecer mais pesada do que deveria - lenta para navegar, assustadora para refatorar, cheia de pequenos módulos que parecem depender uns dos outros de maneiras que você não consegue desenhar em um quadro branco - esta postagem é para você. As próximas 4.000 palavras são sobre por que isso está acontecendo, o que John Ousterhout descobriu há vinte anos que torna isso corrigível e como a skille improve-codebase-architecture de Matt Pocock operacionaliza a correção dentro do Claude Code.

O custo real de shippar rápido com AI

Aqui está o que ninguém coloca nas páginas de marketing de codificação AI.

A razão pela qual Claude Code parece mágico na segunda semana e pesado no quarto mês não é que o modelo piore. É que sua base de código fica pior, mais rápido do que seu cérebro consegue modelá-la. O software sempre teve essa propriedade — Ousterhout construiu um livro inteiro em torno disso, A Philosophy of Software Design, ao qual voltarei em um segundo. Mas a taxa mudou. AI não escreve código melhor ou pior, em média, do que eu. Ele escreve código de cinco a dez vezes mais rápido que eu. Cada atalho arquitetônico que pego leva quinze minutos em vez de dois dias, o que significa que a entropia se compõe em um calendário no qual meu julgamento nunca foi treinado.

O nome técnico para o que está acontecendo é entropia de software. O nome em forma de código é “bola de lama”. A sensação, se você já viveu isso, é o momento em que você abre um arquivo e percebe que não sabe mais quem chama essa função, o que ela retorna quando a entrada está malformada, ou se alterá-la irá quebrar o conjunto de testes ou a produção, ou ambos.

Tive essa sensação no projeto que mencionei acima. Não porque o código fosse ruim – a maior parte foi revisada, a maior parte teve testes, a maior parte foi executada em produção para usuários pagantes. O problema era mais refinado do que "código incorreto". O problema era que eu tinha trinta módulos e precisava de doze. Conceitos que pertenciam um ao outro foram divididos em arquivos porque, no momento em que escrevi cada peça, a divisão parecia mais limpa. O custo cognitivo total dessas divisões era agora superior ao custo cognitivo da duplicação que evitavam.

É isso que o AI acelera. A decisão de dividir, extrair e abstrair é barata quando um agente pode fazer isso em vinte segundos. A decisão é tão barata que tomo sem pensar. O resultado é uma base de código em forma de fractal de módulos pequenos, educados e individualmente corretos, sem centro.

Ousterhout tem uma palavra para essa forma. Ele chama isso de superficial. A correção também tem um nome: deep modules. A skille que estou prestes a mostrar é a primeira ferramenta que usei que operacionaliza a correção sem exigir que eu releia trezentas páginas de um livro de design de software todas as sextas-feiras à tarde.

Deep Modules vs módulos rasos - em inglês simples

Antes de abordar a skille, você precisa do vocabulário. Depois de obtê-lo, o resultado da skille será semelhante ao inglês. Sem ele, o relatório parece uma lista de compras refatorada.

Um módulo é uma unidade do seu aplicativo com um limite claro. Em um aplicativo React, um módulo pode ser um componente. Em um serviço Node, pode ser uma função, uma classe ou uma pasta. O que o torna um módulo não é seu tamanho - é que há um exterior e um interior, e o interior está oculto.

A interface é o que alguém precisa aprender para usar o módulo externamente. Assinaturas de função. Adereços de componentes. Métodos públicos. Documentação. Definições de tipo. Qualquer coisa que um chamador precise carregar em sua cabeça para que o módulo faça seu trabalho.

A implementação é tudo dentro do limite que o chamador não precisa saber. Loops, auxiliares, máquinas de estado, consultas de banco de dados, novas tentativas — o trabalho real.

Agora a parte que importa.

Um módulo profundo possui uma interface pequena e uma implementação complexa. Você aprende dez coisas sobre isso e ele faz mil coisas por você. O índice de alavancagem – comportamento acessível por unidade de interface aprendida – é alto. O exemplo clássico de Ousterhout é a chamada do sistema de arquivos Unix read(fd, buf, n). Três argumentos. Décadas de complexidade do sistema operacional escondidas por trás disso. Você não pensa em geometria de disco, caches de páginas ou alocação de blocos. Você pede n bytes. Você obtém n bytes.

Um módulo superficial possui uma interface que é quase tão complexa quanto a implementação que ele oculta. Você aprende dez coisas sobre isso e ele faz onze coisas por você. Ou, na pior das hipóteses, você aprende dez coisas sobre isso e ele faz oito coisas para você, porque a interface vaza mais do que a implementação contém. O índice de alavancagem está próximo de um. O módulo mal paga o aluguel.

Aqui está um par concreto. Fique comigo – este é o momento em que o vocabulário chega.

// SHALLOW: this module's interface is bigger than what it hides
export class UserAuthHelper {
  hashPassword(password: string, salt: string): Promise<string>;
  generateSalt(): string;
  verifyPasswordAgainstHash(password: string, hash: string, salt: string): Promise<boolean>;
  isPasswordStrongEnough(password: string): boolean;
  getMinimumPasswordLength(): number;
  getMaximumPasswordLength(): number;
  generateSessionToken(userId: string): string;
  validateSessionToken(token: string): { userId: string } | null;
  revokeSessionToken(token: string): Promise<void>;
}

Você leu isso e já pode sentir. Para usar isso, preciso saber sobre sais, hashes, tokens de sessão, regras de senha e revogação, todos detalhes de implementação de ser autenticado. A interface está vazando o interior do módulo para o cérebro de cada chamador.

Agora, a versão profunda da mesma coisa.

// DEEP: small interface, the complexity is locked inside
export class Auth {
  signIn(email: string, password: string): Promise<Session>;
  signOut(session: Session): Promise<void>;
  currentUser(session: Session): Promise<User | null>;
}

Três métodos. Salts, hashes, geração de sessão, regras de senha, revogação, expiração, tokens de atualização – tudo isso reside dentro de signIn, signOut e currentUser. O chamador não precisa saber de nada disso. Se eu quiser migrar do bcrypt para o argon2 no próximo mês, nenhum chamador será alterado. Se eu quiser adicionar autenticação multifator, a interface permanecerá a mesma - signIn fica mais rico por trás da costura.

Esse é o movimento que a skille está procurando. Cada oportunidade de aprofundamento é, na sua essência, uma oportunidade para assumir a segunda forma e encobrir a primeira.

Há mais um vocabulário de que você precisa antes de prosseguirmos.

Localidade é como a funcionalidade relacionada é agrupada na base de código. Alta localidade significa que as coisas que mudam juntas vivem próximas umas das outras. Baixa localidade significa que a alteração de um recurso requer a edição de arquivos em três pastas que nem sequer se conhecem. O UserAuthHelper raso acima tem localidade média – pelo menos é uma classe. O bug que encontrei em meu projeto tinha localidade baixa — a lógica em formato de autenticação foi duplicada em apps/web/src/lib/session.ts e services/api/src/auth/session.go, sem tipos compartilhados e sem contrato obrigatório entre eles.

O aprofundamento geralmente melhora a localidade automaticamente. Quando você recolhe três shallow modules em um módulo profundo, o código relacionado passa para o mesmo arquivo, o que significa que a próxima pessoa que o editar (provavelmente no futuro, às 23h, daqui a dois meses) poderá ver tudo de uma vez.

O que a skille realmente faz

A skille improve-codebase-architecture, escrita por Matt Pocock e enviada como parte de seu [repositório de skilles] de código aberto (https://github.com/mattpocock/skills), é um pequeno pacote de descontos que remodela a forma como Claude Code lê seu repositório. Você o instala como qualquer outra skille - coloque-o em ~/.claude/skills/ ou use o comando de instalação do README - e a partir de então, quando você pede ao Claude Code para procurar oportunidades de refatoração, ele faz isso através das lentes de Ousterhout em vez de heurísticas genéricas de "cheiro de código".

Mecanicamente, a skille faz três coisas.

Primeiro, ele verifica o repositório com uma pergunta específica em mente: onde os shallow modules estão agrupados? Não está procurando arquivos ruins individuais. Ele procura clusters de pequenos módulos fortemente acoplados, onde cada um tenha uma interface quase tão complexa quanto sua implementação e onde você possa sentir o atrito de se mover entre eles ao ler o código.

Em segundo lugar, ele produz uma lista de oportunidades de aprofundamento — geralmente entre três e dez, na minha experiência — cada uma escrita como uma proposta curta: quais módulos mesclar, como deveria ser a nova interface, onde ficaria a costura de teste e quais riscos o refatorador acarreta. A proposta deve ser lida por um ser humano, discutida e aceita, modificada ou rejeitada.

Terceiro, quando você aceita uma proposta, a skille entra em uma etapa de design interativo. Claude propõe a nova interface, você rejeita nomes e formas, o modelo é revisado e, uma vez estabelecida a interface, ele propõe uma estratégia de implementação. A estratégia inclui como migrar chamadores e onde colocar o limite de teste. Quando você dá luz verde, a skille registra um problema GitHub (ou qualquer rastreador de problemas que você conectou) para que o trabalho seja rastreado mesmo que você não o faça naquele dia.

As duas coisas que quero sublinhar. A skille não refatora seu código por si só. Ele revela oportunidades e ajuda você a pensar. Os humanos fazem todas as chamadas arquitetônicas. E a skille é opinativa – ela prefere especificamente menos módulos mais profundos em vez de mais módulos menores. Se a sua equipe tiver uma forte preferência cultural na outra direção, você lutará contra isso.

O dia em que executei em meu próprio repositório

O repositório que testei era um painel SaaS que envio semanalmente desde novembro. Cerca de 1.500 commits, principalmente meus, ocasionalmente programados em pares com Claude Code. TypeScript em toda a stack, React Router no frontend, um serviço Node na parte traseira, um banco de dados Postgres embaixo. Usuários reais. Erros reais. Custo cognitivo real cada vez que o abro.

Limpei uma manhã de domingo, fiz café e executei um prompt:

Use a skille improve-codebase-architecture. Digitalize este repositório e produza uma lista de oportunidades de aprofundamento, ordenadas por impacto.

Onze minutos. Seis oportunidades.

Vou percorrer três deles, porque os outros três eram variações dos mesmos padrões e você obterá o formato deles.

Oportunidade 1: O conceito de sessão duplicada. Essa foi a que me fez largar o café. A skille sinalizou que apps/web/src/lib/session.ts e services/api/src/middleware/session.go estavam implementando o que parecia, semanticamente, o mesmo módulo – leia a sessão, valide-a, atualize se expirar, retorne nulo se for inválido. Eles tinham tipos diferentes. Nomenclatura diferente. Semântica de erro diferente. O frontend tratou silenciosamente as sessões expiradas como "desconectar o usuário". O back-end retornou um 401. Não havia contrato compartilhado entre eles, o que significava que qualquer desvio entre os dois se manifestaria como um bug de UX. A proposta da skille: definir um único módulo Session com uma interface (digitada em esquema compartilhado), uma máquina de estado canônica (expressa em OpenAPI mais um cliente gerado) e um adaptador em cada lado que implementa a interface no ambiente local.

Dois adaptadores, uma interface. Uma verdadeira costura. Eu havia enviado um bug relacionado à sessão três semanas antes. A skille não sabia disso. A skille viu a arquitetura e previu o formato do bug apenas a partir da arquitetura.

Oportunidade 2: O criador de logs fragmentado. Eu tinha quatro utilitários de registro. Um wrapper console.log no frontend. Uma configuração pino no back-end. Um auxiliar de "evento estruturado" para análise. Um auxiliar de "extensão de telemetria" para rastreamento. Cada um deles foi acrescentado, separadamente, em resposta a uma necessidade real. Cada um parecia limpo isoladamente. Juntos, eles significavam que, quando eu quisesse depurar o fluxo de um usuário específico na stack, teria que ler quatro conjuntos de logs em quatro formatos diferentes. A proposta da skille: um único módulo Observability com uma interface — event(name, payload), error(err, context), span(name, fn) — e quatro adaptadores que se espalham para os transportes existentes. Mesmos sites de chamada. Mesmas saídas. Uma interface para eu aprender, quatro implementações por trás dela. Este foi um puro aprofundamento: nenhuma funcionalidade foi perdida, a vida dos chamadores foi significativamente simplificada.

Oportunidade 3: aquela com a qual discuti. A skille sinalizou meus ajudantes de validação de formulário como uma oportunidade de aprofundamento. Eu tinha validateEmail, validatePhone, validateRequired e meia dúzia de outros, cada um uma pequena função pura. A proposta: reuni-los em um único módulo Validator com um API fluente. Eu empurrei de volta. Funções puras geralmente são mais profundas do que parecem — validateEmail(email) tem uma interface pequena e uma implementação não trivial (RFC 5322 não é amigável), e a taxa de alavancagem é boa. O contra-argumento da skille era sobre localidade: os validadores eram usados ​​juntos, em clusters, em todos os formulários, e o código ao redor tinha que importar seis funções diferentes em vez de uma.

Após dez minutos de idas e vindas no bate-papo, admiti que o argumento da localidade era real, mas propus um compromisso - manter as funções puras, adicionar um módulo Form com um API fluente que as compõe. A perícia concordou, elaborou o novo formulário e arquivou a questão. Foi nesse momento que confiei nessa coisa.

As outras três oportunidades envolviam um módulo de estado de roteador que tinha uma máquina de estado dentro dele, uma integração de pagamento que estava vazando detalhes do webhook no código da interface do usuário e um sistema de sinalização de recursos que silenciosamente se transformou em três sistemas independentes de sinalização de recursos. Todos os três receberam propostas. Dois eu aceitei; um que adiei para o próximo trimestre.

Costuras e adaptadores — Por que o aprofundamento torna os testes possíveis

Aqui está a parte da skille que se conecta diretamente à possibilidade de sua base de código ser testável e a razão pela qual tudo isso é mais importante do que apenas "o código parece melhor".

Uma seam é um limite em seu código onde você pode substituir um falso pelo real sem alterar o código ao redor. Michael Feathers chamou isso assim em Working Effectively With Legacy Code — vinte anos atrás, mas nunca foi tão relevante quanto em 2026. A interface de um módulo é sua costura natural. Se o módulo tiver uma interface pequena e limpa, você poderá colocar uma falsificação do outro lado dessa interface para testes. Se o módulo tiver uma interface extensa e com vazamentos, cada teste terá que fingir ser real de doze maneiras diferentes, e você para de escrever testes porque eles prejudicam.

Um adaptador é a implementação concreta que fica do outro lado da costura. O real fala com o real – Postgres, a rede, o relógio do sistema. O falso devolve o que você quiser para o teste.

O exemplo mais claro, e aquele que uso agora para ensinar isso à minha equipe, é o relógio do sistema.

// The interface — a one-method module
interface Clock {
  now(): Date;
}

// The real adapter
class SystemClock implements Clock {
  now() { return new Date(); }
}

// The fake adapter, for tests
class FakeClock implements Clock {
  constructor(private current: Date) {}
  now() { return this.current; }
  advance(ms: number) {
    this.current = new Date(this.current.getTime() + ms);
  }
}

Agora, qualquer código que dependa do tempo depende de Clock, não de Date.now(). Na produção ele ganha o relógio real. Nos testes ele consegue um relógio falso que posso adiantar uma hora, um dia, um ano. Todos os testes que escrevi que dependiam do tempo costumavam ser esquisitos. Todos os testes que escrevi desde que extraí o relógio em um módulo profundo com dois adaptadores são determinísticos.

A skille adora esse tipo de refatoração. Quando ele verifica um repositório, a pergunta que ele faz em cada módulo é: para onde iria a costura de teste? Se a resposta for "em nenhum lugar óbvio - o módulo está se comunicando diretamente com o banco de dados e a rede e o relógio e o sistema de arquivos simultaneamente", essa é uma oportunidade de aprofundamento. A solução é extrair as dependências em módulos com suas próprias interfaces e, em seguida, colocar adaptadores em cada lado. De repente, todo teste doloroso fica fácil.

Esta é a parte que se paga mais rapidamente. O primeiro aprofundamento que fiz no relatório de skille - o módulo de sessão - me poupou uma tarde inteira na semana seguinte, quando precisei testar um caso extremo de expiração de sessão. Antes da refatoração, eu teria criado um banco de dados de teste, simulado uma chamada HTTP e orado. Após a refatoração, instanciei um adaptador de sessão falso, configurei sua expiração para 30 segundos atrás e executei uma asserção.

A armadilha do legado-codebase (e como evitá-la)

Agora o aviso, porque quase cometi esse erro.

Se você executar essa skille em uma base de código legada – uma com cobertura de teste irregular, baixa localidade e shallow modules em todos os lugares – o primeiro instinto é analisar o relatório de cima para baixo. Aproveite a maior oportunidade de aprofundamento, refatore agressivamente e envie.

Não.

A razão pela qual todo engenheiro sênior com cicatrizes nas mãos tem o mesmo conselho — não refatore código não testado — é que shallow modules sem testes são exatamente os módulos onde o aprofundamento irá quebrar coisas que você não sabia que existiam. Os chamadores dependem de comportamento não documentado. Os casos extremos se escondem nas rachaduras entre os módulos. O formato dos insetos é exatamente o que tornou os módulos superficiais em primeiro lugar.

O movimento certo é aquele sem glamour. Antes de se aprofundar, escreva testes de caracterização em torno do módulo superficial existente. Não são testes unitários. Testes não perfeitos. Apenas testes que identificam o comportamento atual – incluindo o comportamento de bugs – para que, ao se aprofundar, você tenha uma maneira de saber o que mudou. O livro de Feathers é a referência canônica aqui. A skille em si, em seu README, recomenda aproximadamente o mesmo fluxo de trabalho para código legado: escrever testes que documentem o comportamento atual do cluster que você está prestes a aprofundar, executar a proposta de aprofundamento da skille nesses testes e usar os deltas de teste como uma função forçada para decisões de design.

Agora sigo esta regra mesmo no código greenfield. Se uma proposta de aprofundamento diz respeito a um módulo que não possui testes, o primeiro commit no refatorador é o commit de teste. O compromisso de aprofundamento vem em segundo lugar. Isso me atrasa talvez vinte minutos por refatoração e me salva de sessões de depuração do tipo "espere, por que o painel está em branco agora" uma hora depois. Troca eu aceito sempre.

Quantas vezes eu executo agora (e onde ele tropeça)

Eu executo a skille todas as segundas-feiras de manhã em meu projeto principal e aproximadamente a cada cinco dias úteis em projetos paralelos com alta velocidade de commit. Essa cadência surgiu de uma observação simples: em um projeto para o qual envio diariamente o Claude Code, a entropia se acumula rápido o suficiente para que uma revisão arquitetônica semanal realmente a detecte antes que ela congele. Em um projeto que é praticamente estável, mensalmente é bom.

O conselho de cadência da documentação da skille é "a cada poucos dias em bases de código de rápida movimentação" e isso está de acordo com minha experiência. Se eu deixar isso passar por duas ou três semanas, o relatório passa de seis para quinze oportunidades, e aos quinze fico cansado de tomar decisões e começo a ignorar totalmente o relatório. Seis é o número certo para realmente agir.

Agora a parte honesta – onde a skille tropeça.

É ruim em expressões idiomáticas específicas do idioma. Quando o executei em um serviço Go, ele continuou propondo designs em formato de classe que não se enquadravam na granulação do Go. O vocabulário de módulos, interfaces e adaptadores é traduzido, mas o formato das propostas é tendencioso para TypeScript e Python. Se você estiver em um idioma com uma opinião própria forte – Go, Rust, Elixir – você gastará os primeiros cinco minutos de cada proposta traduzindo o idioma.

Também é cego para o custo do tempo de execução. Todas as propostas que recebi foram sobre custo cognitivo — quão fácil é entender o código, quão testável é a costura — e nenhuma delas considerou coisas como layout de memória, padrões de alocação ou desempenho de hot-path. Para a maioria dos códigos de aplicativos, tudo bem. Para qualquer coisa sensível ao desempenho, você deve adicionar seu próprio julgamento.

E o terceiro tropeço: às vezes propõe aprofundamentos que exigiriam que eu reescrevesse o conjunto de testes para validar. A proposta parece bonita isoladamente, mas o custo da migração — incluindo os testes que dependem do formato atual — é superior ao valor do novo formato. A skille não modela muito bem o custo da migração. Agora leio todas as propostas com uma pergunta no topo: como é a migração e o custo da migração é menor do que a alavancagem que eu ganharia? Na metade das vezes, a resposta é sim. A outra metade, encerro o assunto.

Se você estiver executando as skilles mais antigas, como a instalação do Karpathy CLAUDE.md ou qualquer um dos 32 hacks diários do Claude Code que escrevi no mês passado, essa skille está claramente acima deles. Os hacks tornam o envio do Claude Code mais rápido. A skille de arquitetura é a pressão arquitetônica que evita que a velocidade apodreça sua base de código.

A pergunta que carrego comigo agora

Seis semanas depois de começar a executar essa skille semanalmente, minha base de código está significativamente diferente de onde estava. Não dramaticamente menor – não excluí tanto código – mas significativamente mais navegável. O módulo de sessão é um só lugar. O módulo de observabilidade é um só lugar. A composição da forma possui uma única porta frontal. Quando abro um arquivo às 23h para depurar algo, geralmente consigo ver todo o conceito do arquivo em que estou, em vez de alternar entre quatro arquivos e reconstruir a arquitetura a partir da memória.

A mudança que mais importa é aquela a montante da base de código. Quando estou solicitando que o Claude Code envie um novo recurso agora, estou pensando primeiro nos módulos. Onde ficará a costura? Qual é a interface? Como é a versão profunda disso? A skille me treinou para fazer essas perguntas antes de escrever o prompt, o que significa que os próprios prompts produzem um código que já está mais próximo do que a próxima varredura da skille proporia.

A entropia de software é uma seta de mão única sem pressão arquitetônica. AI apenas fez a seta se mover mais rápido. A correção não é mais lenta, AI. A solução é mais pressão, aplicada anteriormente, por algo que se adapta à taxa de envio. A skille improve-codebase-architecture é a coisa mais próxima que encontrei dessa pressão e é a única ferramenta de revisão arquitetural em meu fluxo de trabalho que sobreviveu além do primeiro mês.

Se você tirar algo deste post, responda à pergunta que agora carrego em todas as sessões do Claude Code: este módulo é mais profundo ou mais superficial do que o que está substituindo? Pergunte antes de escrever o prompt. Pergunte novamente quando você ler a diferença. Pergunte nas manhãs de segunda-feira, com café, enquanto um pequeno arquivo de descontos examina seu repositório e informa coisas que você já sabia pela metade, mas estava cansado demais para enfrentar.

Essa pergunta está fazendo mais pelo meu código do que qualquer skille, estrutura ou ferramenta de refatoração que instalei nos últimos dois anos. A base de código para a qual você está enviando em 2027 será a base de código que a pergunta construiu – ou aquela que não foi construída.

Abra o relatório. Leia as seis coisas. Escolha um.

Perguntas frequentes

Qual é a skille improve-codebase-architecture em Claude Code?

É uma skille de código aberto de Matt Pocock que verifica um repositório em busca de shallow modules e propõe refatorações aprofundadas. Ele é executado dentro do Claude Code, produz uma lista de oportunidades de arquitetura e ajuda você a projetar interativamente as novas interfaces. Para obter o passo a passo completo do que foi encontrado em meu repositório, consulte "O dia em que executei em meu próprio repositório" acima.

O que é um módulo profundo em design de software?

Um módulo profundo é aquele com uma interface simples e uma implementação complexa, de modo que o chamador aprende muito pouco sobre o módulo, mas obtém muito comportamento em troca. O termo vem de A Philosophy of Software Design de John Ousterhout. Os módulos superficiais, por outro lado, possuem interfaces quase tão complexas quanto suas implementações e oferecem baixa alavancagem.

Com que frequência devo executar a skille de arquitetura de base de código?

A cada poucos dias em bases de código de rápida movimentação com commits diários assistidos por AI e semanalmente a mensalmente em repositórios mais estáveis. Passadas três semanas de silêncio, o relatório cresce para mais de dez oportunidades e a fadiga das decisões entra em ação. Seis oportunidades por semana é o ponto ideal para realmente agir de acordo com as propostas.

A skille refatora o código automaticamente?

Não, e isso é deliberado. Ele revela oportunidades cada vez maiores e ajuda você a projetar a nova interface e integração, mas os humanos tomam todas as decisões arquitetônicas e aprovam todas as alterações. Depois de aceitar uma proposta, ele poderá registrar um problema GitHub para rastrear o refatorador.

Devo aprofundar módulos em uma base de código legada sem testes?

Não diretamente. Escreva testes de caracterização em torno do cluster raso primeiro para fixar o comportamento existente e, em seguida, aprofunde-se com os testes como sua rede de segurança. Aprofundar o shallow modules não testado é uma das maneiras mais rápidas de enviar uma regressão.

Vamos trabalhar juntos

Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.

• Fiverr (comstackções e integrações personalizadas): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e marca): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io