O que eu aprendi de fazer 1000 comentários de código

Ao trabalhar no LinkedIn, uma grande parte do meu trabalho envolveu fazer revisões de código. Havia certas sugestões que continuavam chegando repetidas vezes, então eu decidi coletar uma lista que eu compartilhei com a equipe.

Aqui estão as sugestões de revisão de código 3 (+1 bônus) mais comuns.

Sugestão 1: Lance uma exceção quando as coisas dão errado

Um padrão comum que eu vi é o seguinte:

Esse padrão realmente causou uma interrupção em um dos aplicativos móveis em que trabalhei. O backend de pesquisa que estávamos usando começou a lançar exceções. No entanto, o servidor da API do aplicativo tinha algum código semelhante ao acima. Portanto, da perspectiva do aplicativo estava recebendo uma resposta bem sucedida de 200 e mostrou uma lista vazia para cada consulta de pesquisa.

Se, em vez disso, a API tivesse lançado uma exceção, nossos sistemas de monitoramento teriam apanhado isso imediatamente e seria corrigido.

Há muitas vezes em que pode ser tentador apenas retornar um objeto vazio depois de ter detectado uma exceção. Exemplos de objetos vazios em Java são opções opcional.empty (), null e empty. Um lugar onde isso ocorre o tempo todo é na análise de URL. Em vez de retornar nulo se o URL não puder ser analisado a partir de um String, pergunte a si mesmo: "Por que o URL está mal formado? Este é um problema de dados que devemos consertar a montante? ".

Objetos vazios não são a ferramenta certa para este trabalho. Se algo é excepcional, você deve lançar uma exceção .

Sugestão 2: use o tipo mais específico possível

Essa sugestão é basicamente o oposto da programação com caracteres rígidos .

Muitas vezes vejo código como esses exemplos:

O uso do tipo mais específico possível permite que você evite toda uma classe de bugs e, basicamente, é a razão inteira para escolher o idioma fortemente digitado, como Java, em primeiro lugar.

Então, agora, a questão é: como os programadores bem intencionados acabam escrevendo um código incorreto de código rígido? A resposta: porque o mundo externo não está fortemente digitado. Há uma série de lugares diferentes de onde as cordas são originárias, tais como:

  • Parâmetros de consulta e caminho em URLs
  • JSON
  • bancos de dados que não suportam enums
  • bibliotecas mal escritas

Em todos estes casos, você deve usar a seguinte estratégia para evitar esse problema: mantenha a análise e serialização das cordas nas franjas do seu programa . Aqui está um exemplo:

Isso confere uma série de vantagens. Os dados malformados são encontrados imediatamente; O aplicativo falha cedo se houver algum problema. Você também não precisa manter a captura de exceções de análise em todo o aplicativo uma vez que os dados foram validados uma vez. Além disso, tipos fortes possibilitam assinaturas de métodos mais descritivos; você não precisa escrever tantos javadocs em cada método.

Sugestão 3: use opções em vez de nulos

Uma das melhores características para sair do Java 8 é a classe Optional que representa uma entidade que poderia razoavelmente existir ou não existir.

Questão Trivia: qual é a única exceção para ter seu próprio acrônimo? Resposta: uma NPE ou uma Exceção de Ponteiro Nulo. É, de longe, a exceção mais comum em Java e foi referido como um erro de bilhões de dólares .

Optional permite que você remova completamente os NPEs do seu programa. No entanto, ele deve ser usado corretamente. Aqui estão alguns conselhos em torno do
uso de Optional :

  • Você não deve simplesmente chamar .get() sempre que você tiver um Optional para usá-lo, em vez disso, pense cuidadosamente sobre o caso em que o Optional não está presente e apresenta um valor padrão sensível.
  • Se você ainda não tiver um valor padrão sensível, métodos como .map() e .flatMap() permitem que você adie essa decisão até mais tarde.
  • Se uma biblioteca externa retorna null para indicar o caso vazio, envie imediatamente o valor usando Optional.ofNullable() . Confie em mim, você vai se agradecer mais tarde. Os nulos tendem a "fazer bolhas" dentro de programas, então é melhor pará-los na fonte.
  • Use Optional no tipo de retorno de métodos. Isso é ótimo porque, então, você não precisa ler o javadoc para descobrir se é possível que o valor não esteja presente.

Sugestão de bônus: métodos "Desbloquear" sempre que possível

Você deve tentar evitar métodos que se parecem com isto:

O que todos os métodos de evitação têm em comum? Eles estão usando objetos de contêiner como Opções, Lista ou Tarefa como parâmetros do método. É ainda pior quando o tipo de retorno é o mesmo tipo de contêiner (ou seja, um método de um param toma um opcional e retorna um opcional).

Por quê?
1) Promise<A> method(Promise<B> param)
é menos flexível do que simplesmente ter

2) A method(B param) .

Se você tem uma Promise<B> então você pode usar 1) ou pode usar 2) "levantando" a função com .map . (ou seja, promise.map(method) ).

No entanto, se você tem apenas B, então você pode usar facilmente 2), mas você não pode usar 1), o que faz 2) a opção muito mais flexível.

Eu gosto de chamar isso de "destravar" porque é o oposto do método comum de utilidade funcional "levantar". A aplicação dessas reescritas torna os métodos mais flexíveis e fáceis de usar para os chamadores.

Veja também

Confira meu outro artigo sobre "Programação Funcional Prática": https://hackernoon.com/practical-functional-programming-6d7932abc58b

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *