A pegada de uma funcionalidade

Ser dono de uma funcionalidade de ponta a ponta começa por saber quão grande uma funcionalidade é. Não em linhas: em lugares que você precisa tocar, e lugares que podem quebrar sem você notar.

Contando o Partners

A funcionalidade de parceiros nesta aplicação. Logos de patrocínio no roadmap, cartões de vagas, um formulário de contato, um CRUD administrativo e, desde que este curso foi escrito, uma API de parceiros, webhooks assinados, um handoff de login e uma tela de consentimento do aluno. Aqui está tudo que ela é.

$ find app -path '*partners*' -type f | wc -l
70

Cerca de cem arquivos: setenta em app/, vinte e sete em spec/, nove migrações. E essa contagem deliberadamente exclui o que não é arquivo. As chaves de idioma em duas línguas, o anexo do Active Storage, as filas em que os jobs rodam, e o que quer que a página do roadmap faça com a TrackSponsorsQuery.

flowchart TB
  F["uma funcionalidade: Partners"] --> M["8 models"]
  F --> C["9 controllers, 4 deles uma API"]
  F --> Q["11 consultas"]
  F --> S["9 serviços"]
  F --> J["4 jobs"]
  F --> ML["1 mailer, 2 templates"]
  F --> V["19 views"]
  F --> T["27 arquivos de spec, 9 migrações, 6 rotas"]
  F --> N["e: chaves de idioma, storage, filas, uma página pública"]

Por que a contagem importa

Porque o instinto quando alguém diz "eu pego o trabalho do logo de parceiro" é imaginar o objeto de serviço. E o objeto de serviço é um arquivo de cerca de cem.

Cada uma dessas camadas é um lugar onde a funcionalidade pode ficar pela metade. Uma consulta acrescentada e nunca chamada. Uma chave de idioma numa língua só. Uma migração que rodou em desenvolvimento e não em produção. Um job que enfileira e silenciosamente não faz nada. Uma parcial de view com uma guarda de nil que ninguém precisou até o dia em que precisou.

Ser dono significa a coluna inteira, não o arquivo interessante do meio.

Onze consultas

Olhe aquela linha de novo. Onze objetos de consulta para uma funcionalidade: ActivePartnersQuery, TrackSponsorsQuery, CourseSponsorQuery, HiringQuery, quatro atrás da API de parceiros, e três de admin.

Duas coisas decorrem desse número.

O lado de leitura é maior que o de escrita. Sete dos nove serviços escrevem; onze consultas leem. Isso é normal e raramente antecipado, e é por que "adicionar um campo em parceiros" nunca é um arquivo. Toda consulta que devolve parceiros pode precisar saber dele.

Alguém já fez a sua pergunta. Antes de adicionar uma décima segunda consulta, o primeiro passo honesto é ler as onze. Essa é a fonte mais comum de trabalho duplicado numa funcionalidade com pegada existente, e custa dez minutos evitar.

As camadas que são esquecidas

Das onze linhas, quatro são as que ficam pela metade, e são as mesmas quatro toda vez:

Chaves de idioma. A funcionalidade funciona na língua em que você desenvolveu.

O template de texto do mailer. A versão HTML recebe atenção; a de texto puro é renderizada por um cliente que você não usa.

O caminho de falha do job. Ele enfileira, então parece pronto.

O formato da migração em produção. Ela rodou num banco de desenvolvimento com quarenta linhas.

As aulas 4 e 5 são sobre essas quatro, porque é onde "terminei a funcionalidade" e "a funcionalidade funciona" se separam.

A definição

Ser dono de ponta a ponta significa: você conhece toda entrada, toda forma de falhar, e como descobriria que parou de funcionar.

Três orações. A aula 2 é a primeira, as aulas 3 e 4 são a segunda. E a aula 5 é a terceira, que é a que ninguém é dono por padrão.

Pontos-chave

• A funcionalidade Partners são cerca de cem arquivos em onze camadas, mais chaves de idioma, storage e filas.
• O objeto de serviço que todos imaginam é um arquivo de cerca de cem.
• Onze consultas leem, sete serviços escrevem: o lado de leitura é maior e raramente antecipado.
• Antes de adicionar uma consulta, leia as onze que existem; é a fonte mais comum de trabalho duplicado.
• Ser dono de ponta a ponta: você conhece toda entrada, toda forma de falhar, e como descobriria que parou.