2 pontos por GN⁺ 2024-08-06 | 1 comentários | Compartilhar no WhatsApp
  • Falei sobre como escolher programas que possam ser usados por muito tempo e como construir uma infraestrutura confiável, mas reconheço que ainda não faço isso bem
  • No último mês, reescrevi o núcleo de um programa que venho usando há 2 anos e, com isso, refleti sobre as mudanças na minha forma de programar ao longo da vida

2015

  • Desconfiava de abstrações e dava grande importância a testes e controle de versão
  • Achava que o abuso de abstrações e a falta de testes/controle de versão eram a causa dos problemas
  • Projetei a plataforma Mu1 com testes e camadas como restrições básicas

2017

  • Comecei a retrabalhar o Mu1 para chegar ao Mu atual
  • No começo, usei todas as novas ideias de testes e camadas, mas aos poucos deixei de usá-las
  • O Mu tem muitos testes, mas no estilo antigo, e a infraestrutura de camadas não foi portada

2022

  • Comecei a trabalhar em Freewheeling Apps
  • No início, comecei sem testes, depois escrevi testes minuciosos para a parte central do editor de texto
  • O restante era difícil de testar, mas funcionava bem

2024

  • Há um mês, apaguei todos os testes
  • Retrabalhei radicalmente o editor de texto de uma forma que antes me faria preocupar com conflitos de merge com outros Freewheeling Apps
  • Parei de me preocupar com controle de versão
  • Abandonei testes e versões e acabei criando um programa muito melhor

Visão unificada atual sobre programação sustentável

  1. Construir de forma sustentável para muitas pessoas é difícil demais, então é melhor nem tentar
  2. A maior parte do software está contaminada por incentivos para servir muita gente no curto prazo. Foque em software com poucos logotipos, fácil de construir, com poucas dependências e sem atualizações automáticas
  3. Pequenas mudanças de contexto podem alterar radicalmente o quanto um programa se encaixa bem nesse contexto
  4. Programas novos inevitavelmente avançam em direção ao desconhecido de alguma forma. Muitas vezes, não sabemos exatamente o que estamos fazendo em nenhuma direção
  5. Tipos, abstrações, testes, versões, máquinas de estado, imutabilidade, análise formal etc. são ferramentas que podem ser usadas em terreno desconhecido
  6. Inevitavelmente, algumas dessas ferramentas acabam sendo usadas em excesso. A quantidade ideal é muito menor do que imaginamos. O uso excessivo é dívida técnica
  7. Quando a compreensão do contexto se estabiliza, vale a pena descartar boa parte do programa e recomeçar do zero
  8. Antes de reescrever, é preciso colocar de uma vez na cabeça tudo o que você quer do programa e todos os cenários com que ele precisa lidar
  9. Construa tudo de uma vez
  • Testes e controle de versão atrapalham chegar ao final dessa evolução
  • Testes fazem você esquecer suas preocupações, e controle de versão faz você se apegar ao passado

Opinião do GN⁺

  • Se um programa ficar complexo demais, pode se tornar impossível lembrar de tudo no passo 8. Isso se aplica à maior parte do software, especialmente ao software escrito por mais de uma pessoa
  • Nem todo software precisa necessariamente chegar ao passo 9. Muitos Freewheeling Apps são simples o bastante e evoluem devagar o bastante para se estabilizarem sem bugs mesmo com apenas algumas pessoas usando, independentemente das escolhas iniciais de design
  • O design orientado a dados é claramente útil para chegar ao passo 9. Não é uma ferramenta para aplicar às cegas, mas uma forma de pensar que olha para o panorama geral de como o programa acessa dados, além das escolhas imediatas de estruturas de dados
  • Esses passos podem não estar totalmente certos. Talvez haja uma subestimação de ferramentas com as quais se tem menos experiência
  • Fico me perguntando que etapas podem existir além dessas

1 comentários

 
GN⁺ 2024-08-06
Comentários do Hacker News
  • Sem testes, você não vê os problemas, então parece que eles desapareceram

    • Sempre encontravam bugs quando faziam testes
    • Apagar os testes é enganar a si mesmo
    • Depois de ler a página, ficou a impressão de que a pessoa está cansada de gerenciamento de alterações/configuração
    • É preciso ter muitos usuários para ganhar dinheiro
  • Ao abrir mão de testes e versionamento, acabou obtendo um programa melhor

    • Em 2024, é difícil entender não usar controle de código-fonte
    • Trabalhar em vários dispositivos, ver o histórico, fazer rollback e criar branches é muito útil
  • No começo acharam que o autor estava errado, mas há bons insights

    • Esse workflow funciona bem para o autor
    • Ele provavelmente teve experiências em que Git ou testes automatizados reduziram a produtividade
    • Também existem alternativas simples, como Dropbox e FTP
    • O autor gosta de criar programas pequenos
    • Testes automatizados são úteis, mas no caso dele talvez o valor não apareça
  • Controle de versão e testes automatizados resolvem problemas reais

    • Hoje em dia, começar um projeto sem controle de versão é loucura
    • Testes automatizados são uma prática recomendada
    • No caso de uso específico do autor, isso pode ser razoável
  • Ao escrever/refatorar programas grandes, é importante escrever, descartar e reescrever

  • Este artigo é confuso

    • Fica a dúvida de por que foi o primeiro a receber tantos upvotes
  • Pequenas mudanças podem alterar muito a adequação de um programa

    • Há o exemplo do K9 Mail
    • O K9 Mail começou com uma UI não tradicional
    • Muitos usuários reclamaram da nova UI
    • Uma pequena mudança destruiu a adequação do app
    • A pessoa ainda usa a versão antiga
  • Fazer software sozinho e em equipe são coisas completamente diferentes

    • Testes são um meio, não um fim
    • Quando há confiança, faz-se menos testes
    • Adicionam testes de integração nas partes importantes
    • Testes unitários são úteis para desenhar novas APIs
  • Em 2022, começou o trabalho no Freewheeling Apps

    • A falta de testes causava frustração
    • A suíte de testes dava confiança para evoluir o sistema
    • Quando a complexidade funcional aumenta, testar fica mais difícil
    • Em 2024, todos os testes foram apagados
    • Essa filosofia só se aplica a uma única pessoa
  • Não concordam que pequenas mudanças possam alterar muito a adequação de um programa

    • O curto-prazismo serve para se adaptar a pequenas mudanças
  • Gostam do autor e gostam do projeto Mu

    • É uma Lisp machine moderna
  • Sentem-se sobrecarregados com a complexidade da engenharia de software

    • Rejeitar todas as ideias não é a solução
    • É preciso escrever testes, usar VCS e usar abstrações
    • Deve-se saber por que se usa cada coisa e, se não houver motivo, reavaliar