YAGNI no desenvolvimento de aplicativos: o que é, a essência do princípio e o benefício prático

O que é YAGNI?

YAGNI (You Aren't Gonna Need It) — um princípio de programação extrema (XP) que significa “você não vai precisar disso”. A regra diz: nunca implemente funcionalidade que não seja exigida pelas histórias de usuário atuais. Se um recurso não for necessário hoje — não o faça, nem mesmo “por precaução”.

O termo foi cunhado por Ron Jeffries, um dos coautores da metodologia XP (com Kent Beck). Jeffries afirmava: “Implemente a coisa mais simples que funciona e não adicione nada até que seja necessário”. YAGNI não é uma proibição de planejar, mas uma proibição de implementação prematura.

De acordo com o Standish Group CHAOS Report (2023), 64% das funcionalidades em um produto de software médio são raramente ou nunca usadas. Extrapolando para um aplicativo móvel — mais da metade do código escrito não agrega valor ao usuário. YAGNI evita esse desperdício de recursos.

Aplique YAGNI como um filtro rigoroso: cada recurso deve responder à pergunta “que problema específico do usuário ele resolve agora?” Se não houver resposta — o recurso não é necessário.

Diferença entre YAGNI e preguiça ou atalhos

YAGNI não é uma rejeição à arquitetura de qualidade. YAGNI proíbe escrever código desnecessário, mas não proíbe escrever código correto. Se um recurso atual precisa de uma camada de abstração limpa — crie-a. Se a camada não for necessária — não a crie. Diferença chave: YAGNI é sobre funcionalidade, não sobre qualidade.

Os desenvolvedores frequentemente confundem YAGNI com acúmulo intencional de dívida técnica (a dívida técnica é sempre um compromisso, YAGNI é um princípio de eficiência). A diferença é que a dívida técnica é reconhecida e documentada, enquanto violar YAGNI é simplesmente trabalho extra.

Pergunte a si mesmo: “Se eu não criar esta abstração agora, quanto tempo levará a refatoração quando for necessária?” Se o tempo de refatoração for menor que o tempo de escrita agora — adie.

Por que YAGNI é crítico para projetos móveis?

O desenvolvimento móvel é especialmente sensível a violações de YAGNI por três razões: o tamanho do APK/IPA afeta diretamente a taxa de conversão de instalação, o tempo de compilação de projetos móveis cresce linearmente com o volume de código, e cada recurso extra adiciona pontos de falha. YAGNI não é sobre preguiça, mas sobre foco.

Um estudo do Google Play Console Data (2023) mostrou: a cada 10 MB de tamanho do APK, a probabilidade de instalação diminui 1,2%. Código não utilizado não é apenas lixo no repositório — é perda financeira direta. Bibliotecas extras (para funcionalidade que “talvez adicionemos depois”) são a fonte mais comum de inchaço do APK.

De acordo com o Gradle Build Performance Report (2024), cada módulo adicional em um projeto Android aumenta o tempo de compilação completa em 3–7 segundos. Se você adicionar 5 módulos “por precaução” — o aumento do tempo de compilação será de 15–35 segundos por compilação. Em um ano, uma equipe de 5 desenvolvedores perde até 200 horas-homem esperando a compilação.

Monitore o tamanho do binário no CI: defina um limite de aviso (por exemplo, +500 KB por commit). Se o tamanho aumentou sem um novo recurso — é uma violação de YAGNI que deve ser discutida na revisão de código.

YAGNI vs gold-plating: exemplos práticos

Gold-plating: animação prematura

Gold-plating — adicionar funcionalidade além dos requisitos na tentativa de “melhorar” o produto. Um exemplo típico: um desenvolvedor adiciona uma animação complexa de transição entre telas, embora o design especifique um fade simples. A animação leva 2 dias, o usuário não a nota, e bugs em diferentes dispositivos perseguem o projeto por anos.

De acordo com o UX Collective Annual Report (2023), 78% dos usuários avaliam um aplicativo pela velocidade e estabilidade, não por animações. YAGNI diz: se a animação não está especificada nos requisitos — não a implemente. O designer adicionará a animação quando realmente for necessária para resolver um problema de UX.

Implemente apenas o que está nos layouts. Se o designer não desenhou uma animação — ela não deve existir. Qualquer desvio do layout é uma violação de YAGNI.

Localização prematura para 20 idiomas

Um erro comum de startups: já incluir suporte para 20+ idiomas “para futura entrada no mercado internacional”. YAGNI recomenda: localize apenas para o idioma do mercado atual. Adicionar cada novo idioma requer tempo de tradutores, testes de strings para corte e depuração de layouts RTL.

De acordo com o Deloitte Digital Globalization Survey (2022), 60% dos aplicativos móveis nunca saem do seu primeiro mercado. Se for o seu caso — os recursos gastos com suporte multilíngue são desperdiçados. Abordagem YAGNI: inglês (base) + idioma do mercado-alvo. Os demais — conforme você realmente entrar em uma região.

Use YAGNI para priorizar: se um recurso não estiver no roadmap dos próximos dois trimestres — não o inicie. O roadmap deve ser documentado e aprovado pelo gerente de produto.

Como aplicar YAGNI no Android e iOS?

YAGNI no Android: não adicione bibliotecas desnecessárias

Projetos Android sofrem de inflação de bibliotecas. Desenvolvedores adicionam Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — antes mesmo de escrever a primeira linha de lógica de negócio. YAGNI recomenda: adicione bibliotecas conforme a necessidade real, não preventivamente.

// Violação de YAGNI: inclusão preventiva de bibliotecas
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// E o aplicativo apenas mostra "Hello World"

Bibliotecas são dependências com sua própria complexidade. Cada uma requer atualizações de versão, migração em mudanças bruscas e aumenta o tamanho do APK. Adicione uma biblioteca quando surgir uma tarefa específica que essa biblioteca resolva. Comece com OkHttp (cliente HTTP mínimo), adicione Retrofit quando precisar de um cliente REST, e assim por diante.

YAGNI no iOS: não force SwiftUI

SwiftUI é um framework poderoso, mas sua adoção deve ser impulsionada por necessidades reais. Se um projeto começa com iOS 14+ e os requisitos de componentes de UI personalizados são mínimos — SwiftUI é uma boa escolha. Se um projeto precisa suportar iOS 13 ou requer gestos personalizados complexos — UIKit continua sendo a solução correta. YAGNI é contra migrar para SwiftUI “porque está na moda”.

// YAGNI: use UIKit enquanto não houver benefício real do SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Perfil"
    }
}

