Preferência por código descartável em vez de documentos de design

• Imaginamos que o desenvolvimento de software siga um fluxo limpo e organizado

  • Escrevemos um documento de design e implementamos funcionalidades liberando pequenas mudanças via PR
  • O histórico do Git parece limpo e bem organizado
  • Mas a realidade é diferente

• A diferença entre o documento de design e a implementação real

  • Implementar exatamente o que está no documento de design é uma ilusão
  • Quando começamos a programar, acabamos alterando o conteúdo do documento de design
  • Planos não sobrevivem ao contato com o inimigo

• Nova metodologia de design: imersão em código

  • Usar PRs em rascunho para implementar protótipos
  • Receber feedback cedo e ajustar a abordagem
  • Documentar PRs em rascunho como registros históricos das ideias de design
  • Estar preparado para descartar completamente um PR em rascunho
  • A partir do PR em rascunho, avançar gradualmente com PRs em etapas
  • Testar cada PR por etapas e reforçar sua robustez

• A importância da maturidade

  • É importante ter a capacidade de descartar ideias que você já codificou
  • O mais importante não é a quantidade de linhas de código, mas a transmissão do conhecimento organizacional
  • Alinhar cedo os pontos importantes para que o trabalho de prototipagem não seja desperdiçado

• Como usar PRs como documentação

  • PRs são uma das melhores formas de documentação para desenvolvedores
  • PRs são artefatos históricos que refletem o estado de um momento específico
  • Documentos de design frequentemente fornecem informações diferentes da realidade

• A importância dos protótipos

  • Um protótipo vale mais do que 1.000 documentos de design
  • Para impulsionar mudanças, é preciso fazer isso com código, não com documentos
  • A organização deve enxergar protótipos não como respostas, mas como perguntas

• A utilidade dos documentos de design

  • São úteis para organizar e arquivar feedback de diferentes partes interessadas
  • São úteis quando a ideia é conceitual demais ou de longo prazo
  • São úteis quando expressar a ideia por escrito é mais eficiente do que codificando
  • São úteis quando a organização não tem a disciplina de descartar a primeira solução
  • Oferecem um ambiente em que profissionais juniores podem questionar com segurança as ideias de desenvolvedores seniores

• Uso inadequado dos documentos de design

  • São usados para desacelerar o processo para desenvolvedores menos experientes
  • São usados como documentação, mas rapidamente ficam desatualizados
  • Tentam resolver todos os problemas de design, mas os problemas reais são descobertos ao programar

• Se a equipe tiver disciplina, hackear é muito mais eficiente do que projetar

  • Recomenda-se criar essa disciplina dentro da organização
  • No fim, o código tem muito mais força do que as palavras

[GN⁺]

Opiniões do Hacker News

• Prototipagem é uma parte importante do processo de design, e é necessário definir o problema e deixar clara a solução

  • Às vezes um documento simples já basta, mas em outros casos é preciso muito feedback e várias iterações
  • Existe o ditado: "algumas semanas de código podem economizar algumas horas de planejamento"

• Escrever é útil para explorar o problema, e houve a experiência de achar que o problema estava entendido, mas novas perguntas surgirem durante a escrita

  • Isso lembra um caso em que um mentor usou o Lucidchart para explicar seis meses de trabalho

• Houve experiência em usar soluções temporárias para concluir um projeto dentro do prazo

  • A solução temporária também é usada como ferramenta de suporte à produção e serve como caminho alternativo caso a versão permanente seja descontinuada

• O maior problema dos documentos de design é que ninguém os lê

  • O problema da prototipagem é que as pessoas a consideram como código final
  • Há preferência por uma abordagem híbrida, com planejamento e documentação bem feitos, além de código de protótipo com qualidade suficiente para ser usado no produto final

• A diferença entre feedback sobre código e sobre design é grande

  • Documentos de design induzem a pergunta do "por quê" sobre o espaço do problema
  • Quando o protótipo funciona, fica mais difícil levantar esse tipo de questão

• Se a descrição do trabalho é escrever muito código para ver o que funciona, o GPT pode substituir isso de forma mais rápida e barata

  • Conseguir consenso sobre o que deve ser construído é sempre o desafio

• Quase ninguém imagina que o desenvolvimento de software siga um fluxo limpo e organizado

  • Escrever código é parecido com escrever texto: o rascunho é sempre ruim, e um bom texto passa por muitas revisões

• Já houve casos em que o código ficou empilhado como um Jenga, de modo que ninguém quer mexer nele

• Há preferência por um processo que documenta decisões de design usando uma thread contínua de comentários

  • Esse processo é feito com GitHub Issues

• Ainda há reflexão sobre essa abordagem, e no pior caso muito tempo pode ser desperdiçado

  • Escrever documentos de design foi mais útil quando o problema foi pensado o suficiente para especificar as propriedades necessárias para uma implementação correta
  • Implementar soluções parciais e melhorá-las gradualmente também teve sucesso