Três meses na Resultados Digitais Dia 23 completei três meses na Resultados Digitais.
Três meses que moro em floripa. Três meses que aprendi a adorar o clima litorâneo.
Estou muito feliz por estar aqui. A vida na praia tem um clima diferente. Incrivelmente me sinto mais livre aqui.
O trabalho também está sendo muito legal, e este post é mais uma reflexão sobre como está sendo minha vida na Resultados Digitais.
Team A
Faço parte de um Team “A” e estou aprendendo muito com eles. Estou gostando de fazer parte de uma equipe maior, estamos em mais de 30 pessoas em 6 equipes. Então sempre é possível aprender mais e ver uma ótica diferente de outros programadores.
Dentro dos times, faço parte de uma equipe que fica mais focada nos problemas de performance e escalabilidade do produto. Está sendo uma experiência incrível para mim, pois estou tendo desafios bem diferentes dos que tive antes em outras aplicações. Até escrevi no blog do shipit sobre algumas dicas para migrações eficientes com ActiveRecord.
Out teach
Outra coisa muito massa aqui na RD é o incentivo para aprender e ensinar. Out teach é um valor do código de cultura da RD, e isso possibilita estar sempre aprendendo em workshops e palestras internas.
Também somos muito incentivados a participar de eventos e compartilhar nossos conhecimentos publicamente. Eu tive o prazer de palestrar com o @andrehjr no TDC aqui em floripa. Foi muito legal, pois, além de nós, os RDevs deram 7 palestras em 5 trilhas além de participar do evento.
Code Review
Falando em ótica diferente, estou apaixonado pela prática do code review. Code review pra mim é uma consultoria particular especializada para me fazer um programador melhor.
Cada vez que recebo um feedback num pull request aprendo a ser um programador melhor.
Cada vez que encontro um problema ou tenho uma ideia para dar no código dos outros devs dou um feedback.
Esse processo se torna muito legal pois você aprende e ensina diariamente. Além de poder expor ideias ou mesmo alertar sobre possíveis falhas e inconsistências.
O code review tem valor se for feito com muita atenção e alto nível de criticidade. Existem muitos detalhes ou complexidades do código que podem tornar a revisão difícil e demorada. Porém uma revisão eficiente pode melhorar o algorítmo e o programador em vários níveis e o produto também, que tal?.
Esses dias achei muito legal que em um feedback de release escutei o @joaohornburg falando: “vamos começar desconfiar de pull requests que forem revisados e não encontrarem nenhum problema”. Em outras palavras, sempre é possível melhorar.
Pra mim o code review tem sido uma das experiências mais valiosas e interessantes tanto para a minha melhora contínua quanto para maior qualidade nas entregas. Esse é o recado: Pratique code review ;)”
Pair programming
Pair programming é a prática de programar em par, usando um computador para dois programadores. Eu gosto muito deste formato de interação para construção de código pois sempre sai um código melhor. Sempre é possível planejar e executar ideias melhores em dois do que sozinho.
Fazendo uma correlação com o tópico anterior, observei que mesmo fazendo pair programming, que já ajuda muito para construir um código melhor, o code review tem um papel diferente e que muitas vezes pode trazer novidades e melhorias que os 2 devs não enxerguem.
Estou pareando bastante nos últimos dias. Isso me deixa muito feliz pois gosto muito de conversar e trabalhar em conjunto nas ideias. Além de poder passar e receber mais conhecimento. Sempre aprendemos tricks que agilizam o flow com as ferramentas dos coleguinhas.
Dentre as principais mudanças que aconteceram no meu flow de desenvolvimento depois que entrei na RD, as mais legais que aprendi com a galera da empresa ou fui inspirado por eles foram:
- Me adaptar a usar tmux
- Migrar definitivamente para o iTerm
- Sair do screen e ir pro byobu
- Abandonar de vez o sh e só usar zsh para terminal shell
- Organizar VM’s com vagrant
- Usar uns plugins mais decentes pro VIM
- Migrar pro vim com janus
- Usar boxen / vagrant ao invés de gambiarrar a máquina
BDD e CI
O desenvolvimento orientado a testes ou Behaviour Driven Development (BDD) é uma das técnicas de programação que mais tranquilizam os finais de semana e as noites de sono de um programador. Na Resultados Digitais fiquei muito feliz com o capricho e a seriedade que é levado o branch master no git do rdstation que tal um exemplo do que seria “levar o master a sério?”. Acho que pra quem não trabalha aqui, isso pode não ficar claro – talvez finalizar o próximo parágrafo dizendo: “e só com os testes passando é que mergeamos com o branch master. Isso é levá-lo a sério”. Também temos integração contínua (CI) e isso significa que várias pessoas compartilham o mesmo código e diariamente criam e compartilham novas funcionalidades e alterações.
Dessa forma, para compartilhar essas funcionalidades e progredir com segurança, existe uma bateria de testes que verifica se o funcionamento está conforme o esperado em cada parte do código até a funcionalidade como um todo. Quando uma nova parte é integrada, todos os testes são verificados e se nenhum código quebrou ou teste falhou, podemos saber que o código que está sendo criado está consistente e não corrompe as funcionalidades atuais.
Parece fácil, mas não é. Na prática essa é a primeira equipe que eu trabalho que consegue levar o processo contínuo de forma integrada.
Isso tudo é muito inspirador e só tenho a dizer muito obrigado :)