Revisão de Código para o Solo Dev

Periklis Gkolias Blocked Desbloquear Seguir Seguindo 31 de dezembro de 2018

Vou começar este artigo, como fiz com o anterior da série.

Nada pode substituir uma grande equipe. Mas um verdadeiro guerreiro tem que poder confiar em si mesmo se necessário.

Algumas pessoas hoje em dia, trabalham em uma equipe de um.

Pessoas que são especialistas no assunto e as melhores em seus campos (e eu sou o último humano na terra que pode dar-lhes conselhos profissionais).

As pessoas que acabaram de fundar, sozinhas, a própria empresa (ou os parceiros da empresa não são técnicos).

Ou pessoas que trabalham sempre remotamente, e em um fuso horário muito diferente do da matriz, onde obter ajuda de outros colegas pode ser difícil.

Revisão de código, o marco da qualidade mínima de software aceitável

Como Jeff Atwood (o fundador do StackOverflow) aponta em seu artigo Code reviews: Just do it

Acredito que as revisões de código peer são a única grande coisa que você pode fazer para melhorar seu código. Se você não está fazendo revisões de código agora com outro desenvolvedor, está perdendo muitos bugs em seu código e se enganando em algumas oportunidades importantes de desenvolvimento profissional. Tanto quanto eu estou preocupado, meu código não é feito até que eu tenha superado isso com um colega desenvolvedor.

Se um engenheiro tão experiente e bem-sucedido apoiar com ousadia a importância da revisão de código, mesmo se você discordar, é preciso pelo menos tentar.

Vamos seguir em frente com as áreas mais importantes, na minha opinião, que o engenheiro solo deve se concentrar, durante a revisão de seu próprio código.

As compilações automatizadas e os testes de automação passam sem falhas?

Você também não tem? Muito ruim, não há desculpas, dado que os serviços como gitlab e bitbucket oferecem serviços gratuitos de CI hoje em dia. E também não há desculpas, uma vez que os testes de unidade são mais fáceis do que nunca para escrever, dada a simpatia dos frameworks de testes unitários onipresentes.

Caso você tenha os dois e o Papai Noel trouxe um presente por ser bom, falhando em qualquer um dos processos automatizados, deverá soar muitos sinos. Mas se não, não é um sinal para resolver.

Você já escreveu novos testes?

Não? Mesmo? Estou tão decepcionado. 🙁

Vou citar um parágrafo do guia de contribuição do Django

Quando dizemos “PEP 8 e deve ter docs e testes”, queremos dizer isso. Se um patch não tiver docs e testes, é melhor que haja um bom motivo. Argumentos como "Eu não consegui encontrar nenhum teste existente deste recurso" não têm muito peso – embora possa ser verdade, isso significa que você tem o trabalho extra-importante de escrever os primeiros testes para esse recurso, não que você obter um passe de escrever testes completamente.

TDD é difícil, mas ter testes de unidade e código testável tem enormes benefícios.

Pense em como seu código pode afetar a funcionalidade existente (regressão)

Esta é uma área onde ter uma ótima suíte de testes irá salvar sua bunda um dia. Isso sempre depende da cobertura que você tem em sua suíte e, dado que a maioria das pessoas tem menos de 100%, sua intuição e seu pensamento analítico serão de grande ajuda aqui.

As diferenças são sensatas?

Dê uma olhada usando qualquer ferramenta de comparação, para ver se as mudanças feitas fazem sentido.

Se você está trabalhando em um problema de segurança, é necessária uma mudança no foo.css? Se você quiser melhorar um formulário, você precisa alterar três arquivos de configuração?

Provavelmente não. Seja vigilante, quando se trata de diffs e ele vai pagar de volta. Finja que alguém lhe pergunta, por que você mudou uma linha específica e esteja pronto para explicar completamente ao seu amigo fantástico.

Execute uma análise de segurança

Você introduziu algum furo de segurança acidentalmente? E eu quero dizer coisas óbvias, como passar uma entrada não higienizada para o banco de dados. Há uma abundância de verificadores estáticos de segurança em torno de você pode escolher os que se encaixam mais ao seu trabalho.

Além disso, verificar se nenhuma informação sensível está sendo registrada é crucial.

Por exemplo, se o software for implantado em uma empresa compatível com PCI-DSS, nenhum número de cartão deverá ser registrado. E é muito fácil esquecer isso, enquanto registra todos os argumentos de uma função.

Falando de logging, você está (under | over) logging?

Under-logging fará com que você rasgue seu cabelo quando um bug furtivo vier à tona. Especialmente se você registrou alguns incidentes ao redor da área afetada.

O excesso de registro pode retardar seu código, aumentar exponencialmente o tamanho dos arquivos de log e fazer com que você procure uma agulha no feno quando a inspeção é necessária.

Minha sugestão é usar níveis de log, onde o padrão pode ser facilmente alterado. Nesse caso, você pode aumentar a saída de registro ao investigar um problema e ter logs mais claros quando não o fizer. A menos que o estado de investigação seja muito mais frequente do que o estado de funcionamento sem falhas.

O código está cuidando de casos extremos e parâmetros inválidos?

O que acontecerá no seu sistema se a rede cair no meio de uma grande atualização de banco de dados ou se eu lhe der meu nome como meu telefone?

Isto é um pouco sobreposto com as verificações de segurança estabelecidas acima.

Você atualizou os tickets, a documentação e os changelogs?

Não é realmente um requisito funcional, mas necessário se o software em que você está trabalhando não for para uso pessoal (mesmo assim, é útil manter o controle de suas ações).

Geralmente, isso inclui o seguinte:

  • Feche o ticket no rastreador de problemas e adicione o link de solicitação pull / link de comparação completo, se não for feito automaticamente (por exemplo, integração Jira-bitbucket)
  • Feche o pedido de pull, se você estivesse trabalhando em uma filial (altamente recomendado mesmo para equipes solo)
  • Atualize o changelog
  • Se necessário, altere os documentos da API / usuário e envie-os para os usuários

Mais alguns pontos que valem a pena considerar

  • O código está em conformidade com os padrões da empresa? Mesmo que seja uma empresa solo, onde você é o dono? Código sujo é tentador às vezes.
  • Se você mudou uma função, lembrou-se de alterar seus comentários?
  • Uma expressão complexa e valores mágicos podem ser extraídos para uma função (n) (inline) e uma constante, respectivamente
  • As novas classes / funções possuem documentação adequada?
  • Os pacotes / classes / funções / variáveis possuem nomes significativos?
  • Você acidentalmente comentou código ou código duplicado, o que polui a legibilidade?
  • Se o seu novo código for exposto a enormes volumes de dados ou o tráfego será dimensionado? Há alguma vitória rápida para melhorar a situação?
  • Você será capaz de trabalhar com essa funcionalidade em dois anos, sem perder muito tempo se familiarizando?

Por último, mas não menos importante, é muito mais difícil se você fizer sozinho

Assim como nos testes, é difícil julgar a si mesmo e isso é comum na maioria dos humanos.

Durante os últimos anos, há serviços em que as pessoas dão uma segunda olhada no seu código, como pullrequest . Eu não tentei o serviço, mas parece uma boa idéia quando estar sozinho é a única escolha e as apostas são altas.

Isso é tudo, pessoal

Obrigado por tomar o tempo para ler este artigo, espero que tenha gostado. No caso, você tem uma abordagem diferente para rever o código, por favor, compartilhe sua sabedoria.

Desejando-lhe tudo de melhor para o ano que está chegando.