Craft Nicely

Introduzindo novas tecnologias

2011-03-30T21:06:00.000-03:00

Em conversa recente com amigos, levantamos a dificuldade de se introduzir novas tecnologias, como um novo ambiente ou uma nova linguagem de programação em uma organização. A questão não se resume a problemas técnicos, mas a problemas pessoais, barreiras psicológicas, etc.

Por exemplo, se uma pessoa se considera em uma zona de conforto (por exemplo, se ela domina bastante uma linguagem de programação popular) pode haver uma certa resistência em colocá-la para aprender uma nova tecnologia (como outra linguagem de programação).

Para resolver problemas como estes, há diversos tipos de abordagens, envolvendo, inclusive, tirá-la da zona de conforto. No entanto, o propósito deste post é discutir questões organizacionais e levantar 5 pontos interessantes para definir uma estratégia para a introdução de novas tecnologias, mais especificamente, de uma nova linguagem de programação, na esperança de que alguns destes pontos possam ser úteis inclusive em outros contextos.

Existem vários motivadores para que uma organização resolva adotar uma nova tecnologia. Entre eles, a exigência de um projeto específico ou de um cliente importante ou até uma meta organizacional. Estes cenários tem suas peculiaridades e devem ser exploradas de forma diferenciada.

Se um projeto específico deve ser feito com uma tecnologia diferente da que a equipe está acostumada a trabalhar, pode ser conveniente, para reduzir os riscos do projeto, investir em treinamentos, contratar gente especializada ou encontrar algum colaborador que detenha conhecimento suficiente e possa dedicar atenção suficiente à equipe do projeto. Após a conclusão do projeto e seu período de manutenção, a mesma demanda por aquela tecnologia pode não ser mais necessária e evoluções podem ser feitas por membros da equipe que adquiriram conhecimento através do primeiro projeto.

Diferentemente deste cenário, a de exigência de um cliente importante ou uma meta estratégica da organização são questões mais duradouras e mais impactantes na organização pois outros futuros projetos serão garantidamente construídos sobre a nova base tecnológica.

O início de todo projeto já traz suas próprias complicações. Todos os envolvidos estão se familiarizando com os objetivos do cliente, com os padrões do projeto, sua arquitetura, suas funcionalidades e restrições. Além da própria curva de aprendizado do projeto, trazer uma nova linguagem de programação traz as curvas de aprendizado do ambiente de desenvolvimento e da linguagem em si, além de bibliotecas e frameworks de terceiros, sem as quais se torna muito custoso desenvolver softwares profissionalmente.

Assim, iniciar com uma equipe inexperiente um projeto com tantas novidades pode ser bastante caótico. Enquanto uma organização pode achar que um projeto pequeno pode ser utilizado, vale lembrar que um atraso de 1 semana em um projeto de 1 mês é muito pior que um atraso de 2 semanas em um projeto de 6 meses. Por outro lado, passar 2 meses na construção de um projeto para descobrir que é inviável na tecnologia escolhida pode inviabilizar o projeto completamente.

Então, quais ações poderiam ser adotadas para minimizar o impacto da introdução de uma nova tecnologia, como uma linguagem de programação?

Minha primeira sugestão é simples:

Quando se trata de atingir um objetivo/meta organizacional, o custo deve ser organizacional e o treinamento da equipe deve ser encarado da mesma forma: como um investimento para se atingir um objetivo.
Logo, pode ser contratado um treinamento, uma consultoria especializada para coaching/mentoring ou tentar orientar o aprendizado individual dos colaboradores.
Uma forma simples de fazer isto é a minha primeira proposta:

1- Alocar pequenas tarefas para cada colaborador.
Por exemplo, um fica responsável por configurar o ambiente e documentar de forma que outros consigam fazê-lo. Outro configura de acordo com o conhecimento registrado e cria uma projeto de exemplo, como o famoso "hello world", registrando seu aprendizado. Um terceiro pode implementar algo simples, como um cadastro de usuários, e um quarto, um sistema de login.
Através de atividades simples e pequenas, pode-se construir e incrementar o conhecimento organizacional, levando à minha segunda proposta.

2- Projeto startup.
Um projeto configurado com algumas funcionalidades simples e comuns pode ser replicado para servir como ponto de partida para outro projeto. Além de servir como exemplo, pode já trazer algumas funcionalidades comuns já implementadas, bastando fazer pequenos ajustes. Isto diminui o tempo e custo do projeto, compensando pelos gastos no aprendizado. Como outros projetos serão feitos na mesma tecnologia, a cada projeto, uma parte deste investimento será retornado.
Um projeto interno também pode ser utilizado se for considerado que seu investimento trará retorno para organização, no entanto, às vezes vale mais a pena escolher um pacote de funcionalidades comuns que irão se repetir em projetos externos ao invés de escolher um projeto interno com muitas especificidades.

3- Investigar, no início do projeto, como resolver as partes mais complicadas, as que se julga serem mais difíceis de serem feitas.
Muitas vezes pode-se descobrir frameworks ou bibliotecas que sozinhos ou combinados podem resolver o problema de forma satisfatória, no entanto, pode-se descobrir que tudo terá que ser construído do zero ou que esta é a forma mais apropriada para aquele cenário. Saber disto no início do projeto ajuda a determinar se a escolha da tecnologia foi adequada, se as necessidades serão atendidas e a minimizar o impacto destes riscos. Também, resolver estas questões pode trazer uma sensação de confiança e tranquilidade à equipe, o que pode ajudar a garantir o sucesso do projeto e até animá-los no aprendizado da nova tecnologia.

4- Escolher o cliente é tão importante quanto escolher o projeto.
Alguns clientes são mais tolerantes a pequenos atrasos que outros, alguns podem aceitar compensações (como uma ou outra funcionalidade extra) ao contrário de outros. Às vezes esta questão tem que ser levada em consideração na escolha de um primeiro projeto em uma nova tecnologia.

5- Rever o plano de implantação com antecedência.
Se a sua organização não tem um plano de implantação mas mesmo assim irá implantar o projeto, convém não só fazer um teste da implantação antes do primeiro release como documentar os passos tomados e as dificuldades encontradas, para que no momento do primeiro release, tudo siga suavemente. Isto é importante tanto para a moral da equipe, em saber que o primeiro release foi implantado e está funcionando corretamente quanto para que não se virem noites tentando resolver problemas de última hora, o que pode inclusive afetar a imagem da organização para o cliente.

Abraço a todos!

O diferencial Ágil

2011-02-05T18:24:00.000-02:00

Desenvolvimento iterativo e incremental em ciclos curtos. Só isso?

Em todas as palestras que já fui até hoje sobre metodologias ágeis, seja quais forem (XP, Scrum, FDD, etc), é sempre a mesma história:

Métodos Ágeis são melhores que cascata porque ...
ou
Métodos Ágeis são melhores que métodos tradicionais (ou engenharia de software tradicional) porque...

Invariavelmente a frase segue comparando o modelo de ciclo de vida iterativo e incremental com o modelo cascata. Este último, sempre conhecido por altíssimos índices de fracasso foi introduzido à comunidade em um artigo de 1970 que dizia que seguí-lo era normalmente um tiro no pé e já falando de absorver feedback ao longo do projeto.

Então vamos a alguns pontos para melhorar o discurso Ágil:

Ainda estou para ver uma metodologia Ágil que preconize o uso de cascata. São todas iterativas e incrementais. Sendo assim, dizer que metodologia A ou B é legal porque é iterativa e incremental é chover no molhado. Este é o mínimo. Quando for apresentar uma metodologia, enfatize o seu diferencial.
Só mostrar as vantagens do uso do ciclo de vida iterativo e incremental não é nem de longe o suficiente para dizer que uma metodologia é boa ou é ágil, visto que pode-se usar o mesmo modelo de ciclo de vida associado a qualquer metodologia ou processo, ainda que totalmente "tradicional".
"Métodos tradicionais" ou "Engenharia de Software tradicional" NÃO são sinônimos de cascata. Se você teve uma péssima experiência na empresa onde trabalhou porque usou cascata, o problema foi onde você trabalhou ou a forma de trabalhar. Não culpe a Engenharia de Software porque você trabalhou em algum lugar onde as pessoas tinham pouco conhecimento sobre o assunto. No máximo você pode por a culpa nas universidades que não preparam direito ou que não deixam claro para o formado que ele não sabe o suficiente para fazer determinadas coisas, como montar um processo de desenvolvimento. O fato de você ter feito de uma maneira incompatível com as necessidades, contexto e restrições do projeto não significa que a Engenharia de Software está errada.
E quanto ao "tradicional", se você acha que o modelo de ciclo de vida iterativo-incremental, revisão por pares/pair programming, escrever testes antes de desenvolver/testar enquanto se desenvolve, e outras práticas são super modernas... well, think again...
Falar bem de A comparando com um B que você escolheu por ser pior é fácil. Faça diferente. Diga porque você acha bom, compare com coisas similares. Mostre vantagens mas mostre também as desvantagens.
Por último, PMBOK não é um processo nem uma metodologia. É um conjunto de práticas apenas. RUP não é um processo específico, é um framework para construção de processos. Muito menos é cascata. Do site do RUP: "RUP promotes iterative development and organizes the development (...)". Da wikipedia: "The Rational Unified Process (RUP) is an iterative software development process framework (...)". CMMI e MPS.BR, não são processos, não exigem que seja utilizado cascata e não restringem o uso de métodos Ágeis. De fato, se você segue um destes modelos e escolheu um ciclo de vida, vai ter que apresentar uma justificativa, o que pode tornar um pouco difícil a adoção de cascata. Sem falar de inúmeros relatos de adoção bem sucedida destes modelos juntamente com metodologias ágeis. Não fale do que não conhece, e principalmente, não fale mal.

Abraço a todos!

Design Emergente no TI Master

2010-12-03T12:21:00.000-02:00

