No Budismo, o caminho do meio (madhyamā-pratipad, em sânscrito) é a prática de ensinamentos que nos afastem das vaidades, extremismos e nos guiem a uma busca por mais sabedoria, moralidade e raciocínio. No mundo Java e .NET, o caminho do meio possui o mesmo conceito. Gostaria de compartilhar, neste contexto, uma interessante leitura sobre experiências de diversos arquitetos de software que guardam uma espantosa coincidência com as idéias e conceitos do caminho do meio. Esta lições estão coletadas no excelente e sucinto livro 97 Things Every Software Architect Should Know, escritas por diversos arquitetos de todo o mundo e compiladas por Richard Monson-Haefel.

Dentro das 97 dicas presentes neste livro, gostaria de destacar três:

• Não coloque seu resumè a frente dos seus requisitos. Este pequeno texto discute porque bons arquitetos primeiro entendem o problema e o contexto de negócio antes de propor a tecnologia preferida do seu currículo. A lição é clara: não leve a sua tecnologia Java ou .NET preferida para o seu cliente antes de entender claramente o problema.
• Simplifique a complexidade essencial, diminua a complexidade acidental. A complexidade essencial diz respeito a complexidade inerente a um problema. A complexidade acidental diz respeito a efeitos colaterais introduzidos por escolha de tecnologias complexas e soluções estado da arte. Exemplos são o uso de EJBs, servidores como o BizTalk, servidores de transações distribuídas ou modelos complexos de orientação por objetos para problemas simples que não necessitam deste tipo de solução. A lição novamente é clara: não introduza complexidade acidental para aprender uma nova tecnologia. É responsabilidade do arquiteto gerir bem o dinheiro do projeto, da sua empresa e do seu cliente. Não brinque com o dinheiro alheio por vaidade.
• Arquitetura é sobre equilíbrio. A arquitetura deve equilibrar aspectos técnicos e aspectos de negócio (condutores de negócio). “Arquitetos Java e .NET” que se esquecem de olhar para o negócio estão violando o caminho do meio. Estão buscando apenas um meio de satisafazer seus egos no uso de soluções “elegantes” e criar novos desafios técnicos que apenas eles precisam.

Um “arquiteto Java” e um “arquiteto .NET”, portanto, irá se tornar um melhor arquiteto se não ficar cego pelas palavras “Java” e “.NET” e colocar no seu cardápio porções de liderança técnica e práticas de alinhamento ao negócio.

Pensamento do dia: “A pior escravidão possível é a escravidão a si mesmo”, Sêneca.

Todos sabem que o Spagetti é uma massa de origem italiana muito popular no Brasil. Nem todos sabem, entretanto, o que é um código spagetti. Um código desta natureza é normalmente formado por um longo conjunto de instruções, com um vários níveis de aninhamento e grande complexidade técnica. A sua manutenção é trabalhosa e muitas vezes injeta erros colaterais na aplicação sendo mantida. Diferentemente do seu primo culinário, portanto, o código spagetti não é bem visto no mundo de TI.

Cortando spaggettis com o uso da métrica de complexidade ciclomática
Cortar um spagetti com faca é um crime culinário para os italianos. Na TI, infelizmente, não nos resta outra opção. Devemos cortar o mal pela raiz, literalmente.

Para isso, podemos usar como métrica um algoritmo que mede o quão simples ou complexos são os métodos e funções que compõem uma aplicação. Chamado de complexidade ciclomática e formalizado por Thomas McCabe, este algoritmo basicamente mede o número de caminhos lineares independentes encontrados em um método ou função. Quanto maior o número de caminhos, mais complexo é o seu código. Valores maiores que 10 geram um alerta amarelo, pois isto indica que o código está muito complexo para um ser humano manter. Surpreendentemente, vemos códigos em empresas com valores maiores que 100, 200 ou 500 (!!!), que são verdadeiros lamaçais de spagetti.

Felizmente não precisamos conhecer os detalhes do algoritmo (baseado em teoria de grafos) para usá-lo. Ferramentas simples e gratuitas analisam todo o código fonte das nossas aplicações e produzem uma análise de complexidade média e de ofensores individuais. Compilo abaixo algumas ferramentas para suporte este processo.

• Source Monitor - Ferramenta simples que calcula a complexidade ciclomática e outras métricas para Delphi, VB, VB.NET, HTML, C#, C++, Ansi C e Java.
• Metrics - Excelente plugin para eclipse, compila diversas métricas de qualidade de código, incluindo a complexidade ciclomática.

Com os resultados em mãos, podemos refatorar os códigos para torná-los mais simples.

Pensamento do dia: “A evolução do conhecimento humano é em direção à simplicidade, e não à complexidade”, L. Ron Hubbard

Vemos muitos projetos que falham por problemas gerenciais. Um destes problemas é a distância entre o gerente de projeto e a sua equipe. Times que não se sentem orientados e aconselhados diariamente perdem o seu foco e se dispersam. Para combater esta distância, devemos fomentar e incentivar a figura do líder técnico de desenvolvimento (que em muitas empresas também é o arquiteto de sistemas).

O líder técnico de desenvolvimento mantém o time unido e coeso. Ele mantém a consistência técnica do produto de software sendo construído e atua como um coach para todo o time para os problemas técnicos e de ausência de motivação, que são comuns em projetos complexos e com prazos desafiadores.

O líder técnico/arquiteto é o contraponto musical do gerente de projeto. O líder técnico e o gerente de projeto atuam como um par-alfa de lobos em uma alcatéia na caçada pelo sucesso do projeto.

As fronteiras entre o Gerente de Projeto e o Líder Técnico de Desenvolvimento

Adapto abaixo um trecho do livro Applied Software Architecture, de Christine Hofmeister, Robert Nord e Dilipe Soni, que explicita a fronteira entre a gerência de projeto e a liderança técnica de projetos.

Pensamento do dia - Eclesiastes 4:9 Melhor é serem dois do que um, porque tem melhor paga do seu trabalho. 4:10 Porque se um cair, o outro levanta o seu companheiro.

Duas notícias recentes levantam críticas sobre o uso dos tradicionais e estabelecidos modelos de gerência de projetos, programas e portfólios do renomado instituto PMI.

1. O Gartner Group fez críticas duras à falta de aplicabilidade destes corpos de conhecimento para TI devido especialmente à sua superficilialidade em diversos pontos (sic). A notícia completa e uma análise desta polêmica esta aqui na portal da SearchCIO. Compilo aqui uma frase do diretor de pesquisa do Gartner Group, Michael Hanford - “Their portfolio management standard shows a solid understanding of a complex discipline, but I’d say it disappoints with an uneven level of explanations“.

2. O SCRUM tem sido adotado mundialmente em cada vez mais empresas no Brasil e no exterior. Uma interessante reportagem do uso do SCRUM em empresas fora do âmbito de TI está disponível aqui. Aparentemente, o SCRUM se adapta melhor a empresas com realidades dinâmicas e ágeis e segue a escola de gerenciamento ágil que também tem sido fomentada pela IBM em sua melhor prática denominada Two Level Planning.

Pensamento do dia: “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”, Charles Darwin