Prazo e Escopo: Uma questão de qualidade - I

Bem, em primeiro lugar um feliz 2010 a todos.

Agora, vamos direto ao assunto: O escopo precisa estar equilibrado com o prazo para que seja garantido um nível mínimo de qualidade para a aplicação. Ponto final. Não existe outra forma para isso funcionar. Não entendo como tentam formulas mágicas para economizar na análise, construção e testes, para gastar rios de dinheiro com a manutenção. Simplesmente não funciona. Vamos verificar as partes prejudicadas, quando temos muitos bug-fixes:

• Cliente: Perde dinheiro de forma indireta com os bug-fixes durante o período de garantia, pois uma aplicação que deveria estar funcionando não está. Fora da garantia, perde dinheiro diretamente;
• Consultoria: Perde workforce durante a garantia. Se ainda necessitar de muitos bug-fixes depois da garantia perde a confiança e satisfação do cliente. Poderia estar ganhando mais dinheiro e tendo menos dores de cabeça.

Frederick P. Brooks JR, em seu livro The Mythical Man-Month, no segundo capítulo, estampa o cardapio de um restaurante de Nova Orleans, o Antoine, que diz o seguinte: "Good cooking takes time. If you are made to wait, it is to serve you better, and to please you."

No livro, Brooks afirma que esta relação Homem-Mês só pode ser usada em atividades que não necessitam de constante comunicação entre as partes, como colher milho, por exemplo. Neste tipo de atividade, contratar mais pessoas reduzirá o tempo necessário para completar as tarefas.

"Isso implica em dizer que Homem-Mês são intercambiáveis. Homem e mês só podem ser considerados intercambiáveis quando a tarefa pode ser dividida entre as pessoas, sem necessidade de comunicação entre elas."

Outro trecho interessante deste capítulo é: "The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debbugging". E continua no parágrafo seguinte: "If a task can be partitioned but which require communication among subtasks, the effort of communication must be added to the amount of work to be done."

Outro ponto considerado é a preparação necessária destas novas pessoas, totalmente alheias ao projeto. Uma boa documentação reduz esse impacto. Mas a passagem de conhecimento deve ser efetuada, e vai consumir tempo.

Dessa forma, surgiu a lei de Brook que diz o seguinte: “Adding manpower to a late software project makes it later”, e acredito que ainda teremos muito para falar sobre o livro neste espaço. Um artigo interessante pode ser encontrado aqui.

O problema não é meu - Esclarecimentos - Parte III

É bom deixar claro uma coisa. O ponto central destes dois (agora três) artigos é tentar combater a cultura enraizada do "está funcionando, não mexe".

Ouvi, ouço e acredito que ainda vou ouvir isso de muitos analistas, inclusive experientes.

A questão do cliente precisa ser mais detalhada.

Em primeiro lugar, quero deixar claro que me refiro a todos os clientes com que trabalhei. Alguns lidam melhor com essa situação, outros não. Inclusive nesse aspecto, creio que a responsabilidade de provar que a melhoria constante no código é um benefício, seja do analista.

Estamos falando de um nível muito baixo no desenvolvimento, o código. O cliente não tem a obrigação de ter visibilidade, o gerente da equipe normalmente não tem e a questão repousa no colo dos líderes técnicos e analistas. Mais especificamente dos analistas, pois estes estão em contato permanente com o código.

Acredito que a nossa área ainda encontra-se em fase de maturação, e vai demorar para que tenhamos uma equalização do conhecimento da importância da qualidade, por todos os níveis envolvidos no processo.

Se o cliente não bancar uma melhoria, o gerente fica sem ação (fica só tomando pancada nas reuniões), o líder menos ainda e o analista, quando psicopata, vai arcar com a melhoria do código. Por outro lado, um analista sem voz, não consegue convencer o líder, este não vai convencer o gerente e este não vai convencer o cliente. Ovo e a galinha?

É claro que estou pintando o pior cenário, quando nem o líder técnico crê nos benefícios da qualidade.

Neste cenário, só vejo uma forma de quebrar esse circulo vicioso. O analista mostrar, praticamente, que estas melhorias vão gerar valor para o cliente e poderá aumentar a sua margem de lucro, com a redução dos custos de manutenção.

Agora vamos a outra questão que está sempre batendo à minha porta. Por que foi codificado sem preocupação com a qualidade?

Em primeiro lugar, prazos e metas agressivos demais. Nada é mais frustrante do que trabalhar com prazo estourado ou sabendo que o prazo vai estourar de qualquer forma.

Agora vamos analisar a estrutura mais comum de uma equipe.

Temos um sênior, dois plenos e três estagiários.

O sênior faz as especificações, os plenos cuidam da codificação complexa e os estagiários funcionam como code-monkeys. Na minha visão, é correto o papel de code-monkey dos estagiários, já que nossas faculdades não formam bons júniores. Quando muito, dá muito conhecimento teórico e nada sobre boas práticas, desenvolvimento corporativo, etc. Com a repetição, o estagiário aprende "na marra".

Claro que falta a figura do arquiteto e dos juniores, mas para a explicação, creio que esta estrutura seja suficiente.

Voltando. O sênior especifica como a coisa deve ser feita e cuida dos códigos complexos. Os plenos cuidam dos códigos complexos. Os estagiários cuidam do serviço repetitivo, como a criação dos DAOs. Notar que não estou entrando no mérito se DAO é bom ou ruim, é apenas exemplificação.

Um dos meus contratos com a equipe, como especificador, são as interfaces. Se não monto uma interface com qualidade para os DAOs, como os estagiários farão um trabalho decente? Difícil. Se monto uma interface com o metodo "add" lançando uma Exception (sic!), como o estagiário saberá que isso é uma péssima prática? Ele vai lançar Exception até se a mãe dele vier a pedir alguma coisa.

Se estou criando uma arquitetura baseada em VO e BO, como explicar para ele que trata-se de um modelo anêmico? Neste outro excelente artigo, Fowler fala sobre o modelo anêmico e a má utilização da Service Layer.

Quase sempre a culpa cai nos ombros dos pobres estagiários, mas vejo isso muito mais como um problema de quem está acima. O estagiário está ali para aprender.

Então, contrário do que muitos podem estar pensando, não creio que a implantação da qualidade, como pedra fundamental da área de desenvolvimento de softwares, seja algo simples.

É necessário mudar muita coisa em muitos lugares. Mas temos que começar de alguma forma.

O problema não é meu - Parte II

Bem, vamos ao que interessa: Quando fazer as alterações não contempladas em um chamado? Como fazer de forma segura? Como ser eficiente para não afetar as metas?

Quero assegurar, mais uma vez, que o descrito nesse artigo ou em qualquer outro neste blog, expressa apenas a minha opinião, não a do meu empregador ou clientes.

Antes, vou reforçar, com um exemplo, o que foi escrito no último post.

Assumi uma aplicação em Delphi que é relativamente simples, mas foi programada com uma complexidade desnecessária. Na última melhoria solicitada, relativamente complexa, resolvi criar algumas classes para a área da aplicação que seria impactada.

Comecei a colher os benefícios da OO ainda neste chamado, já que esta modificação gerou outras necessidades do cliente. Com o código antigo, eu levaria cerca de uma hora para resolver cada necessidade. Com a OO, consegui resolver em cerca de 15 minutos cada uma. Um quarto do tempo. Também é digno de nota que a alteração em uma classe resolveu cerca de um terço das necessidades.

Eu deveria ter colocado o início do parágrafo anterior no plural, pois todos os envolvidos foram beneficiados:

• Cliente - Para este, o ganho é claro, pois pagou cerca de 25% do valor que pagaria antes das alterações. Teve os seus problemas corrigidos de forma mais ágil e o impacto no negócio foi mínimo. Mesmo assim, é difícil mostrar para o cliente os benefícios de um código limpo e bem estruturado;
• Consultoria - Mesmo parecendo que deixou de ganhar com o tempo das correções, a equipe que antes estaria perdendo muito tempo com estas correções, pode estar dando atenção a outros assuntos. Já atuei em consultorias pequenas, médias e grandes e posso garantir que até as pequenas, normalmente, tem mais problema que braço;
• Desenvolvedor - A fila de to-do de um desenvolvedor, normalmente, não é pequena. Perda de meta sempre estoura no colo do analista. Com códigos mais eficientes, as correções irão durar menos tempo e é mais provável que as metas sejam cumpridas.

Agora que já coloquei, mais uma vez, a minha visão de como um código bem estruturado beneficia a todos, vamos as perguntas:

