Leva 6 dias para mudar uma linha de código (2015)

• A fábrica está sendo utilizada em menos de 10%.
• A política da empresa limita a criação de um backlog superior a 3 meses.
• Alterar a política para 4 meses resolve o problema.
• Uma mudança de configuração em um software legado exige alterar uma linha de código.
• O processo de implementação da mudança inclui abrir um ticket, preencher as seções necessárias e obter a aprovação do diretor.
• A mudança é urgente para evitar demissões.
• O programador altera o código com sucesso, mas surgem problemas por causa de variáveis hardcoded e outros erros.
• O código precisa passar por revisão por cópia e testes, e só depois pode ir para produção.
• O acesso ao ambiente de testes necessário é atrasado por problemas de permissão e disponibilidade.
• Os registros de parâmetros precisam ser renomeados e ter trilha de auditoria.
• O programador faz as mudanças necessárias e reenvia o código para nova revisão.
• Os testes exigem um plano de teste adequado, incluindo casos de teste selecionados pelo usuário e resultados esperados.
• Depois de 6 dias, o programa é aprovado para ir para produção.

[GN⁺]

Comentários do Hacker News

• O problema central é recusar quando revisores pedem mudanças que afetam outras partes da base de código.
• Pull requests focados e resistência ao aumento de escopo são lições importantes.
• O processo de revisão de código pode estar cheio de observações exigentes e comentários triviais.
• A equipe de segurança pode não responder rapidamente aos pedidos de permissão.
• O título do artigo pode ser enganoso, e houve melhorias adicionais ao longo dos 6 dias.
• Uma mudança de uma linha pode causar consequências inesperadas.
• O processo de revisão de código pode virar um gatekeeper e atrasar o progresso.
• Permitir comentários sem bloquear commits pode levar a um desenvolvimento mais eficiente.
• Mudar de uma equipe que faz revisão de código formal para outra que não faz pode ser revigorante e dar mais autonomia.
• Há diferenças entre a forma de gerenciar operários de fábrica e desenvolvedores de software.
• Reter mudanças com base em ideais de equipe em transformação é disfuncional.
• O problema está no processo da empresa, não na revisão de código em si.