O desenvolvimento de software já teve vários assuntos da moda. Lembro da moda de design patterns: as pessoas colocavam com orgulho no currículo o conhecimento de patterns. Agora design patterns estão fora de moda; aparentemente as pessoas estão se preocupando mais com frameworks / tecnologias específicas e aspectos gerenciais do que questões de design.
Por mais que eu não concorde com essa priorização, a moda faz sentido. Modas desse tipo não são uma mera questão de preferência pessoal ou a visão de alguma celebridade da área. O avanço das tecnologias é tão grande que frameworks resolvem grande parte dos problemas com simplicidade e, com isso, a gestão se tornou novamente o gargalo.
O interessante das modas é que elas são cíclicas… Sim, já houve uma moda sobre aspectos gerenciais. Isso não quer dizer que voltaremos a falar de design patterns; apesar de cíclica, há uma evolução. Então quando a moda de design voltar – e ela vai voltar -, outras questões de design serão importantes.
Todo esse preâmbulo é para falar do livro Clean Architecture, do Robert C. Martin. Como todo livro do “tio” Bob, ele é bem escrito e tem uma leitura fácil e recheada de relatos de experiência interessantes e alguns insights. Porém, até a parte 5 – lá se vão 14 capítulos – o livro é praticamente uma revisão de um outro livro dele, Agile Software Development: Principles, Patterns, and Practices. Porém é uma revisão para quem já conhece os conceitos. Ela não é muito profunda, usa algumas vezes os mesmos exemplos, mas ainda assim apresenta alguns pontos interessantes. Mas nada que justificaria a leitura do livro.
A discussão interessante começa a partir daí. O livro então entra em algumas polêmicas interessantes. A primeira delas é que arquitetura não pode ser desassociada de um bom design e, portanto, um bom arquiteto precisa ser antes de tudo um bom desenvolvedor. As outras polêmicas: banco de dados (BD), frameworks e web são detalhes. Sim, isso é pesado.
Pessoalmente eu concordo com tudo isso.
Pior que concordar, eu defendo isso nas minhas aulas há anos… Vários alunos meus de pós-graduação já se assustaram com a minha afirmação que BD é um detalhe (como o Paulo Muniz, meu amigo e orientador, bem ressalta, BD talvez seja o detalhe mais importante de um projeto). O capítulo de frameworks traz uma metáfora especialmente interessante ao dizer que um projeto “casa” com um framework. Com tantas alternativas de noSQL, eu diria que nós também casamos com BDs relacionais sem saber se ele é realmente “o nosso par ideal”. Então é motivador ver um livro que faz essas afirmações sem medo.
Além dessas polêmicas, o livro apresenta outras boas discussões sobre arquitetura e design. Note que são discussões avançadas; um programador novato provavelmente não irá entender nada. Um outro detalhe curioso é que o livro é recheado de diagramas UML (apesar de uma nota de rodapé discutível na página 300) e apresenta casos de uso. Para alguns agilistas, isso pode parecer um absurdo: como assim ele cria diagramas e não usa histórias? Para mim isso mostra claramente algo bastante simples: não existe uma técnica ideal. Use o que for melhor para o que você precisa.
Em conclusão, é um livro interessante e polêmico que vale a pena ler. Mas leia antes o livro Agile Software Development; se você for um programador novato, ganhe um pouco de experiência – se divirta um pouco desenvolvendo software antes de ler.
Muito bom, pretendo ler em breve!i