Quando fazer as alterações não contempladas em um chamado?
A resposta a essa pergunta é complicada, porque, normalmente depende de vontade do Analista. Eu, como bom psicopata e vislumbrando uma vida melhor no futuro, faço essas alterações fora do horário do expediente. Cobro do chamado o tempo que eu levaria para atender sem a refatoração. Alguém diria: "Mas nem relógio trabalha de graça". Nesses casos, eu trabalho.

Onde fazer essas alterações?
Esta pergunta não estava inicialmente programada, mas achei pertinente. A melhoria de código deve ser executada nos módulos ou artefatos impactados pela mudança solicitada no chamado. Dessa forma, outras áreas não serão impctadas e as alterações serão exaustivamente testadas pelas equipes de teste.

Como fazer de forma segura?
Em primeiro lugar, mexendo só na área impactada pela solicitação do cliente. Dessa forma, asseguramos que as alterações estarão no escopo das equipes de testes. Em segundo lugar, fazendo o que venho marretando em alguns fóruns ao longo do tempo, coberto por testes. Refatorar sem uma suite de testes bem feita é suicídio.

Como ser eficiente para não afetar as metas?
Respondi a essa pergunta na primeira resposta. Para um futuro melhor, até enfiar na cabeça de cliente e consultoria que melhoria de código é bom para todo mundo, faço isso de graça, fora do expediente.

Para finalizar, como considero isso um assunto polêmico, volto a dizer que isso reflete a minha opinião e não as dos meus colegas analistas, gerentes, consultoria, cliente ou qualquer outra pessoa que venha a se sentir ofendido com as minhas palavras.

Nota: Trabalhar de graça, não me motiva, não me deixa mais feliz. É lamentável a visão que ainda temos hoje do "está funcionando, não mexe". O que me deixa feliz é ver o código novo na próxima manutenção. Isso torna o trabalho prazeiroso.

Nota 02: Não refatoro apenas código legado de outras pessoas. Vivo tentando aperfeiçoar o meu trabalho. E fazer isso de graça no meu código, devo confessar, quase é um prazer.

O problema não é meu - Parte I

Devo desculpas aos amigos que acompanham este singelo espaço, por não escrever nenhum artigo há muito tempo. Infelizmente isso deve ser comum neste próximo ano. Estou em uma equipe que atua com BPM e estamos implantando este conceito em uma das maiores empresas do Brasil.

Já vinha estudando sobre gerenciamento de processos desde fevereiro deste ano, época da minha primeira passagem pela equipe. Tive uma rápida passagem por ETL e, há dois meses, estou de volta ao BPM. Aprendi muitas coisas neste período, principalmente a lidar com a diversidade de profissionais. E é justamente esse o ponto central desta pequena série. Tenho trabalhado com o ALBPM e com um Java que não é Java, mas é Java. Sim, a coisa é meio confusa. Entretanto, existem aplicações puramente Java que auxiliam o sistema como um todo, como as consultas.

Bem, como eu disse, o ponto central deste post é a diversidade de profissionais.

Quando somos jovens, com o excesso de energia que é peculiar desta idade, e encontramos códigos que não estão em boa forma (good shape), a reação mais natural é criticar. Entretanto, quando amadurecemos e olhamos para nossos próprios códigos do passado, com os olhos do conhecimento que adquirimos durante os anos, percebemos que já desenvolvemos de forma amadora. A evolução é algo natural (ou deveria ser) e, naturalmente, tendemos a achar ruim hoje, o que fizemos ontem. Assim, considerando apenas os profissionais que estão preocupados com a sua carreira, não existem bons ou ruins e sim, profissionais que estão em diferentes níveis de carreira.

Acredito que os três níveis tradicionais de analista - júnior, pleno e sênior - não são suficientes para expressar os níveis reais da carreira. Acho que poderiamos explodir o pleno em mais três níveis (como baixo, médio e alto). Reforço que estou me referindo aos profissionais que realmente se preocupam com a sua carreira, que estudam e buscam o aprimoramento, mesmo nos horários de folga.

Dentro deste grupo de profissionais, considero o analista bom ou ruim baseado na sua reação quando encontra um código ruim pela frente. Você diz, isso não é problema meu?

Deixa eu explicar melhor. Nas grandes empresas, é natural assumir aplicações legadas, que chamo, carinhosamente, de filhas adotivas. É natural também, que estas aplicações tenham passado pelas mãos de muitas pessoas. Estas pessoas, obviamente, se encontram em níveis diferentes de conhecimento.