Amigos, a Nicolly Vimercate, jornalista do portal TI Master (http://www.timaster.com.br/) me entrevistou sobre Design Emergente e a matéria entitulada "Projeto de software: antes ou durante?" foi publicada ontem: http://timaster.com.br/revista/materias/main_materia.asp?codigo=1766

Meus agradecimentos à Nicolly, à equipe editorial do TI Master e ao Vinícius Morgado (que tem um blog também, o Bit Design).

Espero que gostem!

Abraço a todos!

Agile e "tradicional": pingos nos i's.

2010-11-21T01:52:00.000-02:00

Bom, como vocês podem já ter notado pelos meus posts, me interesso tanto Agile como não-agile. Inclusive já postei sobre o que eu considero ser Agile e não-agile (o que muitos chamam de tradicional). O caso é que desde que comecei a estudar processos e metodologias, estudo nos dois flancos. RUP, XP, PMBOK, MPS.BR, CMMI, Scrum, Kanban, Cascata, Iterativo e Incremental, etc.
Bom, pra quem conhece estas coisas, sabe que eu listei coisas que tem a ver e coisas que não tem a ver entre si. Entre processos, metodologias, modelos de maturidade, e afins, fiz uma mistura proposital.

Em muitas conversas, vejo pessoas comparando coisas diferentes, falando coisas sobre estes assuntos e tratando-os como sendo a mesma coisa ou fazendo outros tipos de confusões. Ok, são muitas siglas, eu sei. Se você se confunde, está perdido ou conhece muito pouco sobre estas coisas, chegou a hora de desfazer a confusão:

O modelo Cascata

Cascata não é um processo. Cascata não é uma metodologia. Cascata, assim como Iterativo e Incremental, é um Modelo de Ciclo de Vida.
O modelo cascata é aquele em que se faz toda a análise no início, depois se faz toda a modelagem, toda a codificação e todos os testes. Quaisquer que sejam as fases do seu processo, se em uma fase (por exemplo, análise) você faz tudo o que tem pra fazer do projeto (por exemplo, fez análise do projeto inteiro) não retorna a ela depois que entrou em outra (por exemplo, codificação), então você está seguindo um modelo em cascata.

O XP e o Scrum são metodologias que não adotam o modelo cascata pois depois de fazer codificação e testes, eles voltam para fazer análise e modelagem de funcionalidades que ainda não foram abordadas. O modelo que adotam é Iterativo e Incremental.

Notem que o cliclo de vida trata única e exlusivamente da ordem das atividades e não quais atividades são feitas. Por exemplo, você pode ter um processo em Cascata que se inicia com o registro de uma visão, um backlog de user stories, os testes delas e por último seu desenvolvimento com uma integração no final, quando então são feitos uma revisão e uma retrospectiva. Pode até desenvolver em pair programming. Notem que não é Scrum, pois o Scrum fala especificamente de outro modelo de ciclo de vida. No entanto, também não são utilizados casos de uso nem nada que tenha ganho popularidade com Agile.
Ao mesmo tempo posso ter todas as atividades mais tradicionais e ainda ter um processo em várias iterações, onde em cada uma eu escolho alguns requisitos e passo por todas as fases até gerar um release intermediário.

Vale lembrar que métodos ágeis não foram os primeiros a adotar o modelo iterativo e incremental. O RUP, um framework de processos, adota o mesmo modelo.

RUP

RUP não é um processo em si. O RUP, o Rational Unified Process, criado pela Rational (empresa que criou o Rational Rose, famosa ferramenta de modelagem), adquirida pela IBM, é um framework de processos de software.

Isto significa que o RUP apresenta vários artefatos, templates, atividades, fases, objetivando atender um grande escopo de necessidades.

Assim como todo framework, é necessário que em cada situação, a pessoa encarregada de construir o processo analise as suas necessidades e faça um recorte, uma escolha do que deve ser utilizado dentro do que o RUP apresenta.

Ou seja, o RUP pode dar origem a um processo extremamente burocrático ou até um processo leve e fácil de ser seguido. Como qualquer coisa na nossa área, depende de como é usado, por quem é usado e em que cenário foi usado.

Nota-se já que o RUP não é UM processo e que RUP e Cascata são coisas completamente distintas, embora o RUP possa ser mapeado para um processo em Cascata. Afinal, ninguém irá impedir ninguém de fazer adaptações, sejam boas ou ruins. Se você seguiu um processo baseado no RUP e não gostou, a culpa pode não ser do RUP.

PMBOK

O Project Management Body Of Knowledge (corpo de conhecimento em gerência de projetos) apenas organiza o conhecimento na área de gerência de projetos. Aborda temas como gerência de riscos, modelos de ciclo de vida, etc. Porque o Project Management Institute (PMI) resolveu organizar o conhecimento na área não quer dizer que você deve utilizar tudo o que se conhece na área em um projeto. Além disso, não há definição de seqüência de atividades, entradas e saídas. Não é um processo. É apenas o que o nome diz: um corpo de conhecimento.

Portanto, chamar PMBOK de processo é um erro. Assim como é um erro atrelá-lo ao modelo Cascata ou ao RUP.

Claro que como um projeto requer gerência, um framework de processos como o RUP irá incluir atividades de gerência que podem ser associadas a alguns conhecimentos presentes num corpo de conhecimento de gerência, pois se não estiverem associadas, significa que o corpo de conhecimento de gerência deixou de incluir alguma coisa.

Da mesma forma, é apresentado o modelo Cascata assim como o iterativo e incremental. É um corpo de conhecimento, como um catálogo.

CMMI e MPS.BR

CMMI e MPS.BR não são processos, não são métodos, não são metodologias, são modelos de maturidade.
Um modelo de maturidade apresenta um guia do que uma organização pode fazer para melhorar sua maturidade e sua capacidade.

Este guia apresenta "o que" fazer e não "como". Por exemplo, ele diz que você deve desenvolver seus requisitos. Se seus requisitos são casos de uso ou user stories, quem decide é você. Ele diz que você deve testar. Se você fará testes automatizados ou manuais, se utilizará TDD ou não, quem decide é você. Se o seu processo é cascata ou iterativo e incremental, quem decide é você. Se você faz sprint review e sprint retrospective ou não, quem decide é você.

O interessante destes modelos é que eles apresentam, a cada nível, novas áreas e novos requisitos para áreas introduzidas anteriormente, servindo como guias para aumentar a maturidade e a capacidade de se fazer software, reduzindo custos, prazos e aumentando a qualidade.

É cada vez mais comum atualmente encontrar organizações que utilizam métodos ágeis e são avaliadas seguindo modelos de maturidade, pois há um grande nível de compatibilidade.

Metodologias Ágeis

Metodologias ou métodos Ágeis são aqueles que estão alinhados com o Manifesto Ágil, ou seja, qualquer processo de desenvolvimento que valorize:
"Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano"

Os mais populares são Scrum, Extreme Programming (XP), FDD, OpenUP, Crystal e Kanban, mas além destes, qualquer processo que siga os valores acima pode ser considerado Ágil, independente das práticas e das atividades que são executadas. Logo, não há problema em ser Ágil e utilizar um processo baseado no RUP que atende um nível do MPS.BR num processo cuja gerência é orientada por práticas descritas no PMBOK.

Uma parte da comunidade Ágil atualmente rechaça vários destes conceitos como se fossem incompatíveis com a filosofia e não são. Pior, falam deles como se fossem o contrário de Ágil. Já vi inúmeras comparações entre Cascata e Scrum dizendo que o último é melhor. Dizem que MPS.BR e PMBOK são Cascata e por isso são ruins e outras coisas do gênero.

Escolhi estes tópicos em particular porque normalmente a comunidade Ágil faz referência a eles como "tradicional" numa alusão a uma forma tradicional de se fazer software. A questão é que eles não definem uma forma "tradicional" de se fazer software pois não há ruptura entre o movimento Ágil e estes conceitos, visto que não são antagônicos, não são incompatíveis. É como dizer que existe pizza antes e depois de existirem pizzarias, quando você antes podia comer uma pizza excelente em um restaurante que não seja especializado e pode até comer outras massas em uma pizzaria sem que os diferentes estabelecimentos se descaracterizem.

Mas há, dentro do movimento Ágil, este sentimento de ruptura. É inegável. Como em muitas conversas é necessário fazer referência às formas de se desenvolver anteriores ao movimento Ágil, eu uso "não-Ágil".

Espero ter contribuído para desfazer a confusão.

Abraço a todos!

Workshop de Gerência de Projetos

2010-11-01T21:01:00.000-02:00

Amigos, eu sei que o workshop é no Rio de Janeiro mas como meu blog ainda está nos primeiros passos, a maioria dos leitores são amigos (ou amigos de amigos). Assim grande parte está no Rio de Janeiro e portanto acho que vale a pena avisá-los que haverá um Workshop bastante interessante sobre gerência de projetos, baratinho.
Este é o site oficial:
http://sites.google.com/site/workshopsmps/home/workshop-19-10-2010---chamada

A chamada está aqui:

Abraço a todos!

Manifesto Ágil para entender a Agilidade

2010-09-15T19:40:00.001-03:00

Uma vez eu estava assistindo a uma palestra do David Card ("Measuring Software Design Quality" (Prentice Hall, 1990) e "Practical Software Measurement" (Addison Wesley, 2002)) e ele falou uma coisa bastante interessante, sobre a busca por um processo Lean.

Ele disse que uma pessoa pode ficar magra de duas formas. Fazendo uma dieta ou treinando para correr uma maratona. E ele pergunta retoricamente, qual das formas se espera que seja mais saudável, com os melhores resultados no final.
É um ponto de vista muito interessante que eu gostaria de aproveitar para explorar. Na apresentação dele, ele falava que muitas empresas querem ter um processo Lean e acham que vão conseguir isso fazendo cortes, cortando atividades e pulando etapas enquanto que o Lean que traz benefícios deveria vir através de um processo contínuo de melhoria.

Estou falando disso por causa da moda Ágil. Muitas empresas hoje em dia gostam de dizer que são Ágeis porque usam XP ou que são Ágeis porque usam Scrum ou seja lá o que for. Ser Ágil não é seguir um script. Ser Ágil exige mudar o mindset.

Não adianta deixar de gerar os artefatos que agregam valor para o cliente ou para a empresa. Também não adianta trocar artefatos que se gerava para gerar outros sem entendê-los ou sem extrair benefício suficiente deles, benefício que os justifique.

Não existe receita de bolo correta. Nenhuma empresa faz Scrum igual. Nenhuma empresa faz XP igual. Cada empresa tem sua própria cultura organizacional, seu perfil, seus clientes, etc, e fazer modificações Ágeis significa entender o mindset.

Acho que este é o principal valor do Manifesto Ágil. Entendê-lo é entender que não é necessário seguir a receita A ou B para ser Ágil (até porque na primeira necessidade de adaptação, correr-se-á o risco de perder a Agilidade.

O que é necessário é melhorar o seu processo, seja qual for, seja um processo aderente a algum nível do MPS.BR ou do CMMI, seja algum processo baseado exclusivamente em um framework Ágil, de forma a atender os seus objetivos sem gastos desnecessários de recursos, sem perder o foco e melhorando sempre.

Falando em foco, teve recentemente uma discussão bem interessante na lista da APLN Brasil sobre melhoria contínua e métodos Ágeis. A pergunta original era sobre uma empresa que teria, hipoteticamente, estabilizado seus processos Ágeis de forma que era difícil enxergar uma melhoria.

Acho curioso como algumas equipes vêem a melhoria como uma forma de se chegar a um modelo de desenvolvimento Ágil, lean. É muito fácil esquecer que as melhorias devem estar alinhadas com os objetivos estratégicos organizacionais e que estes nunca estão satisfeitos, logo, as melhorias devem ser buscadas de forma a se atingir estes objetivos. Se vc acha que não tem muito o que melhorar é porque está olhando para um cenário bem limitado, como suas atividades diárias. Com uma visão mais ampla do negócio e suas necessidades, as melhorias começam a aparecer com mais facilidade. Mas este é papo para outro post.

Links:

Agile Project Leadership Network (APLN):

http://www.apln.org/

http://groups.google.com/group/apln-brasil

Lean:

http://en.wikipedia.org/wiki/Lean_software_development (en)

http://cantinhodoagile.blogspot.com/2010/06/perspectiva-do-desenvolvimento-de.html (pt)

http://www.infoq.com/br/news/2009/08/lean-30-segundos (pt)

Agile Manifesto:

http://agilemanifesto.org/ (en - oficial)

http://www.manifestoagil.com.br/ (tradução do oficial)

http://en.wikipedia.org/wiki/Agile_Manifesto (en)

MPS.Br:
http://www.softex.br/mpsbr (pt - Oficial)
http://pt.wikipedia.org/wiki/Mps.br (pt)

CMMI:
http://www.blogcmmi.com.br/ (pt)
http://pt.wikipedia.org/wiki/Cmmi (pt)
http://www.sei.cmu.edu/cmmi (en - Oficial)
http://en.wikipedia.org/wiki/CMMI (en)

Scrum:
http://www.scrumalliance.org/ (en - Oficial)

http://en.wikipedia.org/wiki/Scrum_(development) (en)
http://pt.wikipedia.org/wiki/Scrum (pt)

eXtreme Programming:
http://www.improveit.com.br/xp (pt)
http://pt.wikipedia.org/wiki/Programação_Extrema (pt)
http://www.extremeprogramming.org/ (en)
http://en.wikipedia.org/wiki/Extreme_Programming (en)

Abraço a todos!

Papéis e responsabilidades nos métodos ágeis

2010-08-03T18:33:00.000-03:00

Todo mundo conhece a brincadeira do telefone sem fio. Além de uma brincadeira de crianças, ela serve para ilustrar quanto de conhecimento se pode perder entre a captura de requisitos até as funcionalidades de fato implementadas, caso não haja o cuidado necessário.

O interessante é que ao se buscar a solução para o problema, duas abordagens completamente diferentes podem ser tomadas.

A primeira é a mais óbvia, detalhar o máximo possível. Junto com isto temos técnicas de levantamento de requisitos, técnicas para verificar/validar os requisitos e outros recursos. Muitas informações interessantes ficam registradas e outras tantas podem ser extraídas de um Caso de Uso bem feito. Informações que podem levar a melhores estimativas, redução de custos e até de prazos no futuro, informações valiosas para um processo de melhoria. Porém, é mais trabalhoso.

A segunda, adotada pelos métodos Ágeis é a inversa. Detalhar o mínimo possível. E costuma funcionar dependendo do cenário.

Ao escrever uma User Story, a idéia é quase um lembrete do que deve ser desenvolvido e não a descrição exaustiva da funcionalidade. A abordagem se baseia no fato de que, se a perda de conhecimento acontece nos intermediários da comunicação entre o cliente ou usuário e o desenvolvedor, o melhor a se fazer é colocar os dois para conversar no momento em que aquela funcionalidade for implementada.

Neste momento, o desenvolvedor se torna um pouco analista. A seguir, ele pode ser um pouco arquiteto, um pouco desenvolvedor, um pouco testador, etc. Claro, nada impede que se tenha gente experiente nestas áreas acompanhando o processo em cada fase, mas também não tem nada que exija isto. Porém, quando o cliente ou usuário tem baixa disponibilidade para o projeto, as coisas podem sair um pouco diferentes do esperado.

Não estou dizendo que uma abordagem é melhor ou pior que outra. Como eu estou tentando mostrar, há vantagens e desvantagens e a abordagem ideal deve levar em consideração a cultura organizacional e o alinhamento com os objetivos estratégicos da organização.

A questão do mindset fica bem clara quando analisamos as abordagens. Um dos valores do Manifesto Ágil prega "Individuals and interactions over processes and tools". Isso significa que se deve preferir resolver um problema através da redefinição de papéis e responsabilidades ao invés de recorrer a mais ferramentas e alongar os processos desnecessariamente.

Se um problema pode ou não ser resolvido de formas mais alinhadas ao Manifesto Ágil é outra questão. Pode ser que possam, pode ser que naquela organização não possam ou ainda não se tenha encontrado uma forma de fazê-lo.

Existe um limite para o que pode ser feito pois o necessário é aquilo que se precisa para se atingir um objetivo e não adianta abrir mão de informações que são importantes para manter outras partes do processo funcionando adequadamente ou até informações que poderiam comprometer os objetivos organizacionais caso faltassem.

O limite do que é Ágil e o que não é, na verdade, é um limite móvel, que deve ser adaptado à capacidade e ao cenário de cada empresa. Assim, eu diria que uma organização que tem como objetivo se tornar Ágil, deve começar mudando seu modo de enxergar os problemas.

Tomando que uma empresa em busca da Agilidade julga como sendo melhor entre duas soluções aquela que está mais alinhada com os ideais do Manifesto Ágil, eu diria que, como sempre há uma forma de melhorar, nunca se é Ágil o suficiente.

Logo, não importa muito se há muita coisa a ser melhorada ou se está difícil enxergar onde se pode melhorar. O passo essencial para se tornar Ágil é mudar a perspectiva sobre os problemas, buscar soluções inovadoras e principalmente, mudar o mindset.

Links:
Agile Manifesto:
http://agilemanifesto.org/ (en - oficial)
http://www.manifestoagil.com.br/ (tradução do oficial)
http://en.wikipedia.org/wiki/Agile_Manifesto (en)

User Stories:
http://en.wikipedia.org/wiki/User_story (en)

Casos de Uso
http://pt.wikipedia.org/wiki/Caso_de_uso (pt)
http://en.wikipedia.org/wiki/Use_case (en)

Abraço a todos!

SQL é para dados, lógica não!

2010-06-27T22:17:00.002-03:00

Engraçado como são montadas as grades de disciplinas nas universidades... cada professor quer ensinar o que sabe, obviamente. O problema é que isto não é, necessariamente, no melhor interesse do aluno quando se olha para o todo, para o corpo de conhecimento sendo passado. Algumas coisas ficam bem aprofundadas e outras nem são mencioadas.

Por exemplo, sempre achei engraçado como na graduação em Ciência da Computação do DCC/UFRJ temos linguagens de programação nos primeiros períodos sem vermos NADA de banco de dados. Que só é visto na segunda metade do curso, sem nenhuma linguagem de programação acompanhando.

Resultado: ninguém faz um programinha que conecte no banco e faça alguma coisa. Inclusive, toda a persistência de trabalhos de faculdade é feita em arquivos até banco de dados e muitas vezes depois também.

Claro, sempre vale o argumento de que é muito fácil aprender sozinho, etc. Mas isso quando se pensa na conexão em si. Ninguém fala de mecanismos no banco para lidar com concorrência (locks pessimistas/otimistas) nem mapeamento objeto-relacional nem particionamento horizontal/vertical nem nada assim. Pelo menos não nas obrigatórias.

Mas acho que o pior é quando o professor acha que todo mundo tem que saber fazer as coisas na mesma profundidade que ele (por mais específicos que sejam os casos de aplicação real). E passa metade da disciplina em SQL. E os alunos arrancando os cabelos para fazer SQLs de várias linhas para... hmm.. nada útil.

O fato é que grande parte dos sistemas atualmente são orientados a objetos. A maior parte das queries é simples e as mais complicadas são geradas por algum framework de mapeamento objeto-relacional.

O pior é que SQLs grandes costumam gerar código "write-once". Aqueles que as pessoas escrevem e torcem pra nunca terem que alterar pois não conseguirão mais entender como aquilo funciona (e por Murphy é justamente alí que vai ter mudança, nem que seja pra jogar aquele trabalhão todo fora).

Por exemplo, uma questão que me lembro quando fiz esta disciplina era gerar uma SQL que desse como resultado as posições de chegada de cavalos na ordem, com seus tempos de chegada após uma corrida. A tabela tinha os cavalos e seus tempos. O "x" da questão era justamente gerar as posições.

Pois bem, apreciem a resposta:

select count(*) as posicao, c1.nome, c1.tempo from cavalos c1 join cavalos c2 on c1.tempo >= c2.tempo group by c1.nome, c1.tempo order by posicao;

Isto mesmo, um join da tabela com ela mesma onde qualquer um teria feito simplesmente um "SELECT * FROM Cavalos ORDER BY posicao;" e um for que imprime o índice do loop antes de cada linha, para produzir o seguinte efeito:

1	FugindoDoJackBauer	00:00:01
2	Veloz	00:00:25
3	Rápido	00:00:35
4	Corredor	00:00:40
5	Ligeiro	00:00:45
6	Pangaré	00:01:00

Agora, amigos, imaginem uma aplicação onde se coloca a lógica da aplicação em consultas de várias linhas. Pois é, nem tudo que dá para fazer é para ser feito, né? :-)

Abraço a todos!

P.S.: Caso alguém queira testar, be my guest.

CREATE TABLE cavalos (nome varchar(255), tempo time);

INSERT INTO cavalos (nome, tempo) VALUES ('Pangaré', '00:01:00');

INSERT INTO cavalos (nome, tempo) VALUES ('Ligeiro', '00:00:45');

INSERT INTO cavalos (nome, tempo) VALUES ('Corredor', '00:00:40');

INSERT INTO cavalos (nome, tempo) VALUES ('Rápido', '00:00:35');

INSERT INTO cavalos (nome, tempo) VALUES ('Veloz', '00:00:25');

INSERT INTO cavalos (nome, tempo) VALUES ('FugindoDoJackBauer', '00:00:01');

Workshop de Melhoria de Processos de Software

2010-05-12T23:09:00.000-03:00

Amigos,

Vai acontecer no Rio (ok, é no Fundão, mas vale a pena) um Workshop de Melhoria de Processos de Software.
Esta é uma iniciativa conjunta da COPPE/UFRJ, RioSoft, Promove e Prime Up.
Baratinho (Profissionais 50,00 / Estudantes 30,00), vai abordar temas importantes como conceitos, normas e modelos de maturidade de processos de software, indicadores de desempenho sobre o MPS.BR, implementações em empresas, etc.
Serão 4 palestras proferidas por alguns dos maiores nomes da engenharia de software no país como a professora Ana Regina e o professor Guilherme H. Travassos além de um painél onde representantes de empresas falarão sobre suas experiências em projetos de melhoria de processos que atendem a mais de um modelo/norma simultaneamente.

Acho que vai ser interessantíssimo. Será dia 28 e acho que vale muito a pena para quem tem interesse no tema. Uma ótima oportunidade de aprendizado, troca de idéias e experiências e contatos profissionais.

Este é o site: http://sites.google.com/site/workshopsmps/
Tem informações mais detalhadas. Lá vocês também podem se inscrever para receber (via e-mail ou feed) futuras notificações sobre workshops como este.
Claro, sabendo de algum, eu vou avisar a vocês por aqui também. ;-)

Espero vocês lá!
Abraço a todos!

"Testar ou não" não é a questão.

2010-04-23T12:04:00.002-03:00

É até engraçado ouvir de um desenvolvedor iniciante que "está pronto, só falta testar".

As chances de um código não funcionar de primeira para todos os casos previstos é tão grande que ninguém diz uma coisa destas. Se não testou, não está pronto.

Bom, para os que estão pensando em comentar sobre a declaração do Knuth dizendo que só precisa de testes automatizados quando não está desenvolvendo num ambiente familiar, onde ele já sabe o que vai e o que não vai funcionar. E eu repito o que reverberou por aí depois da declaração dele: "-Se você for o Knuth, escreva certo de primeira. Se não for, teste!".

Bom, nem era exatamente sobre isso que eu ia falar, mas antes de começar eu gostaria de dizer que só agora estou percebendo que o título fez uma rima besta. Me desculpem. Agora vai ficar assim mesmo. :-P

Como eu dizia, a questão não é sobre testar ou não. É sobre o que ou como testar.

Vou contar um caso interessante. Imaginem um projeto de alguns anos de desenvolvimento. Bom, no início tem pouco código, pouca funcionalidade e no fim de uma iteração já se põe o analista a testar manualmente. Em 2 dias está tudo testado, os bugs foram reportados, os desenvolvedores corrigiram, tudo foi revisado e o sistema está ok.

