Qualquer um que tenha gasto tempo construindo software em alguma empresa irá lhe dizer que conseguir reutilizar software é realmente extremamente difícil. Um reúso sistemático, de larga escala é ainda mais difícil em uma organização. Como um desenvolvedor com prazos a cumprir e funcionalidades para entregar é difícil manter o reúso como uma prioridade. Se você é líder de um time, então essa afirmação é pior ainda – você precisa atender as necessidades dos patrocinadores do projeto, entregar as funcionalidades dentro do prazo e do orçamento, e gerenciar o desenvolvimento do time. Reúso, qual reúso?
Passando por diversos projetos e fazendo parte de times altamente produtivos, tenho chegado à conclusão de que o reúso de software é uma idéia viável. Isto não quer dizer que é uma tarefa fácil e existem diversas maneiras de fazer um reúso de software mal feito. Falta de liderança e de visão para fazer o esforço de trabalho dentro de uma política organizacional e um contexto cultural e a falta de alinhamento com o que os – patrocinadores do negócio estão tentando alcançar é um fator chave. Alguns esforços falham porque eles são demasiadamente ambiciosos, onde grande parte dos esforços de se construir um design perfeito é gasto na tentativa de modelar futuros componentes para um futuro perfeito. Ainda que outros falhem por conta da falta de flexibilidade no projeto, por conta de um planejamento inadequado, e o financiamento de problemas. Uma comunicação efetiva e consciência da importância do reúso de software é também um fator crítico de sucesso.
O propósito deste artigo é apresentar algumas dicas de como ter sucesso com o reúso sistemático baseado na minha experiência em vários projetos. A intenção é que artigo não seja cansativo e sim que desenvolvedores e líderes de equipe apreciem a variedade de estratégias – técnicas e não-técnicas – de que é preciso aplicar para ter sucesso com reúso sistemático.
Dica #1 Focar nos recursos específicos de domínio do software
O valor ao negócio é o que torna a sua aplicação ou linha de produto única, a sua empresa especial, e o que diferencia você da concorrência. Quanto mais rápido você desenvolve, libera, e iterativamente melhora os seus conhecimentos no domínio do software mais rápido você irá reagir às mudanças do negócio e atender os seus clientes. Se você focou somente em construir componentes de negócio reutilizáveis, à grandes chances de eles serem relevantes para as demandas do negócio e de serem reutilizáveis em futuros projetos.
Geralmente, os desenvolvedores em seu zelo de criar uma obra de arte técnica, focam em construir componentes reutilizáveis e serviços para os problemas que já possuem solução dentro de sua empresa ou em uma comunidade de código aberto. Agora, se você tem que fazer, faça – mas tente evitar construir código novo para soluções que já existem. Não é sobre isto que trata reúso de software?
Dica #2 Nomeie seus componentes de software apropriadamente
Sempre que nomear um método, uma classe, um componente, uma biblioteca, ou um serviço – pare um minuto para pensar sobre o propósito real do seu software e suas funções antes de atribuir um nome. Um nome apropriado irá ajudá-lo a procurar por componentes de software existentes para serem reutilizados. Adicionalmente, o esforço será compensado quando você tentar refatorar componentes de software existentes para serem mais reutilizáveis.
Não importa se você vem por um método facaTudo () ou um serviço EnviarDadosParaServicoSistemaXYZ – tire um minuto para renomeá-los apropriadamente. Geralmente, um nome ruim irá lhe causar um pouco mais de pesquisa para validar uma capacidade que exista em sua aplicação. Se o nome for muito obtuso, você pode não reconhecer uma funcionalidade que já está lá e acaba duplicando-a.
Bons nomes são obviamente vinculados para seu problema de domínio, mas guias gerais também são válidos, é uma boa idéia nomear os componentes de software baseados nas funcionalidades do negócio ou em suas capacidades. Se você está publicando alterações de pedido para outro sistema, porque não chamar o componente PublicarAlteracoesPedido ao invés de EnviarDadosParaSistemaABC? Quando você nomeia um componente de maneira acurada, simples e clara você irá se surpreender com a freqüência que isto irá lhe ajudar na hora de reutilizá-lo.
Dica #3 Não tem certeza se é algo reutilizável? Atrase o comprometimento
Os problemas realmente interessantes em seu domínio irão requerer uma reflexão considerável, colaboração com os stakeholders do projeto, múltiplas iterações, e um feedback real dos usuários. Este é o primeiro item básico para que a reutilização sistemática prospere. Entretanto, somente o fato de que algo parece ser reutilizável, pode não ser... pelo menos ainda não. Considere estas perguntas:
- É um pedaço de funcionalidade realmente reutilizável além do projeto em questão?
- Tornar algo reutilizável irá adicionar uma mudança significativa para o design existente?
- O problema relevante ao domínio relacionado à funcionalidade esta sendo compreendido?
- Como esta funcionalidade irá evoluir com o passar do tempo?
Quando temos mais perguntas do que respostas sobre um componente reutilizável em potencial – resista ao desejo de generalizar, adicionar camadas de abstração ou fazer variações do produto. Como alternativa, foque nos requisitos imediatos do negócio e trabalhe somente nisto para a iteração atual ou para o release. Anote a idéia ou funcionalidade como um candidato a ser reutilizado, mas não necessariamente torne-o reutilizável ainda, pois você não pode saber o que ainda não sabe.
Kevlin Henny, em um trecho no livro, '97 Things Every Software Architect Should Know', refere-se a este conceito chamando-o de 'Simplicidade Antes da Generalização, Utilize Antes de Reutilizar.
Lembre-se, a clareza do domínio adicional sobre a vida do projeto combinado com o feedback real do usuário irá ajudá-lo a não macular a sua causa.
Dica #4 Evolua Componentes Reutilizáveis Iterativamente
Quando você reconhece a necessidade de reutilizar um componente de software, a chave é mapear o componente com uma estratégia de realização. Se você fizer uma abordagem de realização “big bang” para seu componente, você pode acabar criando um componente de software que seja irrelevante para as necessidades imediatas de seu projeto e adicionar um risco significante ao seu cronograma por conta do aumento no design, desenvolvimento, e tempo de teste. De qualquer modo, você irá perder uma grande quantidade de recursos preciosos.
Ao invés disso, mitigue os riscos que envolvem o componente reutilizável no decorrer de múltiplas iterações. Tome como exemplo um componente reutilizável que envia notificações para seus usuários. Vamos nomear o componente de Notificador de Negócio. Ao invés de tentar construir as 100 campainhas e sinais que o componente poderá ter nós iremos montar um plano simples que irá evoluir com o passar de diversas iterações.
Iteração #1 - notificação via email para eventos predefinidos de negócio.
Iteração #2 - permitir que o usuário escolha notificações diferentes dos eventos de negócio.
Iteração #3 - permitir que os usuários definam regras de negócio customizadas para gerar eventos de negócio.
Iteração #4 - enviar notificações em um console web ou aplicações de mensagem instantânea.
Iteração #5 - permitir que os usuários incluam seus amigos ao receberem notificações.
Iteração #6 - integrar as notificações com workflow de revisão para uma pessoa de suporte.
Obviamente este é somente um exemplo e as funcionalidades que você irá colocar em uma iteração especifica são baseadas em requisitos de negócio, prioridade, facilidade de implementação, e outras considerações. Você poderia por exemplo, reduzir o investimento em um componente se não for mais prioridade ou vice-versa. A chave é saber que não interessa o que você quer construir como um componente reutilizável, planeje a sua evolução no decorrer das múltiplas iterações. Você irá reduzir os riscos e continuará flexível para as necessidades e requisitos de negócio e por fim, construa somente componentes que você realmente quer investir.
Dica #5 Ser Consistente é mais importante do que seguir um padrão de indústria.
Ao construir componentes de software e serviços para reúso entre muitas aplicações é mais importante empenhar-se em buscar consistência do que seguir um padrão. Se uma grande parte de suas aplicações utiliza um componente reutilizável em particular, você pode tratar a interface existente sempre como um adaptador, que por sua vez invoca uma API padrão da indústria por trás das cenas. Note, entretanto que não estou sugerindo que você construa cegamente onde padrões maduros já existam.
Isto é especificamente relacionado ás capacidades horizontais do negócio que você quer reutilizar. Por exemplo, digamos que você precise processar pagamentos de cartão de crédito de diversas aplicações e não exista um padrão de indústria no momento que você precisa da funcionalidade. É importante ter uma API de pagamento que suas aplicações utilizem ao invés de esperar que um padrão apareça como por mágica. No dia seguinte, se e quando um padrão aparecer você pode alterar a implementação existente sem causar qualquer impacto em suas aplicações existentes. Ok, talvez eu esteja simplificando – talvez precise de alterações menores no código e testes de regressão. Mas a questão é que você estará em uma posição consideravelmente melhor do que ter que alterar o código através de sua base.
Dica #6 Conduza Revisões de Código
Revisões de código são uma das maneiras mais efetivas de assegurar que seus componentes reutilizáveis estão sendo utilizados apropriadamente. Geralmente, na pressa de entregar logo um produto, os desenvolvedores podem incluir código sem perceber que a funcionalidade já existe em algum outro lugar. Porque isto toma tempo e requer disciplina para revisar código, é um boa prática fazer esta atividade em pequenos trechos. A chave é a consistência e não uma grande quantidade de código. Você pode querer uma maneira rápida de referenciar quais componentes reutilizáveis existem e integrá-los ao seu código. Geralmente me encontro descobrindo idéias para novos componentes reutilizáveis enquanto faço as revisões de código. Com o passar do tempo você irá começar a encontrar padrões e duplicação entre fragmentos de código e funcionalidades da aplicação que irá auxiliá-lo a alcançar esta sinergia.
Quando você vê oportunidades de refatoração ou de criar componentes reutilizáveis, separe-os do resto do código de sua aplicação. Separar o código fonte fisicamente e controlar a versão como uma entidade independente. Assim como todas as coisas isto é preciso ser feito iterativamente e não é um item obrigatório para o release inicial do produto. Conforme os componentes evoluem e se tornam reutilizáveis eles podem ser refatorados para seus próprios repositórios de forma que você possa gerenciá-los melhor. A chave é movê-los para o repositório assim que eles se tornarem reutilizáveis. Versione e evolua os componentes separadamente do código principal assim será mais fácil de integrá-los em novos projetos.
Dica #7 Nunca lance um componente de software reutilizável sem uma suíte de testes de regressão automatizado
Se você irá apostar em um componente de software reutilizável e divulgá-lo ao mundo você precisar ter uma suíte de testes de regressão para ele. Por quê? Sem testes de regressão, os clientes atuais e em potencial não terão uma confiança adequada no componente. O principio fundamental de reúso é a alta qualidade – reduzir chances de erros, bugs, implementação incorreta de requisitos – para não ter que produzir algo que já existe. Para ter certeza que você pode entregar algo conforme combinado, uma suíte compreensiva de testes de regressão automático é essencial. Isto não irá ajudar os seus clientes imediatos, mas para todos que ainda hão de vir.
Você pode criar scripts reutilizáveis para compilação, execução, e reporte de todos seus testes unitários e de regressão. É uma prática aplicável tanto se você está construindo componentes ou serviços ou até fluxos de processos de negócio. O próximo passo a ser feito é integrar estes scripts em uma suíte de integração contínua.
Dica #8 Entenda as necessidades do negócio antes de tentar persuadir
Geralmente é tentador persuadir um desenvolvedor ou um gerente de desenvolvimento para fazer com que eles concordem em reutilizar um componente de software. Entretanto, se você persuadir repetidamente sem entender a necessidade, o requisito de negócio, dificilmente seus esforços trarão frutos. Ao invés de usar a persuasão, tente escutar, enfatizar e realmente entender o requisito. Tente se colocar do outro lado e identifique os componentes que podem ser potencializados ou desenvolvidos. Por quê? Porque quando você ouvir realmente seu cliente, irá descobrir que seus componentes existentes atendem perfeitamente as necessidades do negócio como eles são ou se não atendem. Talvez seus serviços reutilizáveis precisem atender uma certa métrica de performance. Ou se existir um investimento para o serviço existente, o risco irá aumentar. Seja lá o que for.
O ponto é a relevância do seu componente existente para o problema em questão. Ouça, avalie, e convença (se aplicável). Nesta ordem.
Dica # 9 Crie componentes de software reutilizável sempre que possível
Existe uma variedade de razões que iniciativas de reúso sistemático falham, incluindo razões técnicas e organizacionais. Se não existe um grupo de desenvolvedores que sejam prováveis usuários destes componentes reutilizáveis, suas iniciativas não terão chance de sucesso. Geralmente ouço que desenvolvedores e gerentes de desenvolvimento não querem reutilizar ou desenvolver algo reutilizável porque eles não se sentem incluídos na concepção de componentes reutilizáveis. Como lidar com este fato? Ao invés de tentar convencer, crie em conjunto os componentes reutilizáveis.
Se você tem como requisito construir uma notificação de alerta de email – trabalhe com o time de desenvolvimento original e envolva-os no projeto. É melhor tê-los desenvolvendo apenas uma porção ou todas as funcionalidades do software? Se eles auxiliarem na criação com você, eles não irão pensar no componente como uma caixa preta que eles são forçados a utilizar. Você ficará surpreso com isto – eles irão começar a ajudá-lo a fomentar o reúso compartilhando as idéias com outros companheiros na empresa.
Dica #10 Busque requisitos do suporte a produção para seus componentes reutilizáveis
Tem ainda mais uma coisa que você deveria fazer antes de colocar seu componente reutilizável em produção, que é falar com a equipe de suporte da produção. Veja o que eles acham, compartilhe seu projeto, e obtenha o feedback antes e sempre. Esta atitude não fará somente seu componente suportável (imagine um componente reutilizável sem log, sem processo ou habilidade de reportar em métricas chaves), mas fará com que você conquiste um parceiro de valor. O suporte da produção em breve irá aprender a confiar em seus componentes, em seus serviços e irá demandá-los em diversos projetos. Este é um trunfo para você vender reúso e algo para que seus parceiros tenham um respaldo do suporte.
Conclusão
Utilizando um misto de práticas técnicas, colaboração, e pragmatismo é possível lentamente aumentar a sua base de componentes reutilizáveis. Este artigo apresentou dicas que tenho utilizado repetidamente como parte de meu trabalho diário para aumentar as chances de sucesso. Estou interessando em ouvir mais sobre suas experiências com o que tem e que não funcionado ao tentar adotar um reúso de software efetivo.