Com aplicações em produção, é comum atendermos chamados solicitando melhorias ou correções (bug-fixes). É neste momento que podemos (e devemos) fazer a diferença.

Se você está no grupo de pessoas que afirmam que um código legado mal feito não é um problema seu, está na hora de rever conceitos e, talvez, se tornar um pouco mais psicopata.

Acredito que o pior cenário para fazer melhorias de código, seja o de grandes empresas, por inúmeros fatores, alguns exemplos:

• Ambiente de produção fora do seu controle: Geralmente os processos de deploy e restart de servidores de aplicação não estão nas mãos dos analistas e sim de uma equipe especializada;
• Muitas camadas de testes antes de um deploy: Normalmente, os únicos testes que estão na mão dos analistas são os unitários. Outros testes como os integrados e regressão, estão nas mãos de equipes especializadas em testes.

Estes exemplos mostram como pode ser complicado "subir" alguma modificação motivada "apenas" por melhorias no código. Como um outro post, já planejado, pretende mostrar, o cliente, normalmente, não está preocupado com isso. Não concordo com essa visão, entretanto expor meu ponto de vista sobre esta situação não é propósito deste post.

Estes motivos, na minha visão, já são suficientes para tornar nosso o problema.

Assim, um chamado de melhoria ou correção é uma ótima oportunidade de deixarmos a nossa vida um pouco mais tranquila no futuro. Como? Só vejo uma forma, sendo psicopata.

O meu tempo, como a da maioria das pessoas que frequenta este blog, é escasso. Assim, quando fazer as alterações não contempladas em um chamado? Como fazer de forma segura? Como ser eficiente para não afetar as metas?

Estas perguntas serão respondidas no próximo e último post dessa série. Até lá.

Integrando JSF 1.2 com Richfaces e EJB3 utilizando JBOSS AS 5 e Eclipse - Parte I

Como encontrei pouquíssimas fontes de consulta sobre o assunto em sites brasileiros, resolvi escrever esse artigo que visa exemplificar uma das formas de se integrar com sucesso esses três frameworks em sua aplicação. Foi a solução que implementei em meu projeto e espero que seja de utilidade para outros desenvolvedores que possam estar passando pelos mesmos problemas que eu enfrentei para deixar a aplicação funcionando 100% sem bugs.

Esse é meu primeiro artigo e minha intenção é ajudar a comunidade pois obtenho muita ajuda em fórums e outros artigos, por isso quem notar alguma dificuldade me relate mas sem stress! =)

Em primeiro lugar, tenha certeza de possuir todas as libs necessárias. Caso não possua alguma das libs listadas abaixo, coloque o nome do JAR no Google que com certeza várias fontes para download estarão disponíveis. As libs do JBoss vem junto com o servidor, voce deve usá-las para evitar do Eclipse ficar exibindo erros de falta de bibliotecas em cada linha de código que voce escrever que vá usar algum componente de EJB dentro do seu projeto web.

Esse artigo toma por base que você ja saiba como trabalhar com EJB mas nao sabe como utiliza-lo nos seus projetos com JSF.

COMMONS

• commons-beanutils.jar
• commons-collections.jar
• commons-logging.jar
• commons-digester.jar
• commons-codec-1.3.jar
• commons-discovery-0.4.jar
• commons-el.jar

JBOSS

• Libs do diretorio "client" do jboss

JSF

• jsf-api.jar
• jsf-impl.jar

JSTL

• standard.jar
• jstl.jar

Richfaces

• richfaces-api-3.3.0.GA.jar
• richfaces-impl-3.3.0.GA.jar
• richfaces-ui-3.3.0.GA.jar

Outras LIBs

• jsr250-api.jar
• jsp-api.jar
• tomahawk-1.1.6.jar

Listei a api Tomahawk por ela ter me facilitado muito a vida em algumas coisas que a JSF sozinha não conseguiu realizar.

Essas libs devem ser copiadas para o diretorio: <raiz_do_seu_jboss>/server/default/lib e o servidor deve ser reinicializado para reconhecer as novas libs.

Voce tambem poderá marcar as libs para exportação dentro do Eclipse marcando as mesmas na configuração do build-path na guia "Order and Export". Porém as libs abaixo NÃO devem ser marcadas para exportação caso esse método seja escolhido:

Libs do diretorio client do Jboss

• jsf-api.jar
• jsf-impl.jar

OBS: Eu não recomendo esse método por deixar o arquivo war final muito grande.

