Issues do GitHub - um recurso que vale mais do que parece.

Faz pouco tempo que comecei a usar o GitHub no trabalho. Depois de alguns anos sofrendo com o SVN hospedado no servidor local da empresa, um novo desenvolvedor conseguiu "nos convencer" a migrar para o Git, por ser um sistema melhor, e para a nuvem, devido a vários problemas de disponibilidade que começaram a interferir terrivelmente no nosso pair-programming remoto.

Eu fui o mais fácil de convencer a fazer isso, porque já tinha lido bastante, e porque já tinha "upado" algumas coisas pra lá, dos meus projetos de hobby. O fato é que eu nunca tinha tido usado "seriamente" o GitHub para os projetos pessoais, um pouco por falta de insistência, falta de disciplina minha, e por não haver uma real necessidade. O projeto acabava virando uma bagunça de qualquer forma, e o Dropbox acabava sendo a melhor forma de eu ter "sempre a última versão" entre diferentes máquinas.

Pois o fato é que desde que começamos a usar o GitHub como uma equipe, para desenvolvimento "sério", e em especial por estarmos pagando - e portanto querendo espremer todo o suco da laranja - resolvi ir um pouco mais além e explorar todas as outras coisas que a plataforma GitHub (e não necessariamente o Git) oferece. E, por haver uma necessidade de gestão, as Issues se mostraram surpreendentemente úteis.

Tão úteis que resolvi começar a usar também para os projetos pessoais, e a surpresa é que, mesmo sem ser "desenvolvimento sério", mesmo sem ser trabalho em equipe (ao menos não por enquanto), eu percebi que, simplesmente por estar usando as issues, o desenvolvimento teve um ganho de qualidade e produtividade absurdo!

O que notei de mais marcante é que, juntamente com a facilidade do branching, as issues são a forma ideal de registrar uma direção desejada para o desenvolvimento no momento e no contexto em que é adequado fazer isso. E esse momento definitivamente não é enquanto se está escrevendo código.

O hábito que adquiri rapidamente, e que está dominando a forma de desenvolver agora é:

1. Assim que eu tenho um momento "ahá!", e me dou conta de qual é o principal obstáculo ou feature faltando, eu corro pra abrir a issue e escrever em detalhes qual é a natureza do problema: qual a situação desejada, qual a situação atual, quais os passos necessários para transformar a situação atual na situação desejada, e quais os prováveis obstáculos para isso;
2. Esse issue deve quase que obrigatoriamente se transformar em uma branch;
3. Enquanto eu estiver nessa branch, eu não posso mexer em outra coisa! Manter um histórico "limpo" e evitar a diluição do esforço requer que, numa branch, eu só trabalhe no tema da branch (que deve estar apropriadamente capturado pelo nome escolhido para ela);
4. O maior sonho de quem está trabalhando numa branch que não seja dev ou master deve ser terminar a implementação o mais rápido possível, para que a branch possa ser apagada imediatamente após sua conclusão.

Fazendo isso, temos vários elementos positivos, que somados têm um impacto muito relevante na velocidade e qualidade:

• O fato de um Issue ser criado via browser, com uma interface afastada do código-fonte, leva o desenvolvedor a pensar de forma global e abstrata sobre o problema, em um momento em que o "emocional" não está comprometido com as dificuldades de criação ou implementação. Essa dissociação entre o pensar e o agir fazem com que cada uma dessas etapas seja desacoplada da outra, tornando-se comparativamente mais fácil;
• Ter um par, formado por um Issue e sua Branch correspondente, leva o desenvolvedor a manter o foco naquela funcionalidade específica, e ter um critério definido de "pronto" gera um incentivo palpável e uma sensação de progresso que são muito motivantes;
• A necessidade de isolar as modificações para evitar regressão durante o merge faz com que se privilegie soluções coesas e desacopladas.

Da próxima vez que o leitor der uma visitada no seu repositório, experimente brincar com as Issues - e em especial brinque também com as Labels e Milestones. Garanto que vai se surpreender com o retorno!