Passam-se mais alguns meses (e algumas iterações) e então são 2 dias pra testar, mais alguns pra corrigir, outros para retestar e facilmente já se foi mais de uma semana. E não dá para ser assim. Então o que o gerente esperto diz?

"-Corrijam mais rápido!"
"-Façam hora extra!"

E alguns meses depois já são duas semanas de testes. As correções se limitam aos bugs impeditivos (se tem outra forma de conseguir a mesma funcionalidade, não se perde tempo corrigindo o bug). A equipe está exausta. E o que o gerente esperto diz?

"-Corrijam mais rápido!"

"-Façam hora extra!"

"-COMO ASSIM APARECEU BUG NOVO AO CORRIGIR UM? ASSIM NÃO DÁ, PRESTEM ATENÇÃO!"

Bom, a situação foi ficando insustentável. Pessoas boas deixaram a equipe, etc...

A questão de como testar é simples. Testes automatizados. Há ótimos frameworks de testes automatizados em várias linguagens para facilitar a construção destes. Em segundos ou minutos é possível testar módulos ou sistemas inteiros. Também há testes de carga/performance que sem automatização são impossíveis.

Sugiro escrever testes automatizados em qualquer sistema minimamente sério ou complicado. A área de testes é muito vasta e há várias classificações e formas de testar. Sugiro ler Teste de Software como um ponto de partida para se saber o que aprender sobre testes. Um bom profissional na área de desenvolvimento de software deve ter uma boa noção de como ter uma segurança mínima no que foi desenvolvido. E testar é uma ferramenta poderosa para isto.

É claro que se você faz um teste para ver se o que você fez funciona, o teste não vai dizer se você desenvolveu o produto certo (validação), apenas se você desenvolveu certo o produto (verificação).

No entanto, se você já escreve seus testes tendo em vista os requisitos que precisam ser atendidos e depois escreve código que passa nestes testes, como no Test Driven Development (e talvez este seja o link mais importante de todo o post - se você só for ler um e não conhecer este, é este que deve ser lido), você já está num caminho mais maduro de desenvolvimento de código, focado nas necessidades e não na predição de possíveis problemas que mina a qualidade do código e do sistema em geral.

O que testar já varia em função do sistema que está sendo desenvolvido e do ambiente utilizado para testá-lo. Por exemplo, não faz sentido rodar teste de carga com múltiplos usuários numa administração de sistema web feito para apenas um usuário/administrador.

Da mesma forma, testar código criado automaticamente apenas para dizer que seus testes tem 100% de cobertura diz muito pouco ou nada sobre quão bem seu software está bem testado. Em geral, testar código criado automaticamente é esforço jogado fora. Esforço que o seu cliente está pagando.

Sempre é muito importante ter em mente o custo/benefício de se escrever teste para determinado trecho de código.

Mais para a frente pretendo escrever mais detalhes e dar alguns exemplos, por hoje fica aqui este artigo introdutório apontando apenas alguns links para os inciantes nesta prática se orientarem.

Quem estiver interessado em aprender mais sobre Test Driven Development (TDD) pode se aprofundar um pouco aqui: http://improveit.com.br/xp/praticas/tdd

Abraço a todos!

Isto é jeito de tratar seus objetos? -Domain Driven Design

2010-02-11T15:59:00.000-02:00

Engraçado como às vezes é mais fácil fazer o que é mais complicado do que o mais simples. Pelo menos esta é a única razão que eu encontro quando ouço alguém chamar "vidro" de "vrido". Deve ser mais fácil pronunciar "vrido", já que é mais complicado.

Posso não estar fazendo muito sentido pra vocês agora, mas já vão entender o que eu quero dizer.

Contemplem, por um minuto, esta modelagem "esquisitinha". Mais ou menos como um "r" fora do seu devido lugar:

Não é nada que interfira no funcionamento do sistema ou no entendimento de uma frase. Mas que diabos, estamos fazendo um sistema ou remendando uma colcha?
O que é aquele AlunoCurso ali no canto? E se você se depara com uma referência para DisciplinaSalaProfessorAluno depois de encontrar uma referência para DisciplinaSalaProfessor? Porque não tem um DisciplinaSala? ;-)

Um software é feito para resolver um problema de alguém. Este problema, em primeiro lugar, deve ser caracterizado. Parte desta caracterização envolve reconhecer as pessoas envolvidas e as entidades que executam suas ações em uma atividade problemática.

Quando se faz uma análise do problema, é importante analisar aquele problema e não perder tempo renomeando coisas que já existem, que já tem nomes. Muitas vezes as entidades envolvidas carecem de uma definição melhor delimitada ou de um consenso sobre sua responsabilidade e seu comportamento. Neste caso, um glossário ou até uma ontologia pode ajudar a resolver o problema. Pode ser que durante a análise até se descubra que é melhor retirar algumas responsabilidades de algumas entidades para criar uma nova, melhorando a coesão. No entanto, isto é uma questão totalmente de negócio, uma decisão sobre o domínio da aplicação, e quem entende do domínio é quem tem o problema e não quem pegou o bonde andando e ainda quer sentar na janela. ;-)

Vamos dar nomes existentes para aqueles caras do diagrama ali em cima e algumas coisas vão ficar mais claras:

Essa mania de substituir os nomes do domínio por nomes inventados em função dos relacionamentos das entidades, infelizmente, é muito comum. É péssima. Disruptiva. Uma pessoa nova que chega ao sistema demora a entender o que se passa no código. Uma mudança de requisitos, ainda que faça uso de uma matriz de rastreabilidade, apenas vai identificar quais classes serão alteradas. Qual alteração vai em cada uma é um custo. Tem-se que lembrar qual é a responsabilidade daquela classe em função de um nome artificial dado pelo relacionamento dela com as outras que não enfatiza o seu comportamento e a necessidade da sua existência. Não informa o problema que ela resolve. O que ela pode fazer.
Pior ainda, uma alteração que exija a inclusão de uma classe nova, criando novos relacionamentos, poderá fazer com que nomes deixem de fazer sentido.

Ah, para os que ainda estão com problemas de ver que os diagramas são equivalentes, aqui vai a mesma organização do primeiro no segundo:

OK, parece que eu trapaceei rearrumando o diagrama, mas eu explico. O processo que segui foi listar as classes com os nomes corretos (do segundo diagrama), criar os nomes esquisitos (do primeiro), construir o primeiro diagrama e depois construir o segundo.

A questão é que quando se faz as coisas mais complicadas do que se deveria, muitas vezes o nosso entendimento do problema fica prejudicado e a organização do diagrama acaba podendo refletir isso. Quais são as classes com mais relacionamentos, que parecem ser mais "centrais" no primeiro diagrama? Quais são as classes mais "periféricas", que tem cara de "atributos"? E no segundo? O que você acha que você colocaria no topo do diagrama, para facilitar o entendimento?

Quando se prejudica o entendimento do modelo de domínio, sobre o qual todo o seu software se baseará, se prejudica o entendimento de todo o software.

"O vrido, coloquei encima da táuba pra potreger da agua."
"Coloquei o vidro em cima da tábua para proteger da água."

Perceberam?

E aí, alguém quer comentar nomes "esquisitos"?

Abraço a todos!

O mapeamento é objeto-relacional, não é relacional-objeto.

2010-01-17T13:08:00.000-02:00

É isso aí, deveria ter uma seta no lugar deste hífen:
objeto->relacional

Infelizmente, as pessoas insistem em chamar certo, mas fazer assim:

relacional->objeto

Eu entendo que algumas pessoas trabalharam usando MER e DFD e matriz de interações (matriz CRUD) durante muitos anos e acham que deviam continuar usando primariamente estas ferramentas no desenvolvimento de sistemas orientados a objetos, muitas vezes em detrimento de outras mais ricas como modelos UML.
<Este post é longo, mas o final surpreende.>

Não estou defendendo que se use modelos UML, o que estou querendo discutir aqui é a implicação de se usar uma ferramenta na hora errada.

Antes eu gostaria de discutir a questão da diferença entre o modelo orientado a objetos e o modelo relacional.

O modelo relacional se presta a armazenar dados em tabelas, gerando relações. O modelo relacional não trata de comportamento, não trata de entidades do mundo real, não trata de relacionamentos entre estas entidades. Trata de dados em tabelas e relações matemáticas. Daí a necessidade de se fazer um mapeamento.

Apesar de se falar em entidades e relacionamento num modelo relacional ("Modelo de Entidades e Relacionamentos"), ele trata de tabelas e as relações entre elas. Estas tabelas são tabelas com linhas, chamadas de registros e colunas que contém dados com extremas limitações.

Por exemplo, não se pode associar um registro a vários outros utilizando uma única coluna pois numa coluna só se coloca UM valor.

Logo, se queremos fazer uma associação 1:N ("um para n" ou "um para muitos"):

Para associar um registro Aluno (com um identificador) a outros de outra tabela, por exemplo, Matrícula (supondo que um aluno possa ter uma matrícula para cada curso na mesma instituição), eis a solução:

Neste caso, cada matrícula só pode se relacionar com um aluno. Se fosse possível relacionar uma matrícula com mais de um aluno, ou teríamos vários registros com IDs diferentes e o mesmo número de matrícula, para ter diferentes valores na coluna id_aluno (o que poderia causar várias inconsistências ao alterar uma e esquecer de alterar as outras) ou teríamos que adotar outra solução. Como isto é exatamente o caso de Aluno e Turma, o pior ainda está por vir, o relacionamento n:m ("n para m" ou "muitos para muitos"):

