Um guia do desenvolvedor para evitar arbustos

O desenvolvimento de software está repleto de perigos. Para qualquer tarefa de desenvolvimento, há um milhão de maneiras de fazer tudo errado, e a única maneira correta é uma trilha pequena e estreita que serpenteia silenciosamente pela floresta. É preciso experiência para conhecer o caminho e evitar as armadilhas perigosas ao longo do caminho.

A seguir está uma lista de sete lições duramente conquistadas em muitas viagens à floresta escura. É uma visão opinativa sobre o que fazer e o que não fazer ao navegar pela trilha traiçoeira de codificar um aplicativo. É muito fácil desviar-se do caminho correto, e essas noções irão ajudá-lo a permanecer no rumo e chegar com segurança ao seu destino com um mínimo de obstáculos, erros e desventuras.

Siga este conselho e evite as amoreiras.

Olhe para os dois lados antes de atravessar uma rua de mão única

No Reino Unido, conduzem no lado “errado” da estrada. Os britânicos percebem que os visitantes nem sempre estão cientes disso, porque nas faixas de pedestres de Londres há um texto pintado no chão quando você sai do meio-fio que diz “Olhe para a direita”. Sendo americano, meu hábito é olhar para a esquerda, então gostei do conselho.

Mas não consegui me livrar do hábito, então acabei olhando para os dois lados.

E percebi que olhar para os dois lados era uma boa metáfora para codificação: Proteja-se contra o impossível, porque pode acontecer. O código tem um jeito de surpreender você e definitivamente muda. Neste momento você pode pensar que não há como uma determinada variável inteira ser menor que zero, mas você não tem ideia do que algum futuro desenvolvedor maluco poderia fazer.

Vá em frente e proteja-se contra o impossível, e você nunca terá que se preocupar com a possibilidade de isso se tornar possível.

Nunca faça uma coisa fazer duas coisas

Oh cara, esta é minha implicância pessoal. Não há fim para o problema causado por uma coisa fazer mais de uma coisa.

Se você já se sentiu tentado a reutilizar uma variável dentro de uma rotina para algo completamente diferente, não faça isso. Basta declarar outra variável. Se você já se sentiu tentado a fazer com que uma função faça duas coisas dependendo de um “sinalizador” que você passou como parâmetro, escreva duas funções diferentes. Se você tiver uma instrução switch que escolherá entre cinco consultas diferentes para uma classe executar, escreva uma classe para cada consulta e use uma fábrica para produzir a classe certa para o trabalho.

Pode demorar um pouco mais de codificação, mas saiba que a complexidade criada ao atribuir mais de uma responsabilidade a uma coisa (como diria o tio Bob Martin) é apenas implorar por problemas no futuro.

Codifique em interfaces, não em implementações

É muito fácil — e muito comum — acoplar seu código a implementações específicas. Você começa com um aplicativo que faz todo o registro em um arquivo de texto. Isso funciona muito bem nos estágios iniciais, mas logo seu aplicativo estará sendo executado em várias máquinas e agora esses arquivos de texto estão por toda parte e são difíceis de rastrear e gerenciar. Você decide registrar-se em um banco de dados central e logo percebe que é um trabalho muito grande passar da gravação em um arquivo de texto para a gravação em um banco de dados.

Se você tivesse codificado seu sistema de log em uma interface. Então, quando for apresentado o problema acima, você poderia simplesmente escrever uma nova implementação da interface de registro, conectá-la e pronto! Problema resolvido!

É sempre mais fácil conectar uma nova implementação a uma interface do que extrair uma implementação profundamente acoplada, cujos tentáculos estão profundamente emaranhados em seu aplicativo.

Não tema a variável explicativa

Considere o seguinte código.

if (
  (user.age > 18 && user.hasValidID) &&
  (!user.isBanned || user.hasAppealPending) &&
  (currentDate >= event.start && currentDate <= event.end) &&
  (user.ticketsOwned < event.maxTickets)
) {
  grantEntry(user);
}

Este código é complexo e muito difícil para meu cérebro analisar. Requer que você descompacte mentalmente cada expressão booleana, acompanhando o que está acontecendo entre parênteses. É um grande incômodo e muito difícil de descobrir.

Este código é muito mais fácil de entender:

const isAdultWithID = user.age > 18 && user.hasValidID;

const isAllowedDespiteBanStatus = !user.isBanned || user.hasAppealPending;

const isEventOngoing = currentDate >= event.start && currentDate <= event.end;

const hasRemainingTicketCapacity =  user.ticketsOwned < event.maxTickets;

const qualifiesForEntry =
  isAdultWithID &&
  isAllowedDespiteBanStatus &&
  isEventOngoing &&
  hasRemainingTicketCapacity;

if (qualifiesForEntry) {
  grantEntry(user);
}

Cada uma das variáveis ​​booleanas complexas recebe um nome bom e explicativo para que a noção se um determinado usuário se qualifica para entrada ou não possa ser facilmente compreendida. Não tenha medo de fazer isso.

Erradicar implacavelmente o menor dos erros

Eu sigo essa regra religiosamente quando codifico. Não permito erros de digitação nos comentários. Não me permito nem a menor inconsistência de formatação. Eu removo todas as variáveis ​​não utilizadas. Não permito que código comentado permaneça na base de código. Se a linguagem de sua escolha não diferencia maiúsculas de minúsculas, recuse-se a permitir maiúsculas e minúsculas inconsistentes em seu código.

Cuide desse tipo de pequenas coisas e os problemas maiores cuidarão de si mesmos.

Implicitidade é má

Isso é algo que nunca entendi – por que alguns desenvolvedores veem a implicitude como uma virtude. Acho incrível que alguém opte por ser menos claro em vez de mais claro.

A implicância aumenta a carga cognitiva. Quando o código faz coisas implicitamente, o desenvolvedor precisa parar e adivinhar o que o compilador fará. Variáveis ​​padrão, conversões ocultas e efeitos colaterais ocultos tornam o código difícil de raciocinar.

Como nem sempre é possível adivinhar, eliminar a necessidade de adivinhar tornando as coisas explícitas resulta em um código melhor.

Limite o escopo tanto quanto possível

Todos sabem — ou pelo menos todos deveriam saber — que as variáveis ​​globais devem ser rigorosamente evitadas. Eles podem facilmente sair do controle, ser alterados em lugares que você menos espera e misteriosamente ter valores estranhos.

Ou, dito de outra forma, o seu âmbito é demasiado amplo. Assim, o princípio da limitação do âmbito diz que as variáveis ​​globais são proibidas.

Mas esse princípio pode ser aplicado de forma mais ampla. Limite ao máximo a visibilidade dos campos da sua turma. Use privado, se puder. Declare todas as suas variáveis ​​no último minuto se sua linguagem suportar a noção de variáveis ​​inline. Não deixe que essas variáveis ​​incômodas saiam do controle, expondo-as a lugares onde elas não deveriam estar disponíveis.

Portanto, existem algumas maneiras de garantir que seu código permaneça sob controle. Essas lições são duramente conquistadas pela experiência de fazer coisas erradas e, ainda mais prevalentes, pela necessidade de manter o código que foi escrito por pessoas que não aprenderam essas lições.

Siga esses hábitos e aquela trilha cheia de arbustos ficará muito mais fácil de percorrer.