O Código Magro (The Lean Code)

Seguindo a onda das idéias Lean eu gostaria de criar mais uma tendência aqui nesse blog:

O Código Magro (ou Lean).

Em poucas palavras, Código Magro (ou Enxuto se preferir) é um projeto de software pequeno, independente e extremamente organizado, que pode ser facilmente mantido e sua intenção facilmente compreendida por qualquer participante do processo de desenvolvimento do software, inclusive por não programadores.

A idéia é que mesmo um grande e complexo aplicativo passe a ser composto por vários projetos de software independentes, pequenos, organizados, fáceis de compreender e de manter.

Manutenção é comprovadamente um dos custos mais altos do desenvolvimento de um software. "Dois terços do custo do tempo de vida de um sistema de software envolve manutenções." (Ver Manutenção de Software). É muito mais rápido (e barato) identificar um problema ou uma funcionalidade que precisa ser mantida em um código magro, reduzindo consideravelmente o custo de manutenção de um software.

Quantas funcionalidades o seu código fonte está implementando no momento? A resposta dessa pergunta é uma boa indicação se seu projeto de software é magro ou não.

Um código magro implementa uma quantidade mínima de funcionalidades ao mesmo tempo. Se seu código fonte virou um spaghetti, ou seja, é muito extenso e se tornou tão complexo a ponto de você nem conseguir identificar as funcionalidades que ele implementa, então esse caso realmente necessita de uma refatoração Lean.

É muito importante também que um código magro seja viável. Código magro viável é aquele que possui usuários e clientes comprovadamente satisfeitos. (Veja a definição de Product-Market Fit).

Bons acompanhantes para essa leitura seriam: The Clean Code (ou o blog do Uncle Bob) e The Lean Startup de Eric Ries.

O Código Magro na Prática

Após muito pesquisar sobre visibilidade de código, entendi que para desenvolver um código magro são necessários os seguintes tópicos abaixo:

• Linguagem Ubíqua,
• Minimum Viable Products isolados,
• Uma ferramenta para visualizar a intenção de seu código fonte.

As vantagens da utilização da linguagem ubíqua dentro do código fonte são inúmeras. Esse tópico por si só é extremamente relevante, e por isso possui um post a parte já escrito anteriormente: 

Linguagem Ubíqua para dentro do código-fonte

Este post vai descrever com detalhes os aspectos importantes da Linguagem Ubígua no desenvolvimento de um código magro.

O próximo item é sobre os MVPs. Se seu aplicativo possui uma quantidade incontável de funcionalidades, simplesmente implementá-las todas em uma mesma massa de código fonte não ajudará em nada na compreensão e na manutenibilidade desse código. Por isso a definição a seguir: 


Um código magro deve conter somente um Minimum Viable Product. 

Quando os requisitos de seu software começarem a se multiplicar, volte-se sempre para a intenção de seu aplicativo. Mantenha o foco em seu MVP. Após entrevistar os seus clientes e consultar o seu mercado, se  novas funcionalidades comprovarem-se como de fato úteis para seus usuários (veja o post Definindo o seu Mininum Viable Product), então divida essas novas funcionalidades em diferentes MVPs e crie projetos de software independentes para elas, com códigos fonte isolados. Se necessário, utilize APIs e interfaces de comunicação entre seus MVPs, mas não simplesmente os desenvolva em uma mesma única massa de código.


LiveSource e O Código Magro

Ferramentas de trabalho são muito importantes para auxiliar o processo de desenvolvimento de um software. Não é à toa que uma equipe de desenvolvimento sempre utiliza inúmeras delas. Porém, as ferramentas de desenvolvimento atuais mais utilizadas pelos programadores, as chamadas IDEs (como por exemplo Eclipse, VisualStudio, IntelliJ, etc), são extremamente técnicas e infelizmente não são ideais para visualizar a intenção de seu código fonte ou para serem utilizadas pelos não programadores que também fazem parte da equipe de desenvolvimento de um software (como por exemplo stakeholders, product owners, especialistas de negócio, gerentes de projeto, testers e até mesmo usuários finais ou clientes).