Digo "pior" porque esta solução cria uma entidade de relacionamento, uma entidade fraca, que possivelmente não existe no mundo real, mas existe no modelo relacional por uma restrição tecnológica. Os dados ficariam assim armazenados:

O problema da modelagem relacional é que estas restrições são impostas pela maneira matemática de armazenar e trabalhar com estas informações, através do uso de álgebra relacional.

Como os sistemas gerenciadores de bancos relacionais são muito estáveis, bem estabelecidos no mercado, extremamente confiáveis e extremamente rápidos graças ao desenvolvimento da álgebra relacional e anos de otimizações nas implementações, eles se mantém no mercado mesmo quando o sistema é desenvolvido utilizando orientação a objetos.

Acontece que como os objetos não têm estas restrições, o modelo OO é mais simples, mais próximo do real e isto exige que seja feito um mapeamento dos atributos do objeto para as colunas das tabelas.
Isto seria simples se:

não houvesse herança, que não tem correspondente no modelo relacional. Existem 3 estratégias principais para se mapear heranças (single table, table per class e joined subclasses). Como o foco aqui não é explicar o mapeamento O-R, com estratégias já bem conhecidas, vão ao Google procurar páginas como esta.
se não houvesse encapsulamento e níveis de visibilidade diferentes para atributos e classes, pois não há correspondência no modelo relacional.
se relacionamentos não tivessem "navegabilidade".Ou seja, se Aluno tem um atributo Matrícula mas Matrícula não tem atributo para Aluno, o relacionamento é unidirecional e não tem correspondência no modelo relacional.
se não houvesse atributos que na verdade são coleções de outros objetos, pois uma coluna (para aquele atributo) não pode guardar uma quantidade indeterminada de valores. Apenas um. E se for assim nas duas pontas do relacionamento, teremos uma tabela de relacionamento que não representa classe alguma.

Felizmente, hoje em dia, é possível fornecer metadados (muitas vezes em XML ou Anotações em Java) para as nossas classes de forma que ferramentas automáticas se encarreguem de construir o banco conforme as nossas instruções nos metadados de forma adequada.

Outra alternativa é construir o banco de forma a comportar as nossas classes manualmente. Como este trabalho é muito custoso, normalmente se faz uso de uma ferramenta.

Quando se faz uso do MER antes de se ter o diagram de classes, o que acontece é que o banco é criado e as classes passam a espelhar o banco. Ou cria-se as classes manualmente, copiando-as do banco, uma classe para cada tabela ou se faz uso de ferramentas automáticas para isto.

Neste momento, perde-se todas as heranças (joined subclasses viram associações simples, table per class aglutina classes abstratas na próxima superclasse concreta e single table junta todas as classes a uma classe só), surgem tabelas que não existem como classes com nomes esquisitos, perde-se a navegabilidade dos relacionamentos (muitas vezes impactando no desempenho geral do sistema e aumentando o acoplamento, criando dependências circulares) e perde-se informação de visibilidade dos atributos que muitas vezes acabam trazendo nomes estranhos e fora do padrão de codificação da linguagem adotada.

Tem-se um modelo totalmente deformado. A manutenção fica prejudicada, a compreensão do código fica prejudicada, o desempenho fica prejudicado e a própria codificação fica prejudicada, gerando muitas vezes código extra, com verificações, comparações e loops desnecessários.

Claro que já peguei código assim. Mas vou lhes contar a vez mais estarrecedora:

Imaginem a minha surpresa quando encontrei um banco onde todos os relacionamentos 1:n foram promovidos a n:m sob a desculpa de que um dia o relacionamento poderia ter que ser modificado, então já se modificou todos antes, indiscriminadamente. Mais ou menos como se você fosse para a frente de uma garagem de hospital se jogar na frente de uma ambulância em baixa velocidade toda vez que você fosse atravessar uma rua para minimizar o tamanho do possível acidente.

A questão a ambulância não estava em baixa velocidade. Vinha em alta velocidade, com a sirene ligada e um paciente em estado crítico sendo transportado. Não só o modelo tinha cerca de 770 classes como cerca de 425 (mais da metade) eram de relacionamento já que todos os relacionamentos que não eram 1:1 eram n:m. Pra piorar, todo registro de uma tabela de relacionamento entre A e B tinha um número que significava a posição do objeto B no atributo (coleção) em A, para que ficassem na ordem, mesmo que a ordem não importasse para absolutamente nada para a aplicação e para o usuário e sua supressão não fizesse a menor diferença.

Depois de meses de conversa e persuasão, a ordem foi abolida onde não era importante e o mapeamento foi construído de forma a deixar as tabelas de relacionamento transparentes onde fosse possível. Aproximadamente 410 classes de relacionamento foram retiradas do sistema, sobrando algo em torno de 15. Infelizmente esta era só uma das idiossincrasias da modelagem daquele banco.

E você? Tem alguma história semelhante para contar?

Abraço a todos!

Convenções de codificação

2009-12-23T13:53:00.000-02:00

Estudos revelam que apenas 20% a 40% do custo de um software está relacionado com a construção. 60% a 80% com manutenção (Livro "Facts and fallacies of software engineering", Robert L. Glass).
Isso não significa dizer que manutenção é o mais importante no ciclo de desenvolvimento de software, mas certamente requer uma atenção especial.
Levando em consideração que também é bastante comum fazer manutenção em código de outra pessoa é importante que a outra pessoa nos deixe um código limpo, claro, fácil de entender e sem armadilhas escondidas.

Assim é muito importante que bons padrões de codificação sejam seguidos. Bons padrões melhoram a legibilidade, deixam claras as intenções do autor do código e expõem erros, facilitando não só para quem faz a manutenção mas para quem escreve o código.

Infelizmente muita gente não dá a devida importância ao tópico porque é bastante comum que outra pessoa dê manutenção no código no final das contas. O grande problema é que alguns de vocês leitores precisam escrever um código bom para que outros de vocês sejam capazes de entender, corrigir e mudar. Além disso, você se pergunta em que condições você está entregando o produto do seu trabalho? Você se pergunta o qual o valor do que você está entregando para o seu empregador?

Agora estou escrevendo este post no Blog. E simplesmente não dá para diferenciar os que estão dando manutenção no código de outra pessoa dos que estão escrevendo código para outra manter. E isso se dá pelo simples fato de que todos nós trocamos os chapéus vez ou outra. Então melhor do que torcer para que o seu próximo código a ser mantido tenha sido bem escrito é escrever o seu código atual bem. Se o seu amigo estiver fazendo o mesmo, você terá um bom código para manter e ele também.

Eu já escrevi anteriormente sobre qualidade de código mas desta vez me refiro a padrões. Padrões como http://java.sun.com/docs/codeconv/ e outros podem ser encontrados pelo Google. O padrão definido na linguagem Java tem sido largamente aceito inclusive por comunidades de outras linguagens de programação por ser bastante geral, simples e manter o código limpo.

Para quem acha que estou exagerando na importância do tópico vale lembrar que o padrão ajuda outros desenvolvedores a entenderem o código por já estarem familiarizados com o padrão. Um padrão ajuda em tarefas de automação como contagem de linhas de código (não estou defendendo esta medida, apenas citando) e revisões por pares frequentemente envolvem leitura de código.

Veja o trecho de código abaixo com uma identação adequada e sem uma identação adequada:

    //RUIM
    if ((condition1 && condition2)
        || (condition3 && condition4)
        ||!(condition5 && condition6)) { //QUEBRA RUIM
        doSomethingAboutIt();            //FÁCIL DE PERDER ESTA LINHA
    } 

    //BEM MELHOR
    if ((condition1 && condition2)
            || (condition3 && condition4)
            ||!(condition5 && condition6)) {
        doSomethingAboutIt();
    } 

    //TAMBÉM SERVE
    if ((condition1 && condition2) || (condition3 && condition4)
            ||!(condition5 && condition6)) {
        doSomethingAboutIt();
    }

Exemplo retirado do padrão Java, onde se lê "Line wrapping for if statements should generally use the 8-space rule, since conventional (4 space) indentation makes seeing the body difficult."

E o principal é fazer com que o que esteja errado pareça estar errado. Às vezes encontramos um bug num trecho inocente:


    if (condicao)

        fazerAlgo();

E descobrimos que o autor esqueceu de fazerAlgoAntes();. Assim, vamos corrigir:


    if (condicao)

        fazerAlgoAntes(); 

        fazerAlgo();

E pronto, lá está o fazerAlgo(); fora do if simplesmente porque o desenvolvedor não abriu um bloco no if:


    if (condicao) {

        fazerAlgo();

    }

E não é importante? Quem quer criar um bug novo ao consertar outro? Ou pior, quando você achou que era só "fazerAlgoAntes();" e não percebeu que quebrou o "fazerAlgo();" vai ficar se perguntando porque não funcionou, se não era só isso, como uma coisa fez a outra quebrar, etc...

Viu a diferença que um bloco no if pode fazer?

Não fique parado! Aprenda o padrão da sua linguagem mais utilizada/preferida! :-)

E se você tem algum caso de bug causado por código mal formatado, comente!

Interfaces e comportamento aumentando a coesão e reduzindo o acoplamento

2009-12-07T15:37:00.000-02:00

Você já encontrou uma pessoa famosa na rua executando tarefas cotidianas? Eu já. Encontrei, há muitos anos, o Francisco Cuoco alugando um filme numa Blockbuster em Ipanema. Também numa ida ao Tanaka San da Lagoa encontrei, jantando, Helena Ranaldi, Malu Mader e outros.

Como todas as outras pessoas, estas também implementam interfaces. E estas implementam interfaces públicas! ;-)

Elas comem como todo mundo, assistem filmes, fazem tudo o que nós fazemos. E atuam. Quando estão atuando, estão no ambiente de trabalho. Lá, diferente da vida pessoal, eles são obrigados a obedecer certas regras, assim como o resto de nós.

Ninguém vai trabalhar de pijamas, apesar de ser compreensível que, no mesmo horário, no conforto do seu lar, alguém pudesse estar de pijamas.

Isto porque no trabalho precisamos apresentar uma outra interface, com outro comportamento. Este comportamento é definido por um conjunto coeso de tarefas que podemos executar. Estas tarefas são executadas de uma determinada forma, seguindo determinados passos que compõem nosso método de executá-las.

Assim é com as classes. Ao definir métodos públicos para uma classe, estamos definindo uma interface para ela. Esta interface exibe um comportamento que poderá ser exigido dela através da execução destes métodos.

Se a sua classe implementa mais de uma interface, ela exibe mais de um comportamento. O mecanismo de interfaces presente em muitas linguagens é geralmente usado para simular uma herança múltipla, muitas vezes ausente, pois as interfaces podem ser usados como tipos quando o comportamento que será exigido de um objeto está inteiramente contido nela (e é o mais recomendável pois deixa o código mais flexível e reutilizável).

No entanto, o significado de implementar uma interface é dizer que um determinado comportamento é atendido e criar uma interface não só mostra isso com mais clareza mas também agrupa os métodos de forma mais coesa e dá uma flexibilidade maior ao sistema permitindo que classes em outra hierarquia também possam implementar o mesmo comportamento.

