Melhores Práticas de Governança

Q: Governança mínima para uma equipe móvel de duas pessoas?

CONTRIBUTING.md, lockfile + npm ci, expo lint + tsc em CI, modelo de PR com evidência de dispositivo e uma linha docs/eol-registry.md por SDK. Adicione campeões e SBOM quando um terceiro aplicativo ou cliente corporativo aparecer.

Q: Como governança e expo-rules diferem?

Governança é processo (quem, quando, como as decisões são registradas). expo-rules são não negociáveis técnicos (segredos, OTA, navegação). Ambos aparecem na revisão de PR; violações de qualquer um podem bloquear o merge.

Q: Maior falha de governança em equipes RN?

Deriva de SDK não documentada - múltiplas famílias runtimeVersion em produção sem calendário de EOL, levando a bricks de OTA e patches de segurança que nunca chegam ao aplicativo mais antigo.

Q: Quem mantém os documentos de governança?

Autores Staff / líder de plataforma; Líder aplica na revisão; Gerente de Engenharia patrocina tempo de calendário. Todos propõem atualizações de ADR quando a realidade diverge da política.

Um resumo condensado das 25 práticas de governança mais importantes para equipes móveis do Expo SDK 57 - extraído de todas as páginas desta seção.

Publique padrões em docs/CONTRIBUTING.md: Nomenclatura, pastas e regras de toque nativo vivem no git - não em pins do Slack que novos contratados nunca veem (Noções Básicas de Padrões).
Barras de recursos são bloqueadores de merge: Importe apenas de @/features/<name> - importações profundas acoplam refatorações; aplique com ESLint no-restricted-imports (Padrões de Código e Guias de Estilo).
app/ fina, src/features/ gorda: Arquivos de rota reexportam telas; a lógica de negócios nunca vive em nomes de arquivo do Expo Router - alinha-se com Checklist de Regras do Projeto Expo.
Regras de toque nativo têm proprietários nomeados: plugins/, app.config.ts, e ios/ / android/ verificados exigem CODEOWNERS da plataforma - equipes CNG regeneram, nunca editam manualmente (Regras de Módulos Nativos).
Superfície de comando única para qualidade: format:check, lint, typecheck, test - idêntico no Husky, laptop e GitHub Actions (Portões de Qualidade de CI).
ESLint sem avisos em main: expo lint -- --max-warnings 0 em CI - avisos se tornam dívida ignorada dentro de um sprint (Noções Básicas de Linting).
Prettier e ESLint não entram em conflito: Escolha Prettier para formatação e ordem de importação; desative regras de estilo conflitantes do ESLint (Prettier e Ordenação de Importações).
Modelo de PR codifica portões humanos: Evidência de dispositivo, anexos de diff nativo e caixas de seleção de padrões - política supera o sistema de honra (Padrões de Código e Guias de Estilo).
ADR para cada exceção intencional: Edições nativas "temporárias" ou violações de arquitetura sem ADR se tornam permanentes - use Registros de Decisão de Arquitetura.
Bloqueie lockfiles; CI usa npm ci: Instalações flutuantes escondem a discrepância nativa/JS até o TestFlight - nunca ignore package-lock.json no gitignore (Governança de Dependências e Cadeia de Suprimentos).
npx expo install para pacotes Expo: Pins de versão manuais causam falhas no doctor e travamentos nativos em produção - Melhores Práticas das Regras Expo.
npm audit falha em alto/crítico em CI: Documente o risco aceito em docs/security-exceptions.md com expiração - exceções sem datas não são aceitas (Governança de Dependências e Cadeia de Suprimentos).
SBOM por tag de release da loja: CycloneDX do lockfile arquivado com build_id do EAS - auditorias corporativas perguntam o que foi enviado na build abc123, não no main de hoje.
Licenças OSS nativas enviadas no aplicativo: Bundle de Configurações do iOS e tela OSS do Android atualizados a cada bump nativo - revisão jurídica sobre adições de classe GPL.
Janela de suporte apenas para SDK N-1: Produção suporta o SDK atual e um anterior - três gerações de SDK em uso quebram OTA e suporte (Política de Atualização de SDK).
Campeão de atualização nomeado por bump de SDK: Responsável pelo branch, expo-doctor, matriz de pré-visualização e ADR de runtimeVersion - não um voluntário na sprint 47 (Habilidade de Atualização de SDK).
Atualizações de SDK em branches dedicados + worktrees: Nunca misture expo upgrade com trabalho de recursos em main - hotfixes permanecem possíveis em worktree paralelo (Rebase Interativo e Worktrees).
expo-doctor e eas build de pré-visualização são portões de merge: OTA não pode corrigir a discrepância nativa de um merge de SDK ruim - matriz de build completa antes da produção (Regras de Release e OTA).
Registro de EOL com proprietários e prazos: Arquitetura RN, Expo SDK, pisos de SO e depreciações de API em docs/eol-registry.md - revisado trimestralmente (Rastreamento de Depreciação e EOL).
Aumentos de piso de SO são decisões de produto: Análise ASC / Play + ADR antes de aumentar deploymentTarget / minSdkVersion - preferência de engenharia sozinha é insuficiente.
Spikes são com tempo limitado e resultados de ADR: ADOTAR, ADIAR ou REJEITAR documentado; branches de spike excluídos após a demonstração - sem merge de sexta-feira sem flags e QA (Spikes, PoCs e Nova Arquitetura).
Spikes Brownfield usam artefatos isolados: expo-brownfield AAR/XCFramework - nunca copie e cole bundles JS em assets do host (Noções Básicas de Brownfield).
Nova Arquitetura validada em builds semelhantes a release: Expo Go não é prova - pré-visualização EAS + smoke test em dispositivo antes da habilitação NA em toda a organização no RN 0.86.
Calendário de risco alinha três relógios: Binário da loja, bundle OTA e depreciação de API de backend em um documento compartilhado - EOL móvel não deve atrasar a remoção da API (Calendário do Trem de Release).
Governança Staff+ é medida pela durabilidade: Políticas, runbooks e ADRs adotados por squads após sua saída - não linhas de código ou fins de semana de release heroicos (Crescimento na Carreira: Senior → Lead → Staff).

