Padronizando código em seu time

Manter a organização e o padrão no código é um dos maiores desafios de um time na programação, isso porque cada um aprende de uma forma, tem seus costumes, resolve problemas da sua maneira, mas isso é saudável para um projeto? Você já sabe a resposta, não.

Pense em seu projeto como um corpo humano, cada “gambiarra” ou fuga do padrão é como se seu projeto ingerisse algo muito ruim que com o tempo irá torná-lo inoperável ou até matá-lo. A boa notícia é que temos como prevenir tudo isso com bons padrões de código e criando a cultura correta dentro do time para produzir um bom código.

Nesse post vou relatar algumas das ferramentas/técnicas que mais me ajudaram a manter uma boa organização, deixei de fora as que são relacionadas especificamente à uma linguagem, englobando apenas as que você pode utilizar em todo projeto independente da linguagem.

Design Patterns

De uma maneira simplista, os Design Patterns são formas comuns de escrever código a fim de solucionar problemas que provavelmente você irá encontrar com o crescimento do seu código. Em frameworks MVC como Rails, Laravel ou Django é muito comum vermos um mesmo tipo de estruturação de Design Patterns com Facades, Repositories, Middlewares, entre outros, tudo isso não surgiu do nada e sim para resolver um problema que mais de uma pessoa já teve e por isso conhecer os Design Patterns mais indicados para a linguagem/framework que você está utilizando é essencial.

Esses padrões vão muito além de formas de separar o código em arquivos com nomes legais, os Design Patterns são embasados em milhares de problemas que pessoas como você já tiveram e dentre elas encontraram um padrão que funciona bem.

Ferramentas

Algumas ferramentas que podem te ajudar a alcanças o padrão perfeito de escrita de código.

EditorConfig

Com certeza deve ser sua primeira opção na hora de começar a padronizar o código em um projeto, o EditorConfig gerencia as configurações do seu editor baseado em cada projeto. Está utilizando indentação com 2 espaços? Linha em branco no final do arquivo? Deixa que essa ferramenta realiza a configuração para todos os outros integrantes do time automaticamente.

Para iniciar, você deve criar um arquivo chamado .editorconfig na raiz do seu projeto e dentro dele vamos começar a especificar as regras:

root = true
[*]
indent_size = 2
insert_final_newline = true
end_of_line = lf
charset = utf-8

• root: Define se esse é o arquivo principal do EditorConfig (você pode ter mais arquivos em pastas);
• [*]: Define quais arquivos vão sofrer essa configuração, no caso estou repassando todos (você pode definir por exemplo: */.js ou até lib/*.php;

As outras configurações representam o tamanho de indentação, linha em branco no fim do arquivo, tipo de quebra de linha e charset respectivamente. Você pode encontrar uma lista de configurações possíveis aqui.

Agora instale a extensão no seu editor de preferência e pronto, todos que tiverem também a extensão e abrirem seu projeto estarão com o editor configurado exatamente da mesma forma que você.

Vagrant/Docker

“Funciona na minha máquina”.

A fim de evitar que essa frase seja repetida pelos programadores essas ferramentas surgiram para garantir que o ambiente de desenvolvimento entre todo o time e até o servidor estejam iguais, assim todos terão as mesmas funcionalidades disponíveis da linguagem, atualizações, etc.

• Vagrant: Fácil de configurar, ótimo para quem está iniciando (vídeo para quem quer começar: https://www.youtube.com/watch?v=gx50Kv6-2KA)
• Docker: Utilize principalmente se tiver seu processo de build automatizado, vai ajudar bastante.

Fluxo de desenvolvimento

Técnicas que podem ser utilizadas durante o fluxo de desenvolvimento de um projeto a fim de evitar fugas do padrão.

Code Review

Uma das técnicas geralmente desprezada pelos times mas provavelmente a mais eficaz. Code review significa basicamente revisar o código, mas quem? Eu mesmo? Na verdade não. A ideia é que toda vez que um desenvolvedor terminar uma feature e for integrá-la ao projeto, o seu código passe por uma revisão por pelo menos outro desenvolvedor do time.

Apesar de parecer complicado gerenciar esse fluxo de desenvolvimento, uma ferramenta de controle de versão como o Git, unida ao poder do Github e suas Pull Requests, pode tornar tudo isso muito menor custoso.

A ideia é que com esse processo você garanta que seu time esteja de acordo com as alterações de código evitando surpresas indesejadas.

Algumas equipes avaliam o código pelo número de WTF’s (What the f#ck) por minuto que você fala ao abrir o código do seu colega ?

Pair programming

Técnica utilizada em metodologias ágeis como a XP que consiste em dois programadores escreverem código ao mesmo tempo, no mesmo computador, um ao lado do outro. Com dois teclados? Não, um de cada vez. Enquanto um programa o outro analisa se faria da mesma forma e voltamos ao antigo ditado onde duas cabeças pensam melhor que uma.

Os programadores devem ficar com o monitor ao meio e nunca haver um “principal”.

Calma, esse processo não precisa ser direto, você pode fazer sessões de Pair Programming afim de alinhar os conhecimentos e técnicas utilizadas pelos desenvolvedores da sua equipe e a tendência é que com o tempo o time fique alinhado precisando cada vez menos estar um ao lado do outro.

Projeto no meio do caminho

Pegou um projeto no meio do caminho que não segue nada disso acima? Nesse caso, tente encontrar o padrão de quem desenvolveu essa aplicação (se existir) e continuar seguindo o mesmo padrão, isso porque pior que não seguir os padrões indicados é tornar esse projeto um frankenstein com vários tipos de padrões diferentes.

The end

Então antes de iniciar seu próximo projeto, esteja atento a esse post e aplique todas técnicas e ferramentas que repassei aqui. Mas lembre-se:

Não existe técnica, não existe ferramenta, não existe metodologia se não existir cultura.

Não esquece de deixar as palmas e um comentário do que achou do post ?