- Recentemente, em uma conversa com um CEO de tecnologia renomado e um engenheiro, ouvi uma metodologia interessante de desenvolvimento de software. Ela me fez pensar sobre outras heurísticas e generalizações.
O método dele
- No início do dia, começa-se a trabalhar em uma funcionalidade. Se ela não estiver concluída até o fim do dia, apaga-se tudo e recomeça no dia seguinte. Os testes unitários escritos podem ser mantidos.
- Se, depois de alguns dias, ainda não for possível implementar a funcionalidade, pensa-se na base, infraestrutura ou refatoração que a tornaria possível, implementa-se isso e depois volta-se à funcionalidade.
- Esse método é semelhante ao movimento de Programação Extrema do fim dos anos 90 e início dos anos 2000.
Reflexões sobre o método
"Escreva tudo duas vezes"
- Um conselho dado a engenheiros juniores: resolva o problema, salve o código em um branch e depois escreva tudo de novo.
- Descobri esse método por acaso depois que meu notebook quebrou. Reescrever levou apenas 25% do tempo da implementação inicial, e o resultado foi muito melhor.
- Com 1,25x do tempo, é possível obter um código com qualidade duas vezes maior. É útil para projetos que exigem manutenção de longo prazo.
- O método de "recomeçar todos os dias" é ainda mais extremo. A cada reescrita, você tende a encontrar uma solução mais elegante.
"Quantidade tem sua própria qualidade"
- A citação de Stalin se aplica a engenheiros de software. Para engenheiros juniores, as primeiras 100 mil linhas de código são essenciais.
- O método de "recomeçar todos os dias" ajuda a escrever essas 100 mil linhas mais rapidamente.
- Resolver o mesmo problema repetidamente é útil para memorizar padrões.
- Em 5 mil linhas de código perfeito, é possível ver todos os padrões principais. As 95 mil linhas restantes reorganizam os neurônios por meio da repetição.
Comparação com a heurística de "uma arma apontada para a cabeça"
- Para alguém que apresentou uma solução para um problema, pergunte: "Se você tivesse que terminar isso em 24 horas, como faria?"
- Esse método quebra o enquadramento e o viés de ancoragem. Muitas vezes, em poucos minutos, ele pode levar a um plano que parece poder ser concluído em um dia.
- Na prática, não é um plano que realmente possa ser finalizado em um único dia, mas a nova solução muitas vezes pode ser concluída em poucos dias.
- O objetivo desse experimento mental não é gerar a solução real, mas estabelecer um limite inferior para a solução.
Encontrando caminhos
- O ponto central é encontrar caminhos no espaço do problema. Cada caminho é uma solução, e o papel do engenheiro é encontrar o melhor caminho.
- Vale a pena pensar nas semelhanças entre essas heurísticas e vários algoritmos de busca de caminho.
- O mesmo vale para heurísticas de engenharia: tornar-se um engenheiro melhor significa encontrar caminhos melhores no espaço do problema.
Resumo do GN⁺
- Este texto explora metodologias e heurísticas eficientes no desenvolvimento de software.
- O método de "recomeçar todos os dias" e o de "escrever tudo duas vezes" são úteis para melhorar a qualidade do código.
- A resolução repetitiva de problemas ajuda no reconhecimento de padrões e na reorganização dos neurônios.
- A heurística de "uma arma apontada para a cabeça" é útil para estabelecer um limite inferior para uma solução.
- Encontrar o melhor caminho no espaço do problema é o papel central do engenheiro.
5 comentários
Ficou maluco? Isso só seria possível para gente que tem tempo de sobra; isso é algo minimamente viável na realidade?
No ambiente coreano de SI, isso seria impossível mesmo.. haha, talvez só em projeto pessoal
Essa abordagem é algo em que eu nunca teria pensado.
Acho que vou tentar haha
Concordo muito com a reescrita.
Uma vez apaguei sem querer o código em que estava trabalhando e, ao escrevê-lo de novo,
acabei levando em conta coisas que tinha ignorado no meio do caminho por preguiça de mudar o design,
e o resultado acabou sendo até melhor.
Comentários do Hacker News
Escrever uma funcionalidade duas vezes é uma boa estratégia. Mas, para desenvolvedores de negócios ou gerentes de projeto, isso pode parecer um atraso desnecessário
A pergunta "E se tiver que terminar em 24 horas?" é algo que um gerente de projeto não pode fazer
Bom código é escrito escolhendo as abstrações adequadas
Se você tiver colegas competentes, dá para mostrar o que é possível fazer em pouco tempo
Concordo com a opinião de que é bom escrever software duas vezes
Se você ainda não consegue implementar a funcionalidade depois de alguns dias, então precisa primeiro fazer a infraestrutura ou a refatoração necessária
"Em 24 horas" e "escrever tudo duas vezes" estão relacionados entre si
Esta postagem é um dos melhores "conselhos de programação"
Às vezes, é necessário deixar uma thread em segundo plano rodando para resolver um problema
A seguinte abordagem é útil