- Trabalhar em uma grande base de código é uma das tarefas mais difíceis para engenheiros de software. É difícil adquirir esse tipo de experiência em projetos pessoais ou de código aberto
- Milhões de linhas de código, 100 a 1000 engenheiros trabalhando ao mesmo tempo, base de código com pelo menos 10 anos
- Exige uma habilidade própria para entender um estado acumulado de complexidade e tempo
O maior erro é a falta de consistência
- O erro mais comum é ignorar a base de código existente e implementar sua funcionalidade do seu próprio jeito. Isso impede a manutenção da consistência e aumenta a confusão na base de código
- Em geral, isso é feito de forma independente para minimizar a interação com a base de código existente, preservar seu código "limpo" e evitar o código "legado"
- A consistência reduz a complexidade da base de código e facilita melhorias futuras
- Por exemplo, ao implementar um endpoint de API, é importante seguir a forma de autenticação já existente. Isso ajuda a atravessar com segurança o campo minado da base de código
- Sem padrões consistentes, todo o código precisa ser atualizado manualmente, e isso fica cada vez mais difícil
Outros fatores importantes
- Entender como o serviço é realmente usado
- Identificar os principais endpoints de API mais usados e os caminhos críticos (
hot path)
- Tratar com cuidado mudanças em código de uso frequente
- Importância de testes e monitoramento
- Em projetos de grande escala, não é possível testar todos os estados, então testam-se apenas os caminhos principais
- Escreva o código de forma defensiva e dependa de rollout gradual e monitoramento
- Evite adicionar dependências
- Dependências causam problemas de segurança e aumentam os custos de manutenção
- Se for realmente necessário, escolha dependências confiáveis
- Remover código com cautela, mas de forma ativa
- Analise dados de produção para remover chamadas com segurança e depois apagar o código
- Remover código desnecessário facilita a manutenção da base de código
- Esse é um dos trabalhos mais valiosos em grandes bases de código
- Trabalhe com PRs pequenos e trate primeiro mudanças que afetam o código de outras equipes
- Isso permite que especialistas do domínio encontrem problemas e evitem incidentes
Por que grandes bases de código são importantes?
- Valor das grandes bases de código
- A maioria das empresas de tecnologia gera receita a partir de grandes bases de código
- Trabalhar em uma "base de código legada" significa lidar com o trabalho real da empresa
- É preciso entender antes de separar o código
- Para dividir uma grande base de código, primeiro é preciso entender bem como ela funciona como um todo
- Sem esse entendimento, um grande redesenho é impossível
Resumo
- Grandes bases de código têm importante valor de negócio
- O mais importante é manter a consistência
- Antes de implementar uma nova funcionalidade, investigue o código existente e siga os padrões
- Se você não for seguir os padrões existentes, deve haver um motivo muito forte
- Entenda como o código é usado em produção
- Como não é possível testar todos os casos, não dependa excessivamente de testes; dependa de monitoramento e rollout gradual
- Aproveite ativamente oportunidades de remover código, mas faça isso com cautela
- Trabalhe em PRs pequenos para que especialistas do domínio possam revisar
8 comentários
A consistência é importante, mas isso não significa que adiar melhorias no código ou repetir padrões errados já existentes seja uma boa abordagem... é uma questão difícil. Afinal, ao manter a consistência, você também pode acabar acumulando a mesma dívida técnica.
Acima de tudo, é preciso seguir as convenções de codificação.
Especialmente as regras de indentação...
Você trabalha em um domínio em que não dá para aplicar ferramentas que detectam isso automaticamente...? T_T
Sim... T_T
Vou chorar por vocês... buáááááááá
A escala do projeto != maturidade
Concordo que consistência é muito importante, mas acho que devemos evitar usar isso como desculpa para dar baixa prioridade à melhoria do codebase.
Como o projeto está sempre vivo e crescendo, se não conseguirmos fazer melhorias no momento adequado, será preciso muito mais tempo e esforço para reverter isso depois.
Também concordo. Trabalho com um projeto com mais de 20 anos, e há muitas partes que realmente são bastante imaturas em comparação com os padrões atuais.
Embora a consistência tenha a vantagem de aumentar a compreensão do código, as limitações da estrutura acabam gerando limitações funcionais e atrapalhando a evolução do serviço, então acho que, às vezes, também é necessária uma reformulação mais ousada.
Opinião no Hacker News
Quando uma base de código legada é inconsistente, é importante introduzir uma nova forma de fazer as coisas, documentá-la e receber feedback. Deve-se tentar manter consistência com o código existente.
É preciso usar as ferramentas da base de código existente, mas pode ser mais prazeroso construir uma nova base de código.
Para dividir uma base de código grande, primeiro é preciso entendê-la, e há grande chance de fracasso quando uma equipe sem experiência tenta fazer isso.
Há muitas tentativas de melhorar aleatoriamente uma base de código grande.
É difícil sustentar a evolução de uma base de código.
Quando a base de código é grande e há falta de pessoal, leva muito tempo até que uma pessoa nova se torne produtiva.
Manter a base de código limpa significa fazer apenas o trabalho mínimo necessário para lançar funcionalidades.
Consistência não é a coisa mais importante, e é melhor melhorar partes da base de código.
A frase "falta de consistência é um erro fatal" está 100% correta.
Três máximas para engenheiros: