Skip to main content

empirical-software-design

Especialista em Design Empírico de Software e Refatoração Incremental estilo Tidy First (Kent Beck). Cobre estrutura vs comportamento (tidying separado de mudança), teoria econômica do design (opções reais, custo de mudança), acoplamento e coesão, o repertório de tidyings (guard clauses, extrair variável/função, inline, juntar/quebrar, moving features), e a decisão Quando fazer Tidy (Now? Never? Later?).

Ir a la instalación

Datos de origen

Repositorio
dandgabr/skills
Última actividad en el origen
7 de septiembre de 2026 a las 01:33
Idioma detectado de SKILL.md
portugués
Estrellas
9
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
5 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
empirical-software-design
description
Especialista em Design Empírico de Software e Refatoração Incremental estilo Tidy First (Kent Beck). Cobre estrutura vs comportamento (tidying separado de mudança), teoria econômica do design (opções reais, custo de mudança), acoplamento e coesão, o repertório de tidyings (guard clauses, extrair variável/função, inline, juntar/quebrar, moving features), e a decisão Quando fazer Tidy (Now? Never? Later?).
# Habilidade de IA: Design Empírico de Software (Tidy First / Empirical Software Design) Esta skill orienta a inteligência artificial a melhorar o design de código de forma **incremental, pequena e reversível**, separando mudanças de estrutura de mudanças de comportamento, baseada na obra *Tidy First? A Personal Exercise in Empirical Software Design* (Kent Beck). --- ## 🎯 1. Princípio Central: Separe Estrutura de Comportamento - **Mudança de comportamento** = alterar o que o sistema faz (novas regras, features, fixes). - **Mudança de estrutura (tidying)** = alterar como o código está organizado **sem alterar seu comportamento** (extrair função, renomear, mover código). - **Nunca misture os dois no mesmo commit/mudança**. Primeiro tidy, depois a mudança de comportamento ("Tidy First?"), ou tidy depois ("Tidy After?"), mas identifique explicitamente qual está fazendo. - Benefício: diffs pequenos, revisão trivial, bisect confiável, conflitos de merge minimizados. --- ## 💰 2. Teoria Econômica do Design Software design é, antes de tudo, um **exercício econômico**: minimize o custo total futuro. - **Custo humano ≠ custo hoje**: o custo de uma mudança inclui o tempo de quem lê, entende e modifica depois. Pagar um pouco agora (tidy) pode reduzir muito o custo amanhã. - **Opções reais (Real Options)**: manter flexibilidade tem valor — como uma opção financeira, adiar decisões irreversíveis e simplificar reversíveis cria valor. Não centralize cedo demais nem espalhe prematuramente. - **`Custo(mudança) = Σ esforço(ler, entender, editar, testar)`**: otimize para o leitor futuro, não para o escritor de hoje. - **Opção vs obrigação**: cada acoplamento cria obrigação; cada abstração bem colocada cria opção. Prefira designs que aumentem opções a médio prazo. - **Escala de tempo**: tidyings levam segundos/minutos; designs estruturais levam dias; otimize a taxa de mudança agregada, não cada linha. --- ## 🧲 3. Acoplamento e Coesão (Teoria do Design) - **Acoplamento**: quanto mudar um elemento força mudar outros. Reduza acoplamento para reduzir custo de mudança. - **Coesão**: elementos que mudam juntos devem viver juntos. Aumente coesão agrupando por razões de mudança. - **Regra prática de design local**: prefira o design que torna a próxima mudança mais barata — julgue cada decisão no contexto, empiricamente ("empirical software design"), sem dogmas como "menos linhas é melhor". - **Sem Best Practices universais**: o que é bom design depende do fluxo de mudanças do sistema específico. Observe onde o código muda com frequência e co-losine (couple/cohesion) de acordo. --- ## 🧰 4. Repertório de Tidyings (catálogo de micro-refatorações) Execute tidyings em minutos, um por commit: | Tidying | Descrição resumida | | :--- | :--- | | **Guard Clause** | Saia cedo das condições inválidas para achatar aninhamento. | | **Extract Variable / Function** | Nomeie expressões e passos para comunicar intenção. | | **Inline Variable / Function** | Remova indireções sem valor de comunicação. | | **Join Function** | Una funções chamadas só uma vez, uma só vez, juntas. | | **Block Commentary** | Marque blocos com comentários transicionais que depois viram funções. | | **Explicit Parameters** | Substitua réplicas de params implícitos (globais/campos) por parâmetros explícitos. | | **Normalize Symbols** | Padronize nomes para o mesmo conceito (um conceito, um nome). | | **New Interface (Old Implementation)** | Introduza a interface-alvo e delegue, migrando usos gradualmente. | | **Move Function/Field** | Realoque para perto dos dados/behaviors com que muda junto. | | **Combine Similar Shapes** | Una estruturas semelhantes em uma (cuidado: só se o custo de generalizar < manter duas). | | **Helper Function & Helper Relation** | Extraia repetição para helpers; aproxime helper de quem o usa. | | **Reorder Logic (read top-down)** | Coloque o caso principal primeiro e pormenores depois. | | **Extract Constant** | Magic numbers/strings viram constantes nomeadas. | --- ## 🤔 5. Decisão: Quando Fazer Tidy? Aplique a árvore de decisão antes de qualquer mudança: 1. **Será que vale a pena tidyar?** (custo do tidy × economia futura) 2. **Tidy agora (Now), depois (Later), ou nunca (Never)?** - **Now**: o tidy é pequeno (minutos) e destrava a mudança imediata. - **Later**: necessário, mas grande/inseguro agora — anote (TODO/issue) e faça depois, em passo próprio. - **Never**: tidy que não paga o custo (código prestes a morrer, área estável, deep freeze). 3. **Pergunte sempre: este tidy me aproxima ou me afasta do comportamento alvo?** 4. **Limite**: tidyings opcionalmente em lote, mas **nunca** misture tidy + feature no mesmo diff. Se o tidy virar avalanche, corte-o e faça só o essencial. --- ## 🔄 6. Protocolo de Execução (para IA em codebases reais) 1. **Leia para entender onde muda**: identifique o ponto de mudança requisitado e o entorno acoplado. 2. **Liste tidyings candidatos**: baratos, locais, que facilitam a mudança. 3. **Classifique cada um**: Now / Later / Never, com justificativa econômica curta. 4. **Execute tidyings "Now"** em commits separados (`refactor:`), comportamento preservado (testes verdes). 5. **Implemente a mudança de comportamento** em commit próprio (`feat:`/`fix:`). 6. **Comunicue**: em revisões, explique 1) o que muda, 2) o que foi tidado antes/depois e por quê. 7. **Nunca** aproveite o tidy para mudar comportamento "de passagem". --- ## 🔗 Integração com Outras Skills - [clean-code-reusability](../clean-code-reusability/SKILL.md): clean code dá o vocabulário; Tidy First dá o *ritmo* e a economia das mudanças. - [software-architect](../../roles/software-architect/SKILL.md): tidyings micro alimentam decisões macro do arquiteto com dados de mudança real. - [sast-code-review](../../security/appsec/sast-code-review/SKILL.md): revise tidyings garantindo que nenhum controle de segurança foi afrouxado. - [framework-testing](../../framework/framework-testing/SKILL.md): testes verdes são a pré-condição de qualquer tidy (rede de segurança). - [lang-python](../../languages/lang-python/SKILL.md), [lang-java](../../languages/lang-java/SKILL.md), [lang-typescript](../../languages/lang-typescript/SKILL.md), [lang-go](../../languages/lang-go/SKILL.md), [lang-csharp](../../languages/lang-csharp/SKILL.md): aplique tidyings idiomáticos da linguagem em uso.
Ver en GitHub