Aplicando padronização para facilitar o desenvolvimento

Publicado por Paulo Casaretto no dia dev, gestão

Aqui na RD estamos crescendo num ritmo muito rápido. Com o crescimento, é natural surgirem tanto pessoas com diferentes perfis quanto projetos em diferentes linguagens e frameworks.

Com essas diferenças podem surgir problemas na troca de contexto. Um designer que está acostumado a subir um servidor de um jeito pode ter problemas para contribuir em um projeto que não usa a mesma tecnologia. Um novato que está acostumado a usar um framework de teste X pode ter receio de refatorar um código em outro projeto que usa o framework Y.

A padronização oferece uma solução interessante para reduzir o atrito na troca de projetos e permite que os desenvolvedores contribuam rapidamente mesmo que não estejam familiarizados com a “nova” tecnologia.

Usamos algumas linguagens e frameworks diferentes aqui na Resultados Digitais. Este blog, por exemplo, usa Jekyll. No RD Station usamos Rails. Em outro projeto estamos explorando Go. Num outro canto, temos um POC em Node.

Mesmo com essa diversidade precisamos garantir que todos os nossos desenvolvedores – independentemente do nível de conhecimento – possam investigar ou contribuir com qualquer projeto.

Para cumprir esse propósito temos usado um padrão que encontramos nos repositórios do Github.

./script/bootstrap

Tecnologicamente falando, o padrão é muito simples. Em cada projeto temos uma pasta chamada script e dentro dela vão arquivos executáveis que seguem uma nomenclatura comum.

Aqui estão os principais:

  • script/bootstrap - instala/atualiza dependências (gemas em uma aplicação Ruby). Exemplo no Github.
  • script/server - inicia o servidor local para rodar a aplicação (comum em projetos que são servidores web). Exemplo no Github.
  • script/test - roda os testes automatizados. Exemplo no Github.
  • script/cibuild - usado pelos servidores de integração contínua para rodar os testes Exemplo no Github.
  • script/console - abre um console Exemplo no Github.

É muito importante que cada um destes tenha apenas uma responsabilidade, o que torna possível a composição. Um dos exemplos que mais vemos, é o script/cibuild chamando ou até mesmo sendo um link simbólico para script/test.

Como os arquivos são executáveis e seguem um padrão familiar, qualquer desenvolvedor pode rapidamente subir o servidor ou rodar a suite de testes.

Mesmo sem saber todos os detalhes internos da aplicação, um designer pode com muita facilidade fazer o setup, rodar o servidor, fazer suas mudanças e ter certeza de que suas alterações não quebram os testes.

Fica claro como este tipo de padrão pode ajudar a reduzir aquele medo inicial de tocar em um repositório novo pela primeira vez.

Para saber mais sobre este padrão específico, o Github tem um post e um repositório dedicado sobre o assunto.

Paulo Casaretto

Paulo Casaretto

Full Stack Developer

Comentários