// Se o SwiftUI for necessário — integre via UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

A análise do Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) recomenda: não migre telas UIKit existentes para SwiftUI sem uma razão de negócio clara (por exemplo, necessidade de Live Preview para o designer). Reescrever código que funciona é uma violação direta de YAGNI. SwiftUI — para novas telas, UIKit — para as existentes.

Erros típicos ao seguir YAGNI

YAGNI como desculpa para arquitetura ruim

O erro mais perigoso é usar YAGNI como desculpa para uma arquitetura ruim. “Não criaremos uma camada de repositório porque YAGNI — escreveremos a consulta diretamente no ViewModel”. Isso não é YAGNI, é acumular dívida técnica. YAGNI proíbe funcionalidade desnecessária, não integridade arquitetônica.

Arquitetura é um investimento em manutenibilidade. Se você está escrevendo mais de 3 telas — uma camada arquitetônica básica (MVVM, repositório) já é justificada. Se é 1 tela — você pode se dar ao luxo de uma abordagem mais simples. O segredo: determine o mínimo arquitetônico necessário para os recursos atuais e não adicione mais.

Separe as decisões em “arquitetônicas” e “funcionais”. Decisões arquitetônicas (camadas, navegação, DI) não são cobertas por YAGNI — são necessárias para a manutenibilidade. Decisões funcionais (recursos, capturas de tela, animações) — são cobertas.

Seguir YAGNI cegamente ao trabalhar com APIs

Outro extremo — ignorar contratos de API futuros. Um desenvolvedor recebe um JSON do backend com 5 campos e analisa apenas 3, porque “os demais não são necessários segundo YAGNI”. O problema: ao adicionar um campo, o backend pode quebrar a análise se a resposta mudou. A solução é mapear todos os campos da resposta, mesmo que nem todos sejam usados agora.

De acordo com as Meta API Design Guidelines (2023), o cliente deve analisar todos os campos retornados pelo servidor, ignorando os não utilizados, mas sem descartar toda a estrutura. YAGNI aqui é sobre outra coisa: não adicione tratamento de campos que ainda não estão na especificação “por precaução caso o backend os retorne”.

Analise toda a estrutura da resposta (todos os campos que o servidor retorna atualmente). Não adicione tratamento de campos que não estão na especificação atual da API. Este é um equilíbrio entre YAGNI e resiliência à mudança.