Desenvolvimento Paralelo de Funcionalidades

Estratégias para decompor funcionalidades em fluxos de trabalho paralelos, estabelecer limites de propriedade de arquivos, evitar conflitos e integrar resultados de múltiplos agentes implementadores.

Quando Usar Esta Habilidade

• Decompor uma funcionalidade para implementação paralela
• Estabelecer limites de propriedade de arquivos entre agentes
• Projetar contratos de interface entre fluxos de trabalho paralelos
• Escolher estratégias de integração (fatia vertical vs. camada horizontal)
• Gerenciar fluxos de trabalho de branch e merge para desenvolvimento paralelo

Estratégias de Propriedade de Arquivos

Por Diretório

Atribua a cada implementador a propriedade de diretórios específicos:

implementer-1: src/components/auth/
implementer-2: src/api/auth/
implementer-3: tests/auth/

Ideal para: Bases de código bem organizadas com limites claros de diretório.

Por Módulo

Atribua a propriedade de módulos lógicos (que podem abranger diretórios):

implementer-1: Authentication module (login, register, logout)
implementer-2: Authorization module (roles, permissions, guards)

Ideal para: Arquiteturas orientadas a funcionalidades, design orientado a domínio.

Por Camada

Atribua a propriedade de camadas arquiteturais:

implementer-1: UI layer (components, styles, layouts)
implementer-2: Business logic layer (services, validators)
implementer-3: Data layer (models, repositories, migrations)

Ideal para: Arquiteturas MVC/camadas tradicionais.

Regras de Evitação de Conflitos

A Regra Cardinal

Um proprietário por arquivo. Nenhum arquivo deve ser atribuído a múltiplos implementadores.

Quando Arquivos Precisam Ser Compartilhados

Se um arquivo genuinamente precisar de alterações de múltiplos implementadores:

1. Designar um único proprietário — Um implementador é o proprietário do arquivo
2. Outros implementadores solicitam alterações — Envie uma mensagem ao proprietário com solicitações de alteração específicas
3. Proprietário aplica alterações sequencialmente — Evita conflitos de merge
4. Alternativa: Extrair interfaces — Crie um arquivo de interface separado que o não proprietário possa importar sem modificar

Contratos de Interface

Quando os implementadores precisam coordenar em limites:

// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
export interface AuthResponse {
  token: string;
  user: UserProfile;
  expiresAt: number;
}

export interface AuthService {
  login(email: string, password: string): Promise<AuthResponse>;
  register(data: RegisterData): Promise<AuthResponse>;
}

Ambos os implementadores importam do arquivo de contrato, mas nenhum o modifica.

Padrões de Integração

Fatia Vertical

Cada implementador constrói uma fatia completa da funcionalidade (UI + API + testes):

implementer-1: Login feature (login form + login API + login tests)
implementer-2: Register feature (register form + register API + register tests)

Prós: Cada fatia é testável independentemente, integração mínima necessária. Contras: Pode duplicar utilitários compartilhados, mais difícil com funcionalidades rigidamente acopladas.

Camada Horizontal

Cada implementador constrói uma camada em todas as funcionalidades:

implementer-1: All UI components (login form, register form, profile page)
implementer-2: All API endpoints (login, register, profile)
implementer-3: All tests (unit, integration, e2e)

Prós: Padrões consistentes dentro de cada camada, especialização natural. Contras: Mais pontos de integração, a camada 3 depende das camadas 1 e 2.

Híbrido

Mistura vertical e horizontal com base no acoplamento:

implementer-1: Login feature (vertical slice — UI + API + tests)
implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)

Ideal para: A maioria das funcionalidades do mundo real com alguma infraestrutura compartilhada.

Gerenciamento de Branches

Estratégia de Branch Único

Todos os implementadores trabalham no mesmo branch de funcionalidade:

• Configuração simples, sem sobrecarga de merge
• Requer propriedade estrita de arquivos para evitar conflitos
• Ideal para: equipes pequenas (2-3), limites bem definidos

Estratégia Multi-Branch

Cada implementador trabalha em um sub-branch:

feature/auth
  ├── feature/auth-login      (implementer-1)
  ├── feature/auth-register    (implementer-2)
  └── feature/auth-tests       (implementer-3)

• Mais isolamento, pontos de merge explícitos
• Maior sobrecarga, conflitos de merge ainda possíveis em arquivos compartilhados
• Ideal para: equipes maiores (4+), funcionalidades complexas

Solução de Problemas

Implementadores estão se bloqueando mutuamente esperando por código compartilhado.

…