Configuração do diretório web-inf
Desenvolvendo meu projeto, percebi que intermitentemente as tags disponíveis nos TLDs de algumas bibliotecas ficavam indisponíveis como se o container não conseguisse localizar o TLD da tag corretamente. Eu precisava sempre reiniciar o servidor e torcer para que ele localizasse os TLDs nos diretorios META-INF dos JARs das bibliotecas, coisa que nem sempre acontecia. A solução que encontrei para acabar com isso, foi copiar algumas TLDs diretamente para o diretório WEB-INF. Dessa forma, caso você passe por problema semelhante, será necessário copiar os seguintes TLDs para dentro do seu diretorio WEB-INF:

• a4j.tld
• ajax4jsf.tld
• rich.tld
• richfaces.tld
• tomahawk.tld

Esses TLDs podem ser encontrados dentro dos diretorios META-INF das suas respectivas bibliotecas.

Configuração do web.xml
Adicionar as seguintes tags no web.xml para configurar o JSF:

<welcome-file-list>
   <welcome-file>index.jsf</welcome-file>
</welcome-file-list>

<context-param>
   <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
   <param-value>server</param-value>
</context-param>

<context-param>
   <param-name>javax.faces.CONFIG_FILES</param-name>
   <param-value>/WEB-INF/faces-config.xml</param-value>
</context-param>


<servlet>
   <servlet-name>Faces Servlet</servlet-name>
   <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
   <load-on-startup>1 </load-on-startup>
</servlet>


<servlet-mapping>
   <servlet-name>Faces Servlet</servlet-name>
   <url-pattern>*.jsf</url-pattern> // extensao que o cliente web utilizará. Pode ser qualquer coisa.
</servlet-mapping>

Observe que a tag <welcome-file-list> aponta para um arquivo index.jsf que deve ser criado em branco com esse nome na raiz da aplicação. É uma técnica utilizada para "enganar" o container de forma que você consiga acessar sua pagina inicial (index.jsp) sem precisar digitá-la no navegador e trabalhando com JSF, voce provavelmente terá problemas com isso se não proceder dessa forma.

É possível alterar a extensão pela qual suas páginas responderão no navegador do cliente. Voce poderá configurar a extensão que quiser (*.jsf, *.java, *.abacaxi, etc). Portanto voce nao esta preso a utilizar 'index.jsf' e 'index.jsp' como suas páginas, voce pode configurar como desejar no welcome-file-list e no <servlet-mapping> de Faces Servlet.

Para configurar o Richfaces, é necessário adicionar as seguintes tags:

<filter>
   <display-name>RichFaces Filter</display-name>
   <filter-name>richfaces</filter-name>
   <filter-class>org.ajax4jsf.Filter</filter-class>
</filter>

<filter-mapping>
   <filter-name>richfaces</filter-name>
   <servlet-name>Faces Servlet</servlet-name>
   <dispatcher>REQUEST</dispatcher>
   <dispatcher>FORWARD</dispatcher>
   <dispatcher>INCLUDE</dispatcher>
</filter-mapping>

<context-param>
   <param-name>org.richfaces.SKIN</param-name>
   <param-value>blueSky</param-value>
</context-param>

blueSky é o tema padrão utilizado nos componentes do richfaces. Temas diferentes podem ser configurados por essa tag.

Configuração do faces-config.xml
É aqui que a integração com o EJB começa a tomar forma. O faces-config.xml é um arquivo XML com a seguinte estrutura básica:

<faces-config>
   <managed-bean>

   (configuração do bean)

   </managed-bean>
</faces-config>

A tag <managed-bean> é a tag que voce é responsável por configurar para integração de seus EJBs no JSF. Abaixo segue um exemplo de um <managed-bean> básico configurado:

<managed-bean>
   <managed-bean-name>exemplo</managed-bean-name>
   <managed-bean-class>pacote.BeanExemplo</managed-bean-class>
   <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

O parâmetro <managed-bean-name> é o nome utilizado pela sua interface JSF mapeado para o controlador do EJB configurado em <managed-bean-class>. O <managed-bean-scope> possui 3 parâmetros aplicáveis: REQUEST, APPLICATION e SESSION, sendo que o mais comumente utilizado é o REQUEST.

Bom, com isso finalizamos a etapa de configuração. Na próxima parte começaremos a criar uma pequena aplicação de exemplo para juntarmos todas as peças simulando um sistema real.