FAQs

Governança mínima para uma equipe móvel de duas pessoas?

CONTRIBUTING.md, lockfile + npm ci, expo lint + tsc em CI, modelo de PR com evidência de dispositivo e uma linha docs/eol-registry.md por SDK. Adicione campeões e SBOM quando um terceiro aplicativo ou cliente corporativo aparecer.

Como governança e expo-rules diferem?

Governança é processo (quem, quando, como as decisões são registradas). expo-rules são não negociáveis técnicos (segredos, OTA, navegação). Ambos aparecem na revisão de PR; violações de qualquer um podem bloquear o merge.

Maior falha de governança em equipes RN?

Deriva de SDK não documentada - múltiplas famílias runtimeVersion em produção sem calendário de EOL, levando a bricks de OTA e patches de segurança que nunca chegam ao aplicativo mais antigo.

Quem mantém os documentos de governança?

Autores Staff / líder de plataforma; Líder aplica na revisão; Gerente de Engenharia patrocina tempo de calendário. Todos propõem atualizações de ADR quando a realidade diverge da política.

Relacionados

Noções Básicas de Padrões - nomenclatura, pastas, toque nativo
Padrões de Código e Guias de Estilo - manual de aplicação
Governança de Dependências e Cadeia de Suprimentos - auditoria e SBOM
Política de Atualização de SDK - N-1 e campeões
Rastreamento de Depreciação e EOL - registro
Spikes, PoCs e Nova Arquitetura - experimentação segura
Crescimento na Carreira: Senior → Lead → Staff - caminho principal
Checklist de Regras do Projeto Expo - não negociáveis técnicos
Melhores Práticas de Linting e Formatação - resumo do portão de qualidade

Versões de Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Melhores Práticas de Governança

Um resumo condensado das 25 práticas de governança mais importantes para equipes móveis do Expo SDK 57 - extraído de todas as páginas desta seção.

