Os 10 mandamentos do Way2Rocker para código limpo

Escrever código é tipo uma arte na Way2. Não basta funcionar, tem que ser legível, testável, de fácil entendimento e manutenção e performático. Mas calma, aqui explicamos algumas regras básicas que todo Way2Rocker segue para escrever seus códigos-fonte.

1) Escreverás testes e mais testes. E mais testes.

Na Way2 adoramos testes. Na verdade amamos testes! ❤️ Tudo tem que ser testado, e tudo significa… tudo mesmo. Por que? Pois assim temos mais segurança em refactorings e mais rastreabilidade dos impactos das nossas alterações. Quando um dev novo entra para o time (inclusive, veja nossas vagas aqui) tem segurança em fazer alterações no código, pois se uma alteração tiver consequências em algum outro ponto do sistema, os testes avisarão, além de servir de documentação do uso das classes.

2) Escreverás códigos testáveis

“A implementação está pronta, só faltam os testes”. Se faltam testes, a implementação não está pronta. Um código para passar pelo nosso code review precisa de testes, e portanto o código escrito tem de ser testável. Muitas vezes utilizamos do TDD para nos assegurar disso, pois escrevendo os testes antes do código, assim que você acaba o código, a implementação consequentemente está pronta.

3) Nomearás as variáveis decentemente

Imagine que você recebe a notícia que vai ser pai ou mãe do seu primeiro filho(a). Que alegria! Certamente vai ter um cuidado especial ao escolher um nome, certo? Você nomearia um filho seu de “temp” ou “x”? Possivelmente não. Por que? Porque um filho(a) é muito importante para você, e estará do seu lado por toda a vida. Assim como a variável que você nomeou como “temp” pra “pensar em um nome melhor depois” e ficou assim. Por anos. Dificultando a vida de quem vai dar manutenção nesse código. Tenha cuidado ao escolher o nome de uma variável ou classe. O nome tem que ser sugestivo, deixando claro seu objetivo. Nomeamos nossas classes como substantivos e nossos métodos como verbos no imperativo. Assim um repositório de medidores, no nosso querido mundo de gestão de energia elétrica certamente se chamaria “RepositorioDeMedidores”, e um método de carga de medidor por ID se chamaria “CarregueMedidorPorId()”. Não economize palavras, seu código C# vai ser compilado pra linguagem de máquina de qualquer maneira, então o sistema não vai ficar mais lento se você der nomes mais longos aos seus artefatos 😏

4) Escreverás códigos que contem uma história para os humanos do futuro

Código fonte tem que ser tratado como uma piada: se você tem que explicar, não é boa. Nomeando métodos, classes e variáveis de maneira clara você cumpre o objetivo do código fonte: contar uma história concisa, com início, meio e fim a outros desenvolvedores. Essa facilidade de entendimento do código fará com que outros devs consigam entender rápido e dar manutenção de forma mais precisa nesse código escrito, muitas vezes por nossos antepassados (código legado). E um código bem escrito deve ser bom o suficiente pra ser auto-explicativo, não precisando de comentários. Comentários devem ser tratados como notas de rodapé de um livro: elas não estão em todas as páginas pois suas dúvidas tem que ser respondidas todas pelo texto, e as notas de rodapé são utilizadas somente em momentos específicos, pra ampliar o contexto. Portanto, cuidado com o excesso de comentários no código 😉

5) Segregará responsabilidades de módulos, classes e métodos

Um dos princípios S.O.L.I.D. é o Single Responsability Principle, que diz que um módulo ou classe deve ter uma única responsabilidade. Assim nosso módulo de cadastro não tem processamento além do CRUD, nosso módulo de medição não tem cadastro, nossa classe de busca de dados de energia não faz nada além de buscar dados de energia. Com esses contextos muito bem delimitados, sabemos onde buscar por determinada funcionalidade e onde implementar cada nova feature do sistema. O nosso método que busca dados de energia de determinada grandeza vai ter seus respectivos testes somente nesse contexto. Se uma classe faz mais de uma coisa, é um indicativo de que as responsabilidades deveriam ser segregadas. Por exemplo, no caso de uma classe que envia e-mail e notifica o usuário, um nome seria EnvioDeEmailENotificacaoDeUsuario. DANGER! Esse “E” ali no meio do nome, por mais completo e sugestivo que deixe a classe, indica que ela tem mais de uma responsabilidade. Uma possibilidade de resolução dessa situação seria a divisão em uma classe “EnvioDeEmail” que poderia ter o método “EnvieEmail()” e uma segunda classe chamada “NotificacaoDeUsuario”, com um método “NotifiqueUsuario()”.