Este é o ponto de vista interno, do desenho da classe.

Do ponto de vista das classes clientes, ou seja, das classes que irão exigir o comportamento chamando os métodos, utilizar através de uma interface significa não estar preso a uma implementação específica, que pode inclusive ser trocada em tempo de compilação ou de execução, reduzindo drasticamente o acoplamento.

Em tempo de compilação esta flexibilidade permite que os métodos possam ser chamados de classes diferentes e cada classe poderá realizar diferentes ações. Esta flexibilidade é usada em muitos frameworks para isolar a implementação real da funcionalidade sendo disponibilizada, permitindo que os desenvolvedores possam evoluir o framework sem impactar na API externa.

Em tempo de execução esta flexibilidade permite que um método seja chamado de instâncias de diferentes classes, por exemplo, para notificar o acontecimento de um evento. A partir daí, cada instância fará o que foi programada para fazer no acontecimento daquele evento. Assim, uma coleção de instâncias de diferentes classes observadoras pode ser notificada quando um evento observável ocorrer em uma instância de outra.
Este é o padrão de projetos Observer.

Ainda não sei se vou explicar padrões de projeto aqui. Tem muita informação disponível a respeito já, basta googlar. O que acham?

Bom, vão as dicas:

- Depois de identificadas as entidades do sistema, verifique comportamentos em comum que serão exigidos pelas funcionalidades já requisitadas e os defina em termos de interfaces. Isto permitirá a reutilização de funcionalidades já construídas para diferentes hierarquias, reduzindo tempo e custo de desenvolvimento e manutenção.

- Procure identificar funcionalidades que tratam classes de hierarquias diferentes de forma semelhante no seu sistema e verifique se uma interface não poderia eliminar a redundância.

Você cria interfaces no seu sistema?

O CMMI e os processos de software

2009-11-25T23:43:00.000-02:00

O CMMI (Capability Maturity Model Integration) é, como o nome diz, um modelo de capacidade e maturidade. É um modelo de referência para a melhoria dos processos relacionados ao ciclo de desenvolvimento de software em organizações que desempenham esta atividade.

A melhor explicação que já ouvi até agora sobre capacidade e maturidade me foi contada pela professora Ana Regina C. da Rocha, verdadeira autoridade na área. Ela diz que uma criança adquire a capacidade de escrever ainda cedo, mas escreve de uma forma quando aprende, outra quando é adolescente, outra quando é adulta e outra no fim de uma carreira literária. O que muda é a sua maturidade.

Assim também, organizações adquirem a capacidade de fazer software de acordo com determinados processos e a cada ciclo de melhoria, deveria melhorar também a maturidade do que já era feito.

O CMMI organiza os processos de software em 5 níveis. Cada nível introduz novos processos e aumenta a exigência sobre os que já haviam sido introduzidos, obrigando a organização a aumentar sua maturidade.

A cada nível é possível fazer uma avaliação, onde pessoas credenciadas ao Software Engineering Institute, da Carnegie Mellon University atestam que a organização implementa os processos daquele nível de forma suficiente para as exigências do modelo.

Estes processos não foram tirados do bolso, obviamente. Foi muita pesquisa até se chegar na norma internacional ISO/IEC 12207 na qual o CMMI se baseou. Também se baseou na ISO/IEC 15504 para seu processo de avaliação.

Este modelo é considerado de difícil implantação nas pequenas empresas brasileiras, com avaliações caras. Mas temos o MPS.BR, totalmente compatível, com implementação facilitada para pequenas empresas e custos muito mais baixos. Falo dele num próximo post.

Os processos de cada nível são:
Nível 1: Ad hoc - Não há processos e atividades definidas. As pessoas trabalham de forma reativa, sem muito planejamento na maior parte das vezes.

Nível 2: Gerenciado - Processos de gerência, requisitos, medição e análise e outros necessários para um funcionamento controlado.
CM – Gerência de configuração
MA – Medição e análise
PP – Planejamento de projetos
PMC – Acompanhamento de projetos
PPQA – Garantia de qualidade do processo e produto
REQM – Gerência de requisitos
SAM – Gerência de acordos com fornecedores

Nível 3: Definido - Os processos, ferramentas e métodos são definidos a nível organizacional e padronizados em todos os projetos.
PI – Integração do produto
RD – Desenvolvimento de requisitos
TS – Solução técnica
VAL - Validação
VER – Verificação
OPD – Definição do processo organizacional
OPF – Foco no processo organizacional
OT – Treinamento organizacional
IPM – Gerência integrada de projetos
DAR – Análise de decisão e resolução
RSKM – Gerência de riscos

Nível 4: Gerenciado quantitativamente - Os processos são medidos e gerenciados através de ferramentas estatísticas. Considerado como de alta maturidade. Em geral, após um grande esforço de implementação do nível 3, este nível dificilmente é avaliado. Por só ter dois processos, as empresas costumam implementar este junto com o 5 e fazer uma avaliação só.
QPM – Gerência quantitativa de projetos
OPP – Desempenho do processo organizacional

Nível 5: Em otimização - Melhoria contínua implementada com uso do ferramental estatístico e dados coletados a partir de processos estabilizados graças a maturidade obtida pela implantação dos processos dos níveis anteriores.
CAR - Análise de causa e resolução
OID - Inovação organizacional e implantação

O CMMI também permite que uma empresa escolha quais processos quer avaliar por achar mais relevantes na sua situação e quais níveis de cada processo serão avaliados (como expliquei, os processos do nível 2 devem ser mais maduros no 3 do que eram no 2). Este tipo de avaliação é chamada de "contínua" em oposição à avaliação "em estágios". Como a avaliação contínua não dá um nível que a empresa possa estampar no seu material de divulgação, acaba sendo preterida à outra.

No futuro, pretendo falar a respeito de cada um destes processos ou até pedir a especialistas na área que escrevam algo para eu postar aqui. Tenho certeza que será bastante interessante.

Só a título de curiosidade, o MPS.Br facilita as coisas tendo mais níveis com menos processos em cada um, trazendo um retorno de investimento mais cedo. Os níveis G e F do MPS.Br correspondem ao 2 do CMMI. Os níveis C, D e E ao nível 3. O nível B ao 4 e o A ao 5. Outra facilidade também é a presença de avaliadores e implementadores em quase todos os estados e nas principais cidades brasileiras, tornando a implementação e a avaliação mais baratas, além de fontes de subsídio para que as organizações implementem suas melhorias. Mas o MPS.Br fica pra outro post. Merece um só para ele.

Links do CMMI:
http://www.blogcmmi.com.br/
http://pt.wikipedia.org/wiki/Cmmi
http://www.sei.cmu.edu/cmmi (Oficial)
http://en.wikipedia.org/wiki/CMMI

Abraço a todos!

Otimização e desempenho

2009-10-29T18:49:00.000-02:00

Como eu já disse anteriormente, sou monitor da disciplina "Computação 2" (Orientação a Objetos com Java) na graduação em Ciência da Computação da UFRJ.

Uma pergunta bastante recorrente ao longo dos períodos tem sido "Como é mais rápido?" geralmente acompanhada de "O que consome mais memória?".

Estas perguntas podem ser facilmente respondidas em Java com System.nanoTime() e System.currentTimeMillis() para a velocidade e ferramentas de profiling para a memória e outras informações. Embora isto responda a pergunta, ataca um sintoma e não a raiz do problema:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Donald Knuth

O mal ("evil") a que ele se refere é consequência de algo bem explicado por outro grande autor:

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C. A. R. Hoare

Quem já percebeu a relação entre estas duas frases, já sabe onde eu vou chegar. A questão é que muitos tendem a se preocupar primariamente com otimização e deixam a legibilidade do código em segundo plano.
Ao fazer isso, o código pode ficar otimizado onde não precisa, prejudicando a legibilidade sem trazer ganho real.

Em via de regra, seu foco deve ser fazer um código legível. O máximo possível. SE vc tiver problema de desempenho (o que você só sabe depois que rodar com a carga esperada de usuários e objetos criados simultaneamente) é que você deve alterar o código de forma a ganhar desempenho prejudicando a legibilidade o mínimo possível, até atingir o desempenho desejado.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”-Martin Fowler

Já falei de legibilidade aqui antes: "Você comenta seu código?"

A grande questão é que você não trabalha sozinho. Cedo ou tarde alguém vai por a mão no seu código, assim como você vai mudar algo que alguém fez. E ainda que você esteja começando a desenvolver agora e esteja só fazendo pequenos exercícios, é de cedo que se deve treinar bons hábitos.
É importante que você deixe tudo muito bem claro para o seu colega, assim como ele deve deixar tudo claro para você. É mais um fator que pode contribuir para que você tenha no seu currículo um projeto de sucesso, um reconhecimento no ambiente de trabalho e consequentemente uma boa carreira profissional.
Mesmo que seja um projeto seu, particular, você mesmo pode querer mudá-lo alguns meses depois de começado.
Clareza é fundamental e deve vir em primeiro lugar, principalmente porque quando se escreve código, não se sabe, a priori, o que será suficientemente rápido ou precisará de otimização.

Isto só se descobre quando a funcionalidade foi implementada, para que possa passar por teste de carga (também conhecido como teste de estresse ou de performance).

Testes de carga são aqueles em que o sistema é forçado a executar em condições acima do projetado, para ver como se comporta. Por exemplo, se a sua previsão é para 50 usuários simultâneos, teste com 200, para ver como o sistema reagiria num caso de pico de utilização.

Estes testes são feitos geralmente através de ferramentas automatizadas que simulam execuções por usuários virtuais extremamente leves (para que uma máquina sozinha possa simular muitos). Uma ferramenta para Java free e muito popular é o JMeter e há outras para outras linguagens, inclusive algumas independentes de linguagem, já que basta simular um "agente" (termo que usam para um usuário ou sistema externo).

Estes testes, associados a ferramentas de profiling já mencionadas anteriormente fornecem informações sobre quais são os métodos mais lentos, que consomem mais memória, que executam maior quantidade de vezes, etc.

É só a partir destas informações que se pode detectar onde as otimizações devem ser feitas CASO precisem ser feitas. E mesmo assim, o código deve ser modificado para a otimização que menos prejudica a legibilidade e a portabilidade. Depois de um novo teste é que se decide se foi suficiente ou se mais alguma ação deve ser tomada.

Um ótimo exemplo de otimização sem perda de legibilidade está no Blog C++ do Zimbrão. Este é sobre Java e este sobre C++, lembrando que otimizações que realmente funcionam variam de linguagem para linguagem e de compilador para compilador em uma mesma linguagem. O post de otimizações em C++ é muito elucidativo a este respeito.