Publique padrões em docs/CONTRIBUTING.md: Nomenclatura, pastas e regras de toque nativo vivem no git - não em pins do Slack que novos contratados nunca veem (Noções Básicas de Padrões).
Barras de recursos são bloqueadores de merge: Importe apenas de @/features/<name> - importações profundas acoplam refatorações; aplique com ESLint no-restricted-imports (Padrões de Código e Guias de Estilo).
app/ fina, src/features/ gorda: Arquivos de rota reexportam telas; a lógica de negócios nunca vive em nomes de arquivo do Expo Router - alinha-se com Checklist de Regras do Projeto Expo.
Regras de toque nativo têm proprietários nomeados: plugins/, app.config.ts, e ios/ / android/ verificados exigem CODEOWNERS da plataforma - equipes CNG regeneram, nunca editam manualmente (Regras de Módulos Nativos).
Superfície de comando única para qualidade: format:check, lint, typecheck, test - idêntico no Husky, laptop e GitHub Actions (Portões de Qualidade de CI).
ESLint sem avisos em main: expo lint -- --max-warnings 0 em CI - avisos se tornam dívida ignorada dentro de um sprint (Noções Básicas de Linting).
Prettier e ESLint não entram em conflito: Escolha Prettier para formatação e ordem de importação; desative regras de estilo conflitantes do ESLint (Prettier e Ordenação de Importações).
Modelo de PR codifica portões humanos: Evidência de dispositivo, anexos de diff nativo e caixas de seleção de padrões - política supera o sistema de honra (Padrões de Código e Guias de Estilo).
ADR para cada exceção intencional: Edições nativas "temporárias" ou violações de arquitetura sem ADR se tornam permanentes - use Registros de Decisão de Arquitetura.
Bloqueie lockfiles; CI usa npm ci: Instalações flutuantes escondem a discrepância nativa/JS até o TestFlight - nunca ignore package-lock.json no gitignore (Governança de Dependências e Cadeia de Suprimentos).
npx expo install para pacotes Expo: Pins de versão manuais causam falhas no doctor e travamentos nativos em produção - Melhores Práticas das Regras Expo.
npm audit falha em alto/crítico em CI: Documente o risco aceito em docs/security-exceptions.md com expiração - exceções sem datas não são aceitas (Governança de Dependências e Cadeia de Suprimentos).
SBOM por tag de release da loja: CycloneDX do lockfile arquivado com build_id do EAS - auditorias corporativas perguntam o que foi enviado na build abc123, não no main de hoje.
Licenças OSS nativas enviadas no aplicativo: Bundle de Configurações do iOS e tela OSS do Android atualizados a cada bump nativo - revisão jurídica sobre adições de classe GPL.
Janela de suporte apenas para SDK N-1: Produção suporta o SDK atual e um anterior - três gerações de SDK em uso quebram OTA e suporte (Política de Atualização de SDK).
Campeão de atualização nomeado por bump de SDK: Responsável pelo branch, expo-doctor, matriz de pré-visualização e ADR de runtimeVersion - não um voluntário na sprint 47 (Habilidade de Atualização de SDK).
Atualizações de SDK em branches dedicados + worktrees: Nunca misture expo upgrade com trabalho de recursos em main - hotfixes permanecem possíveis em worktree paralelo (Rebase Interativo e Worktrees).
expo-doctor e eas build de pré-visualização são portões de merge: OTA não pode corrigir a discrepância nativa de um merge de SDK ruim - matriz de build completa antes da produção (Regras de Release e OTA).
Registro de EOL com proprietários e prazos: Arquitetura RN, Expo SDK, pisos de SO e depreciações de API em docs/eol-registry.md - revisado trimestralmente (Rastreamento de Depreciação e EOL).
Aumentos de piso de SO são decisões de produto: Análise ASC / Play + ADR antes de aumentar deploymentTarget / minSdkVersion - preferência de engenharia sozinha é insuficiente.
Spikes são com tempo limitado e resultados de ADR: ADOTAR, ADIAR ou REJEITAR documentado; branches de spike excluídos após a demonstração - sem merge de sexta-feira sem flags e QA (Spikes, PoCs e Nova Arquitetura).
Spikes Brownfield usam artefatos isolados: expo-brownfield AAR/XCFramework - nunca copie e cole bundles JS em assets do host (Noções Básicas de Brownfield).
Nova Arquitetura validada em builds semelhantes a release: Expo Go não é prova - pré-visualização EAS + smoke test em dispositivo antes da habilitação NA em toda a organização no RN 0.86.
Calendário de risco alinha três relógios: Binário da loja, bundle OTA e depreciação de API de backend em um documento compartilhado - EOL móvel não deve atrasar a remoção da API (Calendário do Trem de Release).
Governança Staff+ é medida pela durabilidade: Políticas, runbooks e ADRs adotados por squads após sua saída - não linhas de código ou fins de semana de release heroicos (Crescimento na Carreira: Senior → Lead → Staff).