Em 1975, Frederick P. Brooks escreveu o revolucionário The Mythical Man-Month. Quarenta anos depois, esta série de artigos pretende revisar as afirmações e os argumentos do autor. Quanto o ofício da Engenharia de Software evoluiu desde então?
Capítulo 4: Aristocracy, Democracy, and System Design
Neste capítulo, Brooks discute como coordenar o design, ou projeto de um sistema. As analogias com conceitos de organização social e história são impressionantes. Acompanhe os detalhes nos pontos a seguir.
Integridade conceitual
Integridade conceitual é o exercício mais importante no projeto de um sistema
Ao longo do tempo de vida de um sistema, diferentes pessoas atuam em seu desenvolvimento e manutenção, de forma que não é incomum que haja disparidade entre várias partes do código.
Você já deve ter visto aplicações com diferentes trechos de código quase duplicados que fazem praticamente a mesma coisa ou funcionalidades que deveriam ser parecidas, mas apresentam uma experiência inconsistente para o usuário.
Sistemas assim são difíceis para desenvolver e para usar.
Segundo Brooks, um bom projeto de sistema ser coerente e ter como prioridade a integridade conceitual.Integridade conceitual é requisito para ele ser de fácil utilização.
Para explicar isso, o autor faz um paralelo com a construção das catedrais européias durante a idade média. Elas eram construídas ao longo de muitos anos e gerações. Quando um novo construtor era apontado, ele orgulhosamente pensava que poderia melhorar o que o anterior havia feito segundo a moda de sua época. Ao longo dos séculos, o resultado era um estilo confuso e contraditório.
Em contraste, o autor aponta para a excelência da Catedral de Reims, que foi construída por oito gerações de construtores abnegados que sacrificaram algumas ideias particulares em prol de uma arquitetura pura e consistente.
Em suma, num projeto de software, os envolvidos devem respeitar o estilo ou a filosofia do sistema. Segundo o autor, este é o aspecto mais importante do projeto.
Como isto é feito é algo que será discutido nos próximos tópicos.
Um bom projeto
A proporção de funcionalidade e complexidade conceitual é o teste final de um projeto.
Algumas pessoas consideram um sistema melhor porque ele tem mais funções do que os demais. Outras pessoas dizem que o melhor é o mais simples, com menos funcionalidades só que fácil de operar.
Quem está certo? Segundo Brooks, isso depende.
Imagine que alguém resolve fazer uma calculadora simplista, deixando apenas as funções de soma e subtração. Obviamente, esta calculadora é bem fácil de usar para somar e subtrair e também é fácil de implementar.
Porém, para quem precisa multiplicar valores, o seu uso será mais difícil, pois agora ela deve somar um número uma quantidade de vezes para obter o mesmo resultado de uma multiplicação.
A calculadora é simples, mas apresenta poucas funcionalidades, portanto não é um bom projeto na maioria dos casos.
Outro exemplo está em algumas linguagens de programação que dizem ser mais simples porque possuem poucas construções de sintaxe na linguagem, mas para fazer algo mais complexo você precisa escrever muito código. Ou elas geram pouco código, mas exigem uma grande capacidade intelectual para entender e codificar. Outras vêm com muitas APIs prontas, mas você tem dificuldade de encontrar a API certa para cada caso.
O autor defende que um bom projeto é identificado quando o nível de complexidade é razoável para a quantidade de funções que ele oferece.
Portanto, o melhor sistema é aquele que é o mais simples possível e, ao mesmo tempo, permite executar suas funções da forma mais direta (como ter um botão para multiplicação no exemplo da calculadora).
Além disso, é impossível disassociar um bom projeto da sua integridade conceitual, pois somente um sistema com integridade conceitual pode apresentar suas diversas funções de forma coerente e tão simples quanto possível.
Aristocracia vs. Democracia
Para conseguir integridade conceitual, o projeto deve se originar de uma mente ou um pequeno grupo de mentes.
Se você é um agilista de carteirinha, ou apenas cético com relação aos pseudo-arquitetos que andam por aí, talvez esteja se remoendo por dentro após ouvir a afirmação acima.
Infelizmente, é comum programadores sofrerem com a imposição de demandas absurdas de clientes e chefes durante o desenvolvimento.
Você também pode estar acostumado com o pensamento "democrático", onde todos podem opinar e “votar” como algo será feito.
Entretanto, o autor defende que, objetivando a integridade conceitual, é necessário que haja uma ou poucas mentes fazendo o papel de arquitetos do projeto.
Como o autor sugere, isso pode parecer como uma espécie de Aristocracia, isto é, onde um grupo da “elite” toma decisões arbitrárias.
Mas a ideia aqui não é que somente um arquiteto possa ter ideias de arquiteto. Como o autor já mencionou no capítulo anterior, ele defende equipes multidisciplinares e especializadas.
A questão mais importante é que as decisões importantes passem pelo filtro de um “arquiteto” para que não haja conflito com outras decisões tomadas por outras pessoas.
O autor cita o exemplo que um sistema precisa ter um projeto completo da interface com o usuário, de forma que não seja responsabilidade de cada desenvolvedor individualmente decidir como a interação deverá ocorrer em cada caso.
A liberdade de cada desenvolvedor está em propor melhorias e pensar em como fazer o que foi projetado da melhor forma que ele puder, sem no entanto ferir a integridade conceitual ou a filosofia do sistema.
Para um sistema ter integridade conceitual, alguém precisa controlar os conceitos. Isso é aristocracia que não precisa de desculpas.
Mantendo a disciplina
Disciplina é boa para a arte. Uma arquitetura provida externamente deve ajudar, e não atrapalhar, o estilo criativo de quem vai implementar
Sempre repito a afirmação de que "programar é uma arte". Porém, se pudesse voltar atrás no tempo, acrescentaria também que "toda arte é aprimorada pela disciplina".
Se você gosta de arte moderna pode até discordar das afirmações acima, mas para mim é um fato que todas as grandes obras de arte foram criadas por artistas que, além de talentosos, dominavam vários tipos de artes e técnicas, sem contar o grande esforço que investiam em seu trabalho.
Claro que nem sempre podemos dizer que uma arquitetura externa ajuda e vou tratar disto mais tarde. Mas, tomando por base que o arquiteto conhece seu trabalho e quer o bem tanto da sua equipe como do cliente, ter uma direção geral na arquitetura é algo que aumenta a muito velocidade da equipe, que é poupada de tomar todas as decisões.
Enfim, disciplina aqui pode ser entendida por respeitar os limites e as direções definidas na arquitetura. Isto leva a um sistema conceitualmente íntegro que, por sua vez, é mais rápido para desenvolver e testar.
Paralelizando o desenvolvimento
Grande parte da arquitetura e implementação de um software pode ser feita em paralelo, como um projeto software e hardware podem ser feitos ao mesmo tempo.
Dividir o trabalho ao mesmo tempo em que se tenta manter uma integridade conceitual, dado o que foi dito acima, pode parecer contraditório e complicado, já que tudo precisa passar pelo crivo de um ou dois arquitetos.
Entretanto, um sistema que possui um projeto bem-feito e uma filosofia definida, procurando atingir integridade conceitual, pode ser desenvolvido em paralelo de forma bastante eficiente.
Uma vez que todo o projeto segue a mesma filosofia, há definições claras das principais interfaces e uma divisão em alto nível dos principais componentes ou módulos, equipes menores podem começar o desenvolvimento individual de cada uma das partes mantendo a integridade conceitual como um tudo.
Considerações
Bebendo da mangueira de incêndio
Este foi um capítulo difícil, denso e abstrato. Além de capturar as ideias principais, tentei incluir alguns exemplos e explicações que, espero, são mais simples para entender.
Quanto aos conceitos apresentados, posso dizer que não existe realmente muito a contradizer, pois são todos princípios válidos e coerentes com a realidade de hoje.
Porém, talvez as afirmações pudessem ser mais contextualizadas e detalhadas, pois, embora os princípios sejam verdadeiros, no meu entendimento eles estão distantes do programador ou gerente iniciantes. Eu acredito que sem muitos anos trabalhando em projetos, uma pessoa não conseguiria aplicar bem o que foi transmitido no presente capítulo.
O que é mais importante?
Alguém pode argumentar que a integridade conceitual não é o aspecto mais importante de um projeto.
Você pode dizer que é atender as necessidades do cliente, por exemplo, o que não está errado.
Mas certamente, a integridade conceitual, é a principal qualidade do ponto de vista técnico.
Arquitetar ou não arquitetar?
Vivemos em um mundo muito mais volátil. Para a evolução e manutenção de um negócio, muitas vezes precisamos sacrificar a integridade conceitual em vários aspectos. Mas para toda decisão existe um preço a se pagar e, cedo ou tarde, as empresas tem que arcar com o custo de um sistema evoluído sem consistência.
Quem defende uma “arquitetura emergente” e o desenvolvimento iterativo e evolutivo, ágil, de um software pode discordar veementemente do posicionamento “elitista” de um arquiteto ou equipe de arquitetos.
Entretanto, o que tenho visto na prática em todos os projetos de que participei, é que esse tipo de papel precisa ser feito em algum nível, seja pelo analista de negócio, project owner, project champion, gerente de produto, especialista, ou o-cara-mais-que-está-há-mais-tempo-no-projeto. O risco em tentar não fazer uma arquitetura formar é acabar fazendo ela de qualquer maneira sem perceber e da forma errada.
Não existe ninguém que entenda um sistema não trivial por completo olhando por algumas horas para o código. É preciso alguém que retenha a filosofia, as motivações, os objetivos para tudo aquilo. Se isso falhar, ou se o desenvolvedor decidir ignorar, o resultado é um sistema inconsistente.
Não existe mágica
Finalmente, algo muito importante que você deve levar daqui é: não existe uma solução mágica.
Em outras palavras: quando se argumenta a favor de uma arquitetura centralizada, de uma filosofia única ou de integridade conceitual, isso não significa que sucesso por si só.
Integridade conceitual é um atributo de um bom projeto de sistema, mas isso não significa que se agora você começar a escrever um documento de duzentas páginas antes de desenvolver cada sistema isto vai garantir alguma coisa.
Cada conceito, processo ou filosofia precisa ser contextualizada para a sua realidade. Dentro daquilo que você faz hoje em desenvolvimento de software, o que você pode fazer para obter mais integridade conceitual?
Para alguns isso pode significar eleger uma pessoa experiente da equipe, não necessariamente um líder, que seja responsável por acompanhar as decisões dos demais desenvolvedores sobre o sistema. Para outros, pode significar envolver o analista de negócios antes de tomar decisões sobre as funcionalidades do sistema. Ou talvez fazer uma demonstração semanal do sistema para o product owner e alinhar as realizações e expectativas.
A importância de um líder
Um projeto com integridade conceitual precisa ter alguém liderando os demais para um objetivo comum. Não estou falando de alguém para simplesmente mandar nos outros.
Cada pessoa tem seus objetivos e expectativas particulares. Se você é desenvolvedor com alguma experiência, já deve ter notado que quase sempre o que você gostaria de fazer num sistema não bate com o que seus colegas, líderes e os usuários querem.
Independente de quem tem razão, a falta de uma visão comum faz com que cada um persiga sua visão particular do sistema e isso frequentemente faz com que no final nenhum objetivo concreto seja bem realizado. Um bom líder deve, acima de tudo, garantir essa que visão comum, além de ser adotada por todos, atenda as reais necessidades dos clientes.
Infelizmente, Brooks não trata sobre o que fazer quando o arquiteto ou líder persegue uma visão errada. Talvez isso requeira um mais livro completo. Mas, se quem está na liderança tomar o rumo errado, por mais capacidade técnica e boas intenções que a equipe tenha, o projeto está fadado ao fracasso.
Esse é um dos motivos que me faz temer líderes (e pessoas em geral) que tem certezas demais sobre tudo. 😉