É por esse motivo que desenvolveu-se o LiveSource, para que a intenção do código fonte possa ser filtrada,  visualizada e compreendida, e para que não programadores possam participar e contribuir mais ativamente no processo de desenvolvimento do software. Saiba mais sobre as vantagens de LiveSource aqui.

Com LiveSource o código fonte não mais estará escondido atrás de complexas camadas técnicas, mas sim, estará disponível online, traduzido e facilmente compreensível pelos programadores e não programadores da equipe de desenvolvimento. Se a intenção do negócio não estiver claramente refletida no código fonte, é desta maneira que LiveSource vai colaborar com a equipe de desenvolvimento: expondo o problema abertamente.

"Eu vejo valor em manter meu código fonte um pouco mais organizado e mais fácil de ver do que navegar através de código.", comentário de um early adopter de LiveSource.

Quando uma pessoa (programador ou não) visualiza o código fonte através da ferramenta LiveSource é facilmente detectável se este código fonte está suficientemente organizado ou não. É possível visualizar se a documentação desse código, quando existente, é relevante para o domínio de negócios ou se somente está adicionando detalhes técnicos (muitas vezes inúteis) para os programadores da equipe de desenvolvimento.

Possuir a intenção do domínio de negócios totalmente atrelada ao código fonte é uma característica chave do código magro. O nome de cada arquivo, de cada diretório, de cada classe, de cada pacote, de cada função e de cada variável deve refletir diretamente a intenção de sua existência para o domínio de negócios. Um não programador que leia o nome de um arquivo ou de uma função por exemplo, deve compreender facilmente o seu significado. E então, a documentação desse código deve adicionar as informações de negócio que justificam e explicam a sua necessidade.

Repito aqui a indicação da leitura do post sobre Linguagem Ubíqua para dentro do código fonte.

Quando todos os participantes do processo de desenvolvimento, incluindo product owners, gerentes de projeto, clientes, usuários, etc, podem participar ativamente da construção do artefato mais importante de um software, ou seja, do seu código fonte, o dinamismo da comunicação e a precisão dos resultados refletem diretamente na qualidade final do produto gerado, reduzindo drasticamente o custo de sua manutenção.

Após a definição do seu Minimum Viable Product

Os próximos passos após a definição do seu Minimum Viable Product (veja o post anterior desse blog) é justamente contruir e validar esse MVP.


Que funcionalidades precisam estar disponíveis para que seus Early Adopters comecem a utilizar seu produto?
Abaixo encontram-se as Histórias de Usuário para o MVP de LiveSource:


MVP 1: LiveSource é um Toolkit para web que carrega o código fonte de seu software e gera uma versão de fácil leitura desse código, compreensível por todos os integrantes da equipe de desenvolvimento inclusive pelos não-programadores.

• "Como um usuário, eu gostaria de visualizar a lista dos meus projetos de software."
• "Como um usuário, eu gostaria de visualizar a lista de todos os arquivos fontes de cada um dos meus projetos."
• "Como um usuário, eu gostaria de uma visualização de fácil compreensão para cada um dos arquivos do código fonte de cada projeto."

LiveSource é um projeto bastante extenso e complexo, mas como vocês podem observar só existem três Histórias de Usuário no meu MVP. É assim que um projeto Lean deve ser: começar pequeno, eliminar o desperdício, entregar rapidamente, etc...

Junto com a lista de Histórias de Usuário, é importante ter também um rascunho de como seria a interface com o usuário de seu produto. Pode ser algo bem simples, como um desenho em um pedaço de papel, ou a foto de um rabisco num quadro de trabalho. Chamamos isso de Low-Fidelity Prototype.