6) Usarás inversão de dependência para facilitar testes

Usando modelos mais didáticos, todo carro possui os comandos básicos de acelerar, frear, ligar e desligar, cuja instrução é enviada ao motor. Sendo assim, podemos preparar um carro para receber um motor que implemente a interface IMotor, então saberemos quais são os métodos que podemos utilizar para interagir. Além dessa garantia, nos testes podemos implementar casos de testes para verificar as dependências desses métodos. Por exemplo, com o carro desligado, podemos dar o comando de acelerar e definir qual o resultado esperado para essa ação, injetando um mock de IMotor na classe carro.

7) Escreverás código pensando em baixo acoplamento

Ainda usando o exemplo do carro do mandamento anterior, imagine que eu tenho uma classe Carro, e esse carro tem um Motor, que é instanciado no construtor da classe. Esse motor dá ao objeto Carro acesso a todos os seus métodos de funcionamento (Ligue, Acelere, Freie, Desligue), ou seja, nosso carro funciona como se espera. Mas e se eu quiser trocar o motor, tirar o motor de Ferrari e colocar um motor de Porshe?

Vou precisar de um carro novo… 😒 É pra casos como esse que sempre tentamos manter um baixo acoplamento entre as classes. E é justamente isso que nos diz o princípio “O” do S.O.L.I.D (open closed principle). Nesse exemplo existe um forte acoplamento entre o Carro e o MotorDeFerrari. Já no exemplo do mandamento #7 temos um caso de baixo acoplamento, o que significa que qualquer motor que implementar a interface IMotor é compatível com o carro. Fazendo um refactoring no nosso último modelo de carro podemos ter:

Assim podemos usar a mesma classe Carro só passando o motor que queremos como parâmetro no construtor. Dessa maneira não nos preocupamos com a implementação do Motor, pois confiamos no contrato de implementação (a interface) que nos diz quais são os métodos que todo motor que implementa aquela interface (IMotor) terá.

8) Amarás o código do seu próximo como o seu próprio

A cultura de code review está implantada no sangue da Way2. Todo código que produzimos passa por uma revisão de outro dev antes de seguir para o QA, processo esse que coloca uma camada a mais de qualidade (técnica) da implementação. Tanto revisando código quanto tendo o código revisado nos faz crescer muito profissionalmente. Sempre aprendemos algo novo nos code reviews. Temos o olhar de pelo menos mais uma pessoa sobre o nosso código, que vê coisas que nossos olhos viciados naquela solução podem não ter percebido na implementação. Discussões saudáveis são geradas, novas soluções são propostas, e conhecimento é espalhado, fazendo com que todos do time cresçam como profissionais e mantenham o código o mais limpo possível.

9) Não tratarás seu código como intocável

No nosso fluxo de trabalho não existe código intocável, ou seja, seu código não é “seu”, ele é uma parte importante do sistema, o que significa que eventualmente ele vai mudar. E isso não pode ser um problema. Não nos apegamos ao nosso código, nos apegamos ao problema que ele resolve. Em um code review, quando o reviewer dá uma sugestão, não é uma ordem, é só uma sugestão, e como sugestão ela pode ser aceita ou não. A capacidade de mudar é algo que valorizamos muito na Way2, então por que seu código seria imutável? 😃

10) Não escreverás uma Bíblia (…) em cada método ou classe

Um método com mais de 20 linhas já nos dá um indicativo de que ele poderia ser dividido em métodos menores ou até mesmo em outras classes. Muito código junto pode ser um indício de acúmulo de responsabilidades, e portanto deve ser evitado. Divisão de métodos grandes em vários métodos privados, segregando responsabilidades, é uma solução para essa situação, deixando a classe mais claramente dividida, cada método com sua única responsabilidade. Por exemplo, vamos criar um medidor de energia a partir de um nome e um número de série:

Eita, estamos validando os parâmetros de entrada e criando o medidor, tudo no mesmo método! 😱 Calma, vamos ao refactoring:

Pronto, agora cada método faz somente uma coisa, e ninguém fica sobrecarregado. 😃 Assim, quando for preciso adicionar mais uma validação nos parâmetros de entrada, sabemos que temos que alterar o método ValideCampos, e só ele.

Não, nossa vida de dev na Way2 não está restrita a somente esses 10 mandamentos, mas eles são a nossa base pra escrever um bom código. Código tem que ser pensado, estruturado, testado, e escrito com carinho 😍, afinal é esse código que você escreveu hoje que você vai deixar como legado pro seu eu do futuro, e pra outros inúmeros devs que virão a lê-lo.