Além disso, deve-se lembrar neste momento que há diversos mecanismos para melhorar a performance como clusters de aplicações (felizmente para quem trabalha com JEE, isto vem de graça), configurações de datasource, pool de conexões com banco, cache de banco que não mudam a aplicação em si, caso tenha sido desenvolvida corretamente, isolada de acoplamentos com outros sistemas, como o sistema gerenciador de banco de dados ou o servidor onde será executada.

Vou só lembrar ainda que é importante também seguir as convenções de codificação da sua organização. Mas este é assunto para outro post. ;-)

P.S.: Pra quem gostou dos quotes, aqui tem mais: http://en.wikipedia.org/wiki/Program_optimization#Quotes

Abraço a todos!

Exceções são como são

2009-10-10T00:59:00.007-03:00

O mecanismo de exceções comum em linguagens OO modernas como Java, C# e outras é talvez um dos mais incompreendidos.
Tamanho é o incômodo que traz aos desenvolvedores que em C# nenhuma exceção precisa obrigatoriamente ser tratada e frameworks são escritos para lidar com exceções de forma mais "transparente" possível.
Por transparente entende-se muitas vezes "não tratá-las" ou jogá-las a um limbo onde todas são "tratadas" da mesma forma (que geralmente é o mesmo que não tratar).
Mas se o desenvolvedor já ia ignorá-la de qualquer forma (deixando o bloco de captura em branco ou simplesmente imprimindo o trace na console onde nunca será lido), que diferença faz?

Exceções são como são para que possamos tratá-las onde soubermos como fazê-lo. É por isso que nos é dada a opção de relançar ou tratar.

É comum, entre as pessoas que estão aprendendo sobre este mecanismo a dúvida sobre o que fazer em que situação ou "onde tratar".

Tipicamente em um sistema OO, o usuário realiza uma ação que dispara um método buttonSaveAction() que chama um saveUserData(), depois um writeFormattedContentFile() e assim por diante, até que chegamos naquele método saveFile() que grava o conteúdo que o usuário forneceu a um determinado arquivo que o usuário indicou.

E aí entra o problema: o arquivo não existe no local indicado.

Há então algumas opções:

Tratamento em branco / imprimir um erro na console:
Registrar o ocorrido:
Registre se precisar corrigi-lo posteriormente, mas o faça em um arquivo ao menos, para que as informações fiquem a salvo. E com informação que você julgue suficiente para corrigir. Infelizmente esta opção não ajuda nosso usuário, mas pelo menos ele não recebeu um golpe certeiro de um desenvolvedor descuidado, como um stack trace. Stack Trace real (4.40Mb, quase 46 MIL linhas - 45750 suprimidas - quem quiser ver tudo, me mande um e-mail):

01:20:48,359 INFO [Server] Starting JBoss (MX MicroKernel)... 01:20:48,359 INFO [Server] Release ID: JBoss [Trinity] 4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139) 01:20:48,359 INFO [Server] Home Dir: C:\jboss-4.2.2.GA 01:20:48,359 INFO [Server] Home URL: file:/C:/jboss-4.2.2.GA/ 01:20:48,359 INFO [Server] Patch URL: null 01:20:48,359 INFO [Server] Server Name: default 01:20:48,359 INFO [Server] Server Home Dir: C:\jboss-4.2.2.GA\server\default 01:20:48,359 INFO [Server] Server Home URL: file:/C:/jboss-4.2.2.GA/server/default/ 01:20:48,359 INFO [Server] Server Log Dir: C:\jboss-4.2.2.GA\server\default\log 01:20:48,359 INFO [Server] Server Temp Dir: C:\jboss-4.2.2.GA\server\default\tmp 01:20:48,359 INFO [Server] Root Deployment Filename: jboss-service.xml 01:20:48,953 INFO [ServerInfo] Java version: 1.5.0_14,Sun Microsystems Inc. 01:20:48,953 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_14-b03,Sun Microsystems Inc. 01:20:48,953 INFO [ServerInfo] OS-System: Windows XP 5.1,x86 01:20:52,671 INFO [Server] Core system initialized 01:20:56,546 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083/ 01:20:56,546 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:jboss-log4j.xml 01:21:26,296 WARN [TransactionManagerService] XAExceptionFormatters are not supported by the JBossTS Transaction Service - this warning can safely be ignored 01:21:40,875 WARN [ConfigurationFactory] No configuration found. Configuring ehcache from ehcache-failsafe.xml found in the classpath: jar:file:/C:/jboss-4.2.2.GA/server/default/tmp/deploy/tmp55870XXX.ear-contents/SS_2007_048_XXXEJB.jar-contents/lib/ehcache-1.4.1.jar!/ehcache-failsafe.xml 01:21:42,078 ERROR [STDERR] javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.LocalOnlyContextFactory [Root exception is java.lang.ClassNotFoundException: No ClassLoaders found for: org.jnp.interfaces.LocalOnlyContextFactory] 01:21:42,078 ERROR [STDERR] at javax.naming.spi.NamingManager.getInitialContext(Unknown Source) 01:21:42,078 ERROR [STDERR] at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source) 01:21:42,078 ERROR [STDERR] at javax.naming.InitialContext.init(Unknown Source) 01:21:42,078 ERROR [STDERR] at javax.naming.InitialContext.<init> (Unknown Source) (01:21:42,078) ERROR [STDERR] at SUPRIMIDO - ESPECÍFICO DA APLICAÇÃO (01:21:42,078) ERROR [STDERR] at SUPRIMIDO - ESPECÍFICO DA APLICAÇÃO (01:21:42,078) ERROR [STDERR] at SUPRIMIDO - ESPECÍFICO DA APLICAÇÃO (01:21:42,078) ERROR [STDERR] at SUPRIMIDO - ESPECÍFICO DA APLICAÇÃO (01:21:42,078) ERROR [STDERR] at SUPRIMIDO - ESPECÍFICO DA APLICAÇÃO 01:21:42,093 ERROR [STDERR] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 01:21:42,093 ERROR [STDERR] at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) 01:21:42,093 ERROR [STDERR] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) 01:21:42,093 ERROR [STDERR] at java.lang.reflect.Constructor.newInstance(Unknown Source) 01:21:42,093 ERROR [STDERR] at org.hibernate.engine.UnsavedValueFactory.instantiate(UnsavedValueFactory.java:22) 01:21:42,093 ERROR [STDERR] at org.hibernate.engine.UnsavedValueFactory.getUnsavedIdentifierValue(UnsavedValueFactory.java:44) 01:21:42,093 ERROR [STDERR] at org.hibernate.tuple.PropertyFactory.buildIdentifierProperty(PropertyFactory.java:44) 01:21:42,093 ERROR [STDERR] at org.hibernate.tuple.entity.EntityMetamodel.<init> (EntityMetamodel.java:123) 01:21:42,093 ERROR [STDERR] at org.hibernate.persister.entity.AbstractEntityPersister.<init> (AbstractEntityPersister.java:434) 01:21:42,093 ERROR [STDERR] at org.hibernate.persister.entity.JoinedSubclassEntityPersister.<init> (JoinedSubclassEntityPersister.java:91) 01:21:42,093 ERROR [STDERR] at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:58) 01:21:42,093 ERROR [STDERR] at org.hibernate.impl.SessionFactoryImpl.<init> (SessionFactoryImpl.java:226) 01:21:42,093 ERROR [STDERR] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294) 01:21:42,093 ERROR [STDERR] at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:915) 01:21:42,093 ERROR [STDERR] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:730) 01:21:42,093 ERROR [STDERR] at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:127) 01:21:42,093 ERROR [STDERR] at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:246) 01:21:42,093 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 01:21:42,093 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 01:21:42,093 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 01:21:42,093 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source) <b>(Suprimidas 45750 linhas - quem quiser ver tudo, me mande um e-mail)</b> 01:22:52,562 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) 01:22:52,562 ERROR [STDERR] at $Proxy4.start(Unknown Source) 01:22:52,562 ERROR [STDERR] at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) 01:22:52,562 ERROR [STDERR] at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) 01:22:52,562 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) 01:22:52,562 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) 01:22:52,562 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) 01:22:52,562 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 01:22:52,562 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 01:22:52,562 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 01:22:52,562 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) 01:22:52,562 ERROR [STDERR] at $Proxy5.deploy(Unknown Source) 01:22:52,562 ERROR [STDERR] at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) 01:22:52,562 ERROR [STDERR] at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) 01:22:52,562 ERROR [STDERR] at org.jboss.Main.boot(Main.java:200) 01:22:52,562 ERROR [STDERR] at org.jboss.Main$1.run(Main.java:508) 01:22:52,562 ERROR [STDERR] at java.lang.Thread.run(Unknown Source) 01:22:52,562 ERROR [STDERR] Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jnp.interfaces.LocalOnlyContextFactory 01:22:52,562 ERROR [STDERR] at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:521) 01:22:52,562 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415) 01:22:52,562 ERROR [STDERR] at java.lang.ClassLoader.loadClass(Unknown Source) 01:22:52,562 ERROR [STDERR] at java.lang.ClassLoader.loadClassInternal(Unknown Source) 01:22:52,562 ERROR [STDERR] at java.lang.Class.forName0(Native Method) 01:22:52,562 ERROR [STDERR] at java.lang.Class.forName(Unknown Source) 01:22:52,562 ERROR [STDERR] at com.sun.naming.internal.VersionHelper12.loadClass(Unknown Source) 01:22:52,562 ERROR [STDERR] ... 167 more 01:22:54,578 WARN [SessionFactoryObjectFactory] InitialContext did not implement EventContext
Avisar o usuário:
Avisar o usuário parece ser uma boa idéia nesta situação. Se o arquivo não está no local indicado, pode ser que ele tenha informado o caminho errado, por exemplo. Uma forma de resolver o problema seria pedir o caminho novamente, informando o erro e ver se ele corrige. Claro, dependendo da situação, pode ser que sua aplicação resolva criar o arquivo ou salve em um arquivo padrão ou simplesmente não realize o salvamento. De qualquer forma, é sempre bom informar o usuário de que o que ele pediu não foi feito ou foi feito de forma diferente.
Uma vez tomada a decisão de informar o usuário, que método você espera que fique responsável por isso?
writeBytes(), o método onde o erro se originou é um método genérico demais. Pode ser usado para qualquer situação em qualquer aplicação. Resolver o que fazer com um erro irá acoplá-lo a uma regra daquela aplicação especificamente, impedindo seu reuso.
writeFormattedContentFile(), o método que chamou writeBytes() não parece ser responsável por lidar com o usuário, assim como saveUserData(). Ainda que fossem, estando fora da camada de apresentação, como fazê-lo? É uma aplicação desktop em linha de comando, com interface gráfica ou Web? E mesmo que fosse, este era o caso de uso em que o usuário opta por um arquivo existente necessariamente ou é o caso de uso em que o arquivo pode ser criado caso não exista? Em outras palavras, qual era a ação presente no método buttonSaveAction()?
Como se pode notar, conforme os métodos se aproximam do usuário, se tornam mais específicos da aplicação, com mais informação sobre o contexto de sua utilização. Conforme se afastam, se tornam mais genéricos e mais reutilizáveis.

