Revisão de código

Colaboração de ideias fazendo um time melhor.

Não é fácil ser criticado pelo que fazemos e pelo que nos doamos a fazer em 1/3 das nossas vidas. Como programadores, nós transformamos nosso tempo em código. Algoritmo esse que será utilizado por pessoas, mantido por pessoas, vendido por pessoas e viverá muito tempo mesmo que você não exista mais no ciclo de vida do mesmo.

Produzimos, essencialmente, texto que expressam intenções e ideias. Que resolvem problemas e modelam dados. Todas essas manipulações de conceitos abstratos tiveram um catalizador inicial pra fazer sentido: você! :)

É por isso que é tão difícil para programadores serem criticados pelas suas criações: são parte do pensamento e criação de lógica de todos nós. Mas, como esse artigo vai tentar deixar um pouco mais claro, ainda que sejam parte de nós, todo o nosso código deve ser escrito pensando em quem lerá.

Por onde começar?

Ora: do começo! O código a ser revisado.

Tomei a liberdade de fazer clone de um repositório depois de fazer a seguinte pesquisa: Eu não aguento mais! (Shoutout ao Davi Ribeiro)
E vi algumas pessoas que estavam medianamente estressadas com seus códigos. Todos sabemos: acontece com certa frequência. O escolhido da vez foi este projeto mobile.

Padronização é a alma do negócio!

Apos clonarmos o repositório e escolhermos a classe em evidência, devemos sempre olhar para os pontos iniciais da aplicação. Vou listar algumas:

• Nomes de variáveis
• Nome da classe
• Identação
• Espaços e imports inutilizados

A classe escolhida foi: orderAdd.java

Um simples import optimize já torna tudo mais legível logo nas primeiras linhas.

Por padronização, nomes de classes devem ser representadas em camel case. Cada início de palavra, é posta em maiúsculo. É possível também mudar o nome da classe para um nome melhor que represente suas responsabilidades. Mas, por não conhecer o projeto como um todo, achei melhor não mexer :)

Padronização de nomes de variáveis devem ser respeitadas. Divisão de responsabilidades também é algo muito útil para quem for ver o código. Lembre-se: A grande maioria dos devs começam lendo as classes de cima pra baixo da esquerda para a direita.

Devemos contar uma história

O código já parece bem melhor! Já passamos pelo nome dos autores (imports), nome do livro (nome da classe), nome dos personagens dessa história (variáveis) e demos uma arrumada nas margens (identação).

Agora é hora de sabermos o que o programador quis nos contar.

No android studio temos uma barra de "Structure" que nos permite ver de forma (quase) organizada como nossa classe está construída.

Toda história precisa ter um começo, meio e fim.
Em Android, temos isso bem delimitado por causa do ciclo de vida. No nosso caso, o começo da nossa história é o método onCreate.

Com os nomes escolhidos para os métodos, fica pouco inteligível qual o processo que a classe está tomando para efetuar suas responsabilidades. Vou tentar escrever como leio essa classe atualmente:

"Ok. A classe adiciona orders. Ela começa verificando os editTexts. Mas eles estão populados ou vazios? Depois escrevem nomes. Lista de nomes!
Pega a instância de uma lista, dita o comportamento do click dela e depois popula essa lista?
Onde que está a função adicionar? O que é order? Isso está confuso."

Depois de um tempo lendo a classe e reformulando sua lógica, ficou assim:

É obvio que seria bem difícil alguém fora do contexto da aplicação verdadeiramente entender os conceitos específicos. O que é uma ordem? O que é NamesLists? Isso só entendi depois de ler o código.

Diga não ao código duplicado!

Eu sei que a vontade de usar o control+c/v é grande. Copia, cola, compila, FUNCIONA! É hora, então, de arrumar.

É fácil ver que existe um padrão claro e bem definido neste bloco de código que está sendo duplicado.

Dessa maneira, tornamos a facilidade de modificar em um lugar somente e ambas as listas serem afetadas num futuro (muitas vezes proximo) muito mais fácil.

Vamos falar a mesma língua?

Como dito no início desse artigo, o nosso código não é nosso. Portanto, por uma convenção histórica, é bom que tenhamos nosso código todo em uma língua fácil que será acessível por muita gente: O inglês.

Esse refactor simples pode fazer a vida de um desenvolvedor da India entender a sua intenção em criá-lo!

Conclusão

Programar é uma habilidade como qualquer outra. É difícil no começo mas é muito fácil vermos o retorno rápido do que estamos nos propondo a fazer. Mas dificilmente vemos pessoas se destacando em qualquer área da vida sem ter essas habilidades moldadas e levadas a outro nível.

Na área de desenvolvimento, temos um processo conhecido por code review que é, literalmente, pessoas de backgrounds diferentes colocando suas experiências passadas com a intenção de fazer o seu código uma história melhor.

No fim das contas, é tudo uma sugestão. Muitas vezes é preciso saber julgar se aquela sugestão se aplica às suas necessidades e intenções ao escrever o código.

O resultado é um pull request. E dois programadores melhores!

Fiz um patch das mudanças do nosso amigo que vocês podem aplicar se quiserem ver.

Espero que tenham gostado! Feedbacks são absurdamente apreciados! Até a próxima!