O livro mais recente de Jaroslav Tulach, Projeto Prático de API, trata de como projetar API's de software. Jaroslav discute a importância do projeto de API's nos aplicativos modernos, quais são os diferentes fatores que compoem uma boa API, e como implementar frameworks de API. Ao escrever este livro, ele nos trás a experiência como arquiteto do projeto NetBeans IDE. No livro, Jaroslav comenta sobre muitos exemplos reais e como (e mais importante, como não) usar a API do Java, baseado em sua experiência de trabalho no projeto NetBeans.
InfoQ conversou com Jaroslav sobre seu novo livro, a principal motivação para escrevê-lo e outros assuntos. Os tópicos descritos na entrevista incluem estimativa e validação de qualidade de software, o papel das metodologias de desenvolvimento ágil e lean no projeto de frameworks e arquitetura de API's e análise de projetos.
Disponibilizamos também um extrato (~4 MB PDF - em inglês) do livro Projeto Prático de API para nossos leitores.
InfoQ: Qual foi sua motivação para escrever o livro "Projeto Prático de API"?
Jaroslav Tulach (JT): O livro é baseado em anotações que juntei nos últimos dez anos enquanto eu projetava e mantinha as API's do NetBeans. Além disso, também é baseado no processo de transferência de conhecimento das API's do NetBeans para o resto da equipe de desenvolvimento do NetBeans. Eu comecei a pensar em transformar minhas anotações em um livro há cerca de 5 anos. No entanto, demorou um pouco mais até que eu realmente iniciasse. Em vários momentos, outras atividades tomaram meu tempo. Em outros, eu simplesmente temia não ser capaz de terminar o livro, além do temor de ser rejeitado pelos editores, etc.
Entretanto, no verão de 2007, eu conversava com o sobrinho de minha esposa numa festa de família. Quando contei a ele minhas dúvidas, ele disse: "Você sabe o que escrever; você sabe que é um assunto interessante; você sabe que é uma autoridade no assunto. Então... por que você ainda não começou a escrever o livro?".
Eu sempre me lembrava dessa conversa quando faltava motivação para terminar o "Projeto Prático de API", o que já é esperado nesse tipo de projeto, que demora muito. A propósito, eu gostaria de aproveitar a oportunidade para agradecer a todos que me ajudaram a terminar o livro.
InfoQ: No livro, você discutiu a técnica de "Component Injection" para alcançar uma Arquitetura Modular. Que papéis conceituais de projeto como Dependency Injection (DI), Programação Orientada a Aspectos (AOP), e Anotações podem atuar no desenvolvimento de software em geral e, em particular, no projeto de API?
JT: Eu acredito que é muito desejável modularizar aplicações em partes distintas. E é muito melhor quando essas peças não conhecem os detalhes umas das outras, de forma que alguém possa montar uma aplicação composta de várias partes independentes. Para permitir esse tipo de composição a partir de peças fracamente acopladas, é essencial haver alguma forma de injeção. Dependency injection no estilodo Spring é bem-vinda. java.util.ServiceLoader também funciona. Eu dediquei o capítulo 7 do livro para compará-las entre si e também com outras alternativas.
Houve um tempo que as pessoas piravam quando ouviam a frase "manipulação de bytecode". Isso não acontece mais. Hoje em dia as pessoas não têm mais medo de executar um bytecode diferente daquele gerado pelo compilador Java. Por outro lado, se você disser para elas irem diretamente ao arquivo .class e manipular o bytecode diretamente, o medo volta. Por quê? Eu acredito que ê por causa da Programação Orientada a Aspectos (AOP). A AOP torna normais as mudanças no bytecode sem exigir conhecimento do formato do arquivo .class. De fato, a AOP pode ser vista como uma linguagem de alto nível para manipulação de bytecode. Ela não é tão poderosa quanto se você modificasse o .class diretamente, mas ainda assim é acessível às massas e genericamente entendida. Esse exemplo ilustra o princípio de que boas abstrações fazem tudo ser mais usável. Esse princípio é válido no mundo da manipulação do bytecode assim como no projeto de API.
Nós começamos fazendo uso maciço de anotações durante o desenvolvimento da próxima versão do IDE NetBeans. Basicamente, estamos definindo novas anotações como uma fachada de nossa antiga API baseada em XML. Durante a compilação as anotações são processadas pelos nossos processadores de anotações. No final do processo, o XML correto (antigo complexo) é gerado. Nem consigo explicar como estamos felizes com essa solução! De repente nossas API's ficaram muito mais legais. O registro de informação agora faz parte do código fonte Java. O completamento de código automaticamente funciona nos IDEs. Todos os registros são verificados se estão corretos durante a compilação. Baseado nessas experiências, eu só posso recomendar anotações em tempo de compilação para todos os projetistas de API!
InfoQ: Você escreveu no livro sobre como verificar a qualidade de uma biblioteca de API. Você pode comentar como as equipes podem ter garantia e validação permanente da qualidade do software que estão desenvolvendo?
JT: O senso comum entre os programadores é que o projeto não pode ser feito por um comitê. Entretanto, como podemos projetar sistemas que têm aumentado de tamanho sem projetá-los em equipe? Não funciona numa equipe sem muita consistência? Sim, em parte. A maioria das pessoas parecem ser capazes de manter a consistência no projeto quando trabalham sozinhas. Por outro lado, os projetos de softwares atuais, e os futuros, serão projetados por equipes. É muito mais difícil manter a consistência nesses ambientes, mas certamente é possível.
Normalmente você tem duas alternativas: detectar diminuições na qualidade quando elas acontecem ou prevenir esse tipo de problema antes de serem integrados. Eu dediquei todo o capítulo 16 a esses assuntos. Lá eu descrevo quais aspectos precisam ser verificados e validados e como fazer isso automaticamente. Dessa forma, nós podemos estar preparados para quando as coisas começarem a ir mal. O capítulo também introduz um processo de "Revisão de API", que a equipe do NetBeans está seguindo para revisar as mudanças na API antes de fazerem a integração. Dessa forma nós podemos nos prevenir contra as regressões antes mesmo de pensarmos nisso.
InfoQ: Como as metodologias ágeis e lean como SCRUM, XP e Kanban podem ajudar uma equipe envolvida no projeto e desenvolvimento de API?
JT: A questão é se as metodologias ágeis ajudam o projeto e desenvolvimento de API's... ou se a modularização correta de uma aplicação e a divisão dela em muitas bibliotecas com API's simplificaria o uso das metodologias ágeis. Ambas provavelmente são verdadeiras.
Existem muitas regras no mundo do projeto de API. Por exemplo, você precisa ter consciência de que a primeira versão de sua API não será perfeita. Também, você precisa imaginar quem serão seus usuários. Dois outros princípios básicos são que os testes unitários são praticamente obrigatórios e que você deveria sempre projetar sua API de forma que ela estivesse pronta para uma melhoria futura.
Muitas desses conselhos estão perto de ser as regras que também governam as metodologias ágeis. Dessa forma, eu penso que o projeto correto de API e as metodologias ágeis podem fortaceler uma à outra.
InfoQ: Você pode contar como sua equipe conduziu as revisões de arquitetura e de projeto no desenvolvimento do NetBeans?
JT: Nós temos dois modos: a revisão padrão e a revisão rápida. A última é usada para mudanças pequenas, incrementais, compatíveis e não-polêmicas. Ela é baseada na "estratégia de bloqueio otimista": você prepara a diferença na mudança do código e anexa isso ao sistema de controle de problemas. As pessoas então têm uma semana para comentar ou vetar a mudança. Se ninguém se opuser dentro desse tempo, a mudança pode ser aplicada imediatamente. Isso funciona bem para mudanças em métodos isolados ou extensões de classe para bibliotecas já existentes.
A revisão padrão é direcionada a novas bibliotecas ou subsistemas. É uma revisão de dois rounds. Primeiro, nós revisamos o conceito. Então, se o conceito é aceito, o resultado é revisto novamente antes de ser integrado no repositório principal de código. Todos os detalhes de revisão são documentados no website do NetBeans.
InfoQ: Quais são as melhores práticas e as "pegadinhas" que os arquitetos de software devem ter em mente quando trabalharem com bibliotecas de componentes reusáveis?
JT: É difícil enumerar todas elas... isso me tomou 400 páginas no Projeto Prático de API. :-) Mas vamos nos ater em algo interessante: "O que você acha que está relacionado ao nome API?" O nome das classes? Provavelmente. Os nomes dos campos ou métodos? Sim, se são public ou protected. Mas isso é tudo?
Não, não é. Você alguma vez já pensou que os arquivos que seu aplicativo lê são uma API? E que os sockets abertos também são uma API? E as variáveis de ambiente? E as mensagens traduzidas? E que tal as mensagens de saída produzidas por seu código? Tudo isso pode influenciar o comportamento da sua aplicação ou sua biblioteca. Eles também podem ser observados e usados externamente. Da mesma maneira, também é um tipo de API. É muito importante saber isso e nunca esquecer.
InfoQ: Qual é o papel que os arquitetos de software na economia atual e nas condições atuais do mercado?
JT: Pergunta difícil. A resposta comum é que eles devem aprender a oferecer o que o mercado precisa. Mas suspeito que ninguém realmente saiba o que seja. Exceto...
... um dos problemas no desenvolvimento de software está relacionado com as mudanças "big bang", isto é, situações onde você encontra seu produto repleto de bugs e problemas de projeto, de modo que não pode ser consertado, exigindo reescrevê-lo do zero. Demora muito tempo até chegar nesse ponto, já que as evidências precisam crescer ao longo do tempo, com várias releases. Entretanto, existe um ponto no ciclo de vida da maioria dos projetos onde alguém sugere fazer uma mudança "big bang". Inicialmente, a proposta é recusada porque todo mundo sabe que a reescrita será dolorosa e cara. Então, durante as próximas releases, quando as evidências aparecem mais, a equipe se dá conta que não há outra saída. Nesse ponto, o projeto inteiro é interrompido, o desenvolvimento de um subsistema incompatível é forçado, e então as outras equipes precisam adaptar-se à mudança. Independente de quão realista os planos originais foram, esse processo normalmente leva mais tempo do que o esperado. E, no final, temos um produto novinho em folha que tem muito menos bugs do que o original, mas que também cuida apenas da metade dele. Não preciso dizer que esse processo não é muito bom.
O livro Projeto Prático de API descreve as melhores práticas para evitar a necessidade dessas mudanças "big bang". Para começar, ele explica o que significa compatibilidade e prega mudanças pequenas, incrementais e compatíveis com o código existente, mas sempre focando na melhoria futura. Esse modelo não precisa, de forma alguma, das mudanças "big bang" que quebram a compatibilidade reversa. Por outro lado, às vezes algumas mudanças bruscas são necessárias. Esse é o motivo pelo qual o livro discute algumas formas de permitir a convivência dos diferentes comportamentos e explica como ligá-los, quando necessário.
Se modularizarmos nossas aplicações e tratar cada peça como uma biblioteca de API, podemos minimizar a necessidade das mudanças "big bang" que param o mundo e substituí-las por melhorias constantes espalhadas por todo o código. Talvez essa proposta seja mais cara a princípio, mas a longo prazo o custo de propriedade é definitivamente menor.
Dito isto, vamos à resposta para sua pergunta inicial: "Talvez os arquitetos de software devessem aprender mais sobre o projeto correto de API e usá-lo para criar equipes com melhor custo-benefício."
InfoQ: Qual a sua opinião sobre as novas funcionalidades e APIs que virão na versão 7 do JDK e sobre os recursos abandonados, como Closures?
JT: A primeira coisa que precisa é um módulo de sistema padrão adotado por todos. Recentemente, eu conversava com um programador Ruby sobre os benefícios de projeto de API em Ruby. Inicialmente, parecia que "duck typing" era a maior vantagem do Ruby. Agora todos vemos que a maior vantagem real do Ruby são suas "gems" com todas suas dependências entre bibliotecas... enquanto Java não tem nada. Isso precisa ser corrigido.
Eu sei que existem módulos de sistema. A propósito, um desses roda sob o IDE NetBeans. Entretanto, nem toda biblioteca do mundo é projetada com modularidade em mente. Isso precisa mudar. É necessário haver suporte para modularidade na própria linguagem Java. Eu não me importo de esperar alguns anos pelas closures, se pudermos ter agora a modularidade no Java.
InfoQ: Se você pudesse escolher uma característica que mais gosta na linguagem Java, qual seria? E a que você menos gosta?
JT: Dizem que Java tem muitos pontos fracos. Entretanto, eu acho que uma de suas fraquezas é também uma grande vantagem: Java é conhecido por ter verbose. É verdade, você consegue escrever programas menores que fazem a mesma coisa em muitas outras linguagens. Portanto, Java tem verbose. No entanto, o benefício disso é que as pessoas também conseguem ler o que elas escreveram. Os programas Java podem ser lidos e entendidos pelo pessoal da manutenção. Além disso, isso pode ser feito numa página impressa, sem a necessidade da funcionalidade de "ir à declaração" e da característica de "completamento de código" do seu IDE. Eu acho que não estou plenamente satisfeito com a verbosidade do Java, mas eu gosto da possibilidade de se ler o código que isso permite.
InfoQ: Por último, você recomendaria algum outro livro de TI e um livro sobre outra área, para nossos leitores?
JT: Meus livros de referência são Effective Java e Gang of Four's Design Patterns. Eles são leitura obrigatória e são muito bem conhecidos.
Além desses eu também recomendo um livro perfeito escrito por Petr Vopenka sobre a história da geometria: "The Key Stone of European Knowledge". Pode parecer chato a princípio, mas não é eu fiquei apaixonado por ele. Muitas das partes "filosóficas" do meu livro são baseadas nele. Então se você pertence à turma que acha essas partes interessantes, eu recomendaria prestar atenção a esse livro. Só há um problema: ele ainda não foi traduzido para o inglês (nem para o português).
InfoQ:Obrigado, Jaroslav.