Lições aprendidas (até agora) como engenheiro de software trabalhando no appear.in

Um pouco do que aconteceu de 9 nove meses pra cá. Por Walmyr Filho

O tempo voa e já estou quase completando meu primeiro ano trabalhando no appear.in, e como uma pessoa que gosta de compartilhar os aprendizados, aqui está uma lista do que aprendi trabalhando com este grande time.

1. Automatize tudo pode lhe trazer benefícios, ou ao seu time

Se você acha que automação é somente sobre testes, sem nenhum pesar lhe digo, não é. No appear.in automatizamos variados tipos de tarefas, tais como o envio de notificações sobre o status de pull requests e merges para o branch master, análise estática de código, compilação e build de código, processo de deploy, escala de infra estrutura para cima e para baixo, provisionamento de ambientes, e é claro testes automatizados nos mais diversos níveis, como unidade, integração, UI, interoperabilidade (mais no item 6), e até mesmo testes de regressão visual.

Os benefícios de automatizar o máximo que você pode são vários, mas um dos mais importantes é que você pode se adaptar e se mover rapidamente. Mesmo antes de enviar o código para o sistema de controle de versão, podemos rapidamente verificar se o código está usando os padrões definidos pelo time, por exemplo. A propósito, este é assunto para o próximo tópico.

2. Utilize regras de linting para reforçar boas práticas

Uma vez que grande parte do código que escrevemos é JavaScript, podemos nos beneficiar do ESLint para definir e reforçar que os padrões estão sendo seguidos enquanto codificando.

ESLint é uma ferramenta para identificar e reportar padrões encontrados em código ECMAScript/JavaScript. Ele faz ambas verificações de regras de linting (verificando padrões) e verificações de estilo (reforçando convenções).

Ao utilizar tal prática, mesmo com um time de mais de 10 engenheiros, conseguimos garantir que todos seguem o mesmo estilo de código, além do uso de boas práticas aplicadas em outros projetos bem sucedidos. Além disso, tal prática nos permite focar no que importa, em vez de ficar verificando sintaxe de código “manualmente/visualmente”.

Alguns exemplos de regras que reforçam boas práticas são:

• array-callback-return —reforça a declaração de return callbacks em métodos de array
• camelcase —reforça convenção de nomear (variáveis e funções) utilizando camelcase
• indent —reforça indentação consistente
• e muito mais.

No processo de code review, por exemplo, em vez de verificar sintaxe de código, o revisor pode focar na arquitetura do que está sendo desenvolvido, e então, prover feedback valioso para a resolução de tal problema de uma boa maneira. Por falar em code review, vamos ao próximo item.

3. Revisão de código é uma ótima maneira de melhorar habilidades de programação

• Movemos nossa base de código de ECMAScript 5 para ECMAScript 2015.
• Em algumas partes da aplicação, movemos de AngularJS para React.
• Éramos acostumados a ter somente testes de unidade e de integração, e agora contamos até mesmo com testes de regressão visual.

6. Testes de interoperabilidade

Como uma ferramenta de video conferência baseada em WebRTC, precisamos garantir que nosso serviço funcionada nos navegadores que suportam tal tecnologia e precisamos automaticamente testar que as funcionalidades principais da aplicação funcionam conforme o esperado em casos de uso reais, tal como a verificação de que audio e video estão sendo corretamente enviados e recebidos quando duas ou mais pessoas estão na mesma sala, por exemplo, ou que a funcionalidade de compartilhamento de tela funciona como esperado, em ambas as salas free ou premium.

Isto é possível através de WebRTC end to end tests, e temos vários casos de teste automatizados para isso.

7. Infraestrutura como código

Já ouvi falar bastante sobre infraestrutura como código antes de trabalhar no appear.in, porém nunca havia tido a real experiência de implementar infraestrutura como código e rodar em serviços na nuvem, de forma automatizada.

Muitos de nossos serviços rodam na AWS, e para criar uma instância computacional, um security group, um servidor de armazenamento de arquivos estáticos, ou qualquer outro tipo de infraestrutura, utilizamos Terraform, o que torna o processo controlado e seguro. Por exemplo, para realizar um rollback para uma versão anterior da infraestrutura em caso de uma nova mudança ter quebrado algo que já funcionava, além de vários outros benefícios, tais como revisão de código a cada mudança, visto que a infraestrutura é código como qualquer outro.

8. Trabalhe em tarefas pequenas

Uma ótima maneira de fazer progresso é trabalhando em tarefas pequenas que são parte de algo maior. Em nosso processo de desenvolvimento trabalhamos com sprints de duas semanas, e movemos em passos pequenos, um de cada vez, para atingir grande resultados.

Me lembro quando comecei a trabalhar nesse time, e em vez de quebrar minha tarefa inicial em tarefas menores, tentei fazer tudo de uma só vez. Em outras palavras, trabalhei no mesmo pull request por duas semanas, e quando era hora de fazer o merge para o branch master (após todas as verificações e o processo de revisão de código), precisei resolver conflitos, os quais levaram mais um a dois dias de trabalho.

Hoje em dia prefiro ter conquistas menores e trabalhar em pull requests pequenos, mesmo que eu precise fazer algo como parte 1 e parte 2, pois, ao menos consigo obter feedback rápido no processo de revisão de código e não tenho que me preocupar com resolução de conflitos. Isto pode ser relacionado a questão de pequenas vitórias.

9. Refatore sem piedade

É muito legal quando todos no time compreendem a importância de tornar o código melhor, para ser capaz de desenvolver um serviço de forma sustentável.

No mesmo sprint, alguns engenheiros estarão trabalhando em novas funcionalidades, outros em correções de bugs, e outros em tornar o código melhor a cada dia, através de refatoração.

É como na regra do escoteiro, onde ele deve deixar o acampamento mais limpo do que quando o encontrou. E isso também se aplica ao código, pois nos preocupamos com isso, e o fazemos pois sabemos que passamos mais tempo lendo código do que escrevendo. Além disso, nos preocupamos uns com os outros, como time.

Quebramos arquivos grandes em menores para trabalhar a separação de responsabilidades e facilitar a manutenção. No processo de revisão de código, sugerimos melhores nomes para funções e variáveis, para tornar o código mais legível, e tentamos resolver problemas complexos de maneiras simples, utilizando padrões de código sofisticados e trabalhando com arquitetura emergente.

10. Pipelines como código

Utilizamos integração e entrega contínua como parte fundamental de nosso processo de desenvolvimento de software, com ajuda de uma excelente ferramenta chamada gocd, e nela, até mesmo nosso pipelines são criados como código, o que torna o processo de criação e atualização de pipelines fácil e de baixo custo para manter.