Figure 1: Low Fidelity Prototype for the LiveSource MVP

Neste ponto do processo de desenvolvimento, já estou utilizando algumas das técnicas do Desenvolvimento Ágil. Podemos agora começar a planejar uma Sprint, definir um Product Backlog, estimar e priorizar as Histórias de Usuário, etc.

Para simplificar ao máximo, para essa primeira entrega do MVP vamos descartar as páginas de login e até mesmo a necessidade de um banco de dados. Vamos carregar todo o código fonte a partir de um repositório de arquivos remoto, como Git ou Subversion.

Para o exemplo de LiveSource, vamos considerar as três histórias acima como prioridade e vamos inserí-las na primeira Sprint do produto. E então vamos descrever todas as tarefas necessárias para implementar essas histórias.

Tarefas para a Interface com o Usuário:

• Listar todos os projetos disponíveis.
• Quando o usuário clica em um projeto da lista, o sistema exibe uma lista com todo o arquivos do código fonte armazenado no repositório desse projeto.
• Quando o usuário clica em um arquivo na lista do código fonte, o sistema exibe uma versão de fácil leitura para esse código fonte.

Tarefas do lado do Servidor:

• Criar uma conexão com o servidor remoto de arquivos dos projetos.
• Carregar a lista de todos os arquivos fonte do projeto armazenados no repositório remoto.
• Carregar o conteúdo do arquivo fonte quando selecionado.
• Extrair todos os comentários e a documentação do conteúdo de um código fonte.

Eu poderia adicionar algumas Spikes a essa lista, como por exemplo uma tarefa para estudar as APIs para conectar com o repositório de arquivos dos projetos, ou uma outra tarefa para explorar como extrair a documentação e os comentários de um código fonte. Cada uma dessas tarefas podem ser complexas e se estender por dias de trabalho. Só não vou adicioná-las a minha lista neste momento porque eu já tive esses tópicos explorados enquanto eu estava desenvolvendo o protótipo do meu produto.

O próximo passo é distribuir as tarefas pela equipe de desenvolvimento. Deixe que cada programador escolha quais tarefas quer implementar e quando cada um pode se comprometer em implementá-las.

Enquanto estiver implementando seu MVP, tente construí-lo o mais independente possível. Quando novas funcionalidades surgirem, tente não simplesmente adicioná-las ao seu MVP já existente, mas sim, tente criar um novo MVP, também independente, de uma maneira que se possa conectar ou desconectar funções sem afetar o sistema como um todo.

Enquanto estiver implementando seu MVP você já deve permanecer em contato com seus ealy adopters, carregar dados reais e testar a usabilidade do sistema. O quanto antes você começar a receber feedback melhor. A idéia é que você já termine a implementação com seus early adopters utilizando o sistema.

A principal mensagem desse post é: Não inicie um novo MVP enquanto os seus early adopters ainda não estiverem utilizando os MVPs que você já desenvolveu. Há muito o que se ajustar depois que se começa a receber feedback dos clientes, e esses ajustes na maioria dos casos são muito mais importantes do que novas funções a serem desenvolvidas.

O melhor momento para se começar a adicionar novas funções ao sistema é quando já se estabeleceu a marca de 40% dos usuários declarando que ficarão "Muito Desapontados" se eles não mais puderem utilizar o seu produto. Essa técnica é chamada de Product/Market Fit.

Se você não está atingindo o seu Product/Market Fit, o que se tem a fazer é reiniciar todo o processo de desenvolvimento de clientes novamente. Retorne ao protótipo e ouça mais os seus early adopters. Que razões eles alegam para utilizar ou não o seu produto. Ajuste o seu MVP até que você atinja o seu Product/Market Fit.

Não é nada fácil atingir esse ponto. Exige-se muita determinação, e normalmente necessita-se de várias iterações para estar pronto para um crescimento em escala. O processo descrito aqui é um bom caminho inicial para o sucesso no final.