Então, finalmente respondendo a pergunta:
As informações técnicas sobre o erro devem ser escondidas do usuário comum, mas salvas para que possam ser utilizadas para corrigir. O tratamento pode envolver tentar de outra forma, tentar novamente ou perguntar ao usuário o que fazer, mas de qualquer forma, o usuário deve ser avisado de que seu pedido não foi realizado da forma que se desejava. E sempre que a solução envolver o usuário (avisar do erro e/ou fornecer alternativas), o tratamento deve ser feito no método que tiver informação de contexto suficiente para não só saber quais são as alternativas viáveis, mas como avisar ao usuário.

Não raro, em aplicações com a camada de negócio e apresentação separadas, uma exceção técnica (como ArquivoNaoEncontrado) pode ser capturada na camada de negócio unicamente para que seja lançada outra em seu lugar, determinando apenas o curso de ação (como PerguntarCaminhoArquivo ou AvisarErroArquivoNaoEncontrado). Na camada de apresentação, então, determina-se como avisar ao usuário, de acordo com a ação decidida pelo lançamento da exceção específica na camada de negócio.

Se for bem utilizado, o mecanismo de exceções é seu amigo.

Abraço a todos!

Agile, "tradicional" ou ambos?

2009-10-06T00:21:00.006-03:00

Muitos não sabem mas antes de enveredar pelo MPS.BR*/CMMI* eu já estudava muito XP*. E antes do XP, muito RUP*. Agora, acabo de regressar de São Paulo onde fiz o curso oficial Certified ScrumMaster* com o Boris Gloger.

O curso foi ótimo para aprofundar meu aprendizado no Scrum. A experiência do Boris com certeza foi um fator importante neste processo. Acabei acumulando ao conhecimento que tive durante o treinamento de coach de XP com o Vinícius Teles e relembrando muitas práticas Ágeis que há muito haviam ficado esquecidas.

O curso também foi muito bom pela contribuição da Ana Rouiller com relação a integração do MPS.BR/CMMI e Scrum. É uma integração já com bastantes artigos publicados em congressos nacionais e internacionais e até onde eu pude perceber, bastante benéfica para as empresas. Espero que as comunidades de ambos os "flancos" ergam bandeiras brancas e percebam que há o que se aprender com a perspectiva do outro.
Esta integração, que eu sempre soube ser não só possível mas também benéfica, é um dos assuntos que mais desperta meu interesse desde que comecei a estudar Engenharia de Software.

*Para quem não está familiarizado com a sopa de letrinhas do primeiro parágrafo, aqui vão alguns links.
Estes são exemplos típicos de assuntos que pretendo abordar neste blog. Na verdade, cada um destes temas merece um blog, mas pretendo abordar todos estes assuntos aqui mesmo em futuras postagens.

Por enquanto, ficam as referências:

MPS.Br:
http://www.softex.br/mpsbr (Oficial)
http://pt.wikipedia.org/wiki/Mps.br

CMMI:
http://www.blogcmmi.com.br/
http://pt.wikipedia.org/wiki/Cmmi
http://www.sei.cmu.edu/cmmi (Oficial)
http://en.wikipedia.org/wiki/CMMI

Scrum:
http://en.wikipedia.org/wiki/Scrum_(development)
http://www.scrumalliance.org/ (Oficial)
http://pt.wikipedia.org/wiki/Scrum

eXtreme Programming:
http://www.improveit.com.br/xp
http://pt.wikipedia.org/wiki/Programação_Extrema
http://www.extremeprogramming.org/
http://en.wikipedia.org/wiki/Extreme_Programming

Rational Unified Process:
http://pt.wikipedia.org/wiki/Rup
http://www-306.ibm.com/software/awdtools/rup/?S_TACT=105AGY59&S_CMP=WIKI&ca=dtl-08rupsite (Oficial)
http://en.wikipedia.org/wiki/Rup

Abraço a todos!

Conformidade de tipo

2009-09-22T01:06:00.003-03:00

Eu já falei sobre isso em algumas aulas mas sempre é válido ressaltar: herança é um acoplamento forte.

Acoplamentos fortes são indesejáveis, pois criam dependências pelas quais o impacto de uma mudança se propaga.
Uma herança entre duas classes traz várias implicações. Uma delas é dizer que a subclasse se comporta como a superclasse (Princípio de Substituição de Liskov*).

Assim, um pequeno polimorfismo de classe pode causar grandes transtornos se este relacionamento não for bem observado. Vou falar um pouco de covariância e contravariância.

Imaginem uma Superclasse e uma Subclasse, ambas com um método m declarado, sendo redefinido na subclasse. Este método tem um retorno e uma lista de parâmetros.

A covariância é a determinação de que o retorno da subclasse deve ser do mesmo tipo do retorno da superclasse ou de um tipo mais específico (subtipo) que este.

Então suponha a classe Object e a classe String herdando de Object.

O método m na Superclasse pode retornar Object. O método m redefinido na Subclasse pode retornar Object ou String (ou qualquer outro subtipo de Object).

Isto porque um código como

Object objeto = instancia.m();

deveria funcionar com

Superclasse instancia = new Superclasse();
ou
Superclasse instancia = new Subclasse();

Reparem que o código cliente (que usa as classes) assume que os retornos serão pelo menos do tipo declarado na Superclasse (ou mais específico) e, mais ainda, a variação deste retorno deve ser igual ou menor. Por exemplo, fosse o retorno um inteiro entre 0 e 10, a subclasse poderia retornar quaisquer números entre 0 e 10 (não necessariamente todos) mas nunca um número fora destes limites, pois o código cliente não pode estar preparado para lidar com situações que não estão previstas para a execução daquele método através de uma referência para a Superclasse.

Notem que para os objetos retornados, o ideal é que o espaço-estado* também seja igual ou menor.

Assim, conforme o tipo vai ficando mais específico (descendo na hierarquia), o retorno também vai ficando mais específico, configurando-se a covariância.

A contravariância é o mesmo conceito aplicado aos parâmetros. Ela é "contra" pois conforme se desce na hierarquia (ficando mais específico), os parâmetros vão aumentando os limites.

Se passo para o método m na superclasse um valor entre 0 e 5 e ele funciona, na subclasse, ele deve funcionar, no mínimo, com valores entre 0 e 5. Nenhum problema se ele funcionar também com 314.1592. O problema é se ele só funcionar com valores entre 0 e 3 ou não funcionar com 4 ou qualquer outra restrição. Devemos lembrar que a declaração
Superclasse instancia = new Subclasse();
é sempre válida e quem determina se uma classe funciona como deveria é o código cliente (novamente Princípio de Substituição de Liskov).

Vocês se preocupam com o funcionamento correto das heranças nas aplicações que fazem?

Abraço a todos!

*Prometo que no futuro falo um pouco do Princípio de Substituição de Liskov e de espaço-estado.

Você comenta seu código?

2009-09-07T14:09:00.009-03:00

Para quem não sabe, sou monitor honorário da disciplina "Computação II" no Departamento de Ciência da Computação da UFRJ (http://www.dcc.ufrj.br/~comp2/professor.html).
Como monitor honorário eu ajudo os outros monitores nas tarefas que me agradam. ;-) Isso significa dar aulas de apoio e tirar dúvidas, principalmente.
Na última semana um aluno perguntou sobre a importância de comentar o código dos exercícios a serem corrigidos. Adaptei a resposta para a pergunta "É importante comentar?".
É MUITO importante que seu código seja compreensível, não só por você mesmo (agora ou no futuro), por pessoas que trabalham com você ou trabalharão num projeto em que você desenvolveu um dia.
Como regra, eu adoto a política de tentar fazer um código tão claro que dispense comentários. Só quando isto não é possível por uma idiossincrasia da vida que eu comento e tento ser o mais explicativo possível.

“There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” Sir Charles Antony Richard Hoare

Reparem, por exemplo, neste trecho fictício:

if ((e1.comparaMaior(e2) || e1.vazio()) && (e2 != null)) {
    fazerAlgo();
}

em contraste com:

if (elemento1AtendeRestricaoComparandoElemento2(elemento1, elemento2)) {
    fazerAlgo();
}

boolean elemento1AtendeRestricaoComparandoElemento2(Elemento elemento1, Elemento elemento2) {
    return (elemento1.comparaMaior(elemento2) || elemento1.vazio()) && (elemento2 != null);
}

Notem que fica claro o que está sendo testado no if e fica clara também a intenção daquela comparação enorme graças ao nome método implementado em seguida. Não é necessário o comentário. Assim, evita-se, entre outras coisas, que o código seja atualizado, e o comentário esquecido, ficando desatualizado e informando uma condição diferente da que acontece, causando muitos transtornos.
Além disso, se a intenção é entender a finalidade do código, muitas vezes entender a comparação é desncessário.

Usar nomes de variáveis que signifiquem alguma coisa também é outra boa prática. Todas as boas IDEs completam os nomes quando digitamos os primeiros caracteres e pressionamos ctrl+space.
Notem que não poupei letras no nome do método. O importante é deixar claro e organizado.

Vale notar também que este código é agora mais testável, já que é possível testar apenas a comparação. ;-)

Uma situação válida para a utilização de comentários é quando entendemos algum código um pouco complicado, que demanda algum raciocínio de como o código funciona para entendermos seu objetivo. Neste caso, vale comentar o objetivo se não for possível (por restrições quaisquer) refatorá-lo para torná-lo adequado ao entendimento.

O Javadoc também é bem interessante, mas nele deve constar apenas "o que" o método faz (objetivo) e não "como" o método faz (lógica). Assim, a documentação se torna suscinta, simples e direta, atendendo aos objetivos de quem a lê. Quem quiser entender como irá ler o código e o deve encontrar devidamente organizado.

E vocês? O que comentam? Como comentam?

Abraço a todos!

Um blog!

2009-09-07T11:48:00.000-03:00

Então galera...
Muita gente tem me perguntado porque eu não tenho um blog sobre coisas relacionadas a Java ou orientação a objetos ou desenvolvimento de software em geral. A resposta é simples. Porque eu não tenho tempo pra ficar postando, atualizando. E ainda acho que isso é verdade.
De qualquer forma, vou fazer uma tentativa.
A princípio, este blog não é sobre Java. É sobre desenvolvimento de software em geral. Sendo de um assunto mais amplo, pode ser que eu tenha mais o que dizer. ;-) Também aumentam as chances de um assunto interessante aparecer por acaso e me animar para postar.
Enfim, pretendo abordar assuntos relacionados a qualidade de software em geral, de processos e metodologias a questões de design, boas práticas, padrões, etc.
É claro que como trabalho com Java, vez ou outra haverá aqui dicas de aplicações, componentes, frameworks e trechos de código interessantes. E os exemplos, em geral, provavelmente serão em Java quando envolverem código.

Vamos ver se esta empreitada segue em frente ou desisto depois de meia dúzia de posts.

Abraço a todos.