Posts Tagged ‘Desenvolvimento’

[QCon 2007] Cedric Beust e Alexandru Popescu: Designing for testability

Thursday, November 8th, 2007

Cedric Beust e Alexandru Popescu, criadores do framework de testes TestNG, fizeram uma apresentação entitulada “Designing for testability“.

QCon 2007 - Alexandru Popescu e Cedric BeustEles falaram algumas coisas interessantes sobre os “inimigos” da testabilidade como chamadas entranhadas à métodos estáticos, encapsulamento ao extremo (atributos private final) e cuidado com Singletons.

No geral a apresentação foi média mas acabou servindo para levantar um ponto importante.

Num determinado momento eles falaram claramente que não acreditam muito em Test-Driven Development porque ninguém nunca vai aplicar corretamente. Eles alegam que as pessoas não gostam de escrever código que dá erro de compilação e que fica “vermelho no Eclipse” para depois escrever código que funciona. Por isso eles na maioria das vezes não usam a técnica.

Eu acho que isso não é um problema do TDD mas um problema das IDEs! O que acontece é que com essas IDEs semi-automáticas de hoje em dia as pessoas ficaram muito acostumadas com o Ctrl+Enter e escrever o teste antes implica em não ter esse tipo de funcionalidade, o que pode dar uma falsa impressão de que você está fazendo algo estúpido. Sem contar que a feature “Build Automatically” faz com que o seu código fique assustadoramente vermelho quando a IDE tenta compilar o teste e não consegue… Se você programar em Ruby, por exemplo, essa falsa impressão desaparece. Quando você escrever um teste para um código que não existe, simplesmente o teste não vai funcionar. Nada de alarmes vermelhos na IDE. Enfim, para mim é uma questão de hábito. Coincidentemente numa das palestras seguintes o Charles Nutter falou exatamente sobre isso e concorda que o problema do TDD no Java são as IDEs.

Para finalizar sobre esse papo de TDD ou não-TDD, gosto muito daquele provérbio budista que diz: “vá sempre pelo caminho do meio“. Não acredito que todo mundo deva ser pragmático e sempre escrever todo e qualquer teste antes de programar absolutamente qualquer coisa. Ninguém vai morrer se você escrever testes junto com a implementação em certos casos. Para mim o que mais importa nisso tudo é o mindset de possibilitar que as dependências sejam isoladas, ter uma suite de testes decente para garantir qualidade/permitir refactorings seguros e coisas desse tipo.

Download

Em qual língua você programa?

Saturday, September 22nd, 2007

Muitas vezes fico em dúvida sobre qual língua usar nos meus sistemas. Sempre me sentí muito mais confortável programando em inglês do que em português mas nunca achei isso muito certo já que nossa língua nativa é o português. Já houveram casos de eu trabalhar com alguém que só sabia português e apesar de achar que nessa profissão quem não sabe inglês não vai à lugar nenhum não podia simplesmente inviabilizar o trabalho da equipe.

No último projeto que participei nossa equipe usou somente português. Algumas coisas boas aconteceram como o fato de termos incorporado a linguagem do negócio ao sistema. Isso é muito bom porque a grande maioria das entidades do sistema são coisas do mundo real e as discussões são sempre sobre coisas reais e não sobre metáforas (frequentemente mal feitas).

Porém também houveram pontos negativos. Por exemplo, uma determinada classe de serviços, que em inglês seria algo como MediaServices, teve que ser chamada de ServicosDeMidia. No fim das contas acabei optando por tirar a preposição (acho que o “de” é uma preposição, certo?) ficando somente ServicosMidias. Resolví retirá-la porque inúmeras classes ficaram com “De” no nome e ficou meio esquisito. O ruim é que não é exatamente assim que a gente fala naturalmente e fica um pouco estranho…

No fim das contas acho que o ideal é utilizar a língua do negócio, seja ela português ou inglês. Desta forma quando você for conversar com os clientes (product owners) você não terá o overhead de mapear todos os conceitos reais para a linguagem ou metáforas usadas no sistema. Com isso a conversa entre os clientes e os desenvolvedores fica muito mais produtiva já que todos estão falando sobre as mesmas coisas.

Para que você vai usar isso?

Tuesday, September 4th, 2007

Quando você se reune com seus usuários para definir um sistema é muito comum que alguém apareça com requisitos que não fazem o menor sentido e que não agregam o menor valor para o software.

Uma vez fazendo levantamento para o desenvolvimento de um sistema alguém me pediu para mostrar em algum lugar da tela a quantidade de pessoas logadas. Tá, eu confesso que era uma coisa relativamente simples de ser feita. O que acontece é que no meio de tantas coisas realmente importantes fazer aquilo me parecia completamente estúpido e inútil.

Então, tentando espremer o usuário, fiz aquela pergunta clássica: “e para que você vai usar isso?”. Normalmente o cara responde alguma coisa vazia como: “eu preciso saber quantas pessoas tem logadas no sistema para ver se tem um número bom de pessoas trabalhando”. E você fica sem saber o que responder e acaba aceitando.

Segundo Scott Bellware, uma forma eficiente de resolver este problema é perguntar para o usuário da forma correta. Ele escreveu um post no Code Better sobre como utilizar uma abordagem de behaviour-driven development para discutir funcionalidades de um sistema.

Neste caso, eu poderia ter perguntado para o usuário: “você poderia me descrever uma história com este requisito?”. Desta forma eu faria com que o usuário percebesse que nenhuma situação de uso real do sistema iria requerer que tal funcionalidade existisse. Na verdade este é o benefício principal de Behaviour-Driven Development. A idéia é que pensando na forma como o software irá se comportar você consegue perceber com mais clareza qual é o comportamento realmente necessário e não o que você imagina que seja necessário.

Desenvolver um sistema a partir de um comportamento necessário faz com que você desenvolva software que atende aos usuários. Já desenvolver um sistema a partir um dado que deverá ser apresentado pode fazer com que você desenvolva software inútil sem se preocupar ou entender o que realmente importa.

Parte da nossa missão trabalhando com desenvolvimento de software é guiar o usuário e fazê-lo entender o que ele realmente precisa, não o que ele acha que quer ou acha que precisa.

Firefox é mais popular entre os desenvolvedores

Thursday, August 16th, 2007

Ultimamente um dos meus passatempos prediletos é ficar navegando no Google Analytics do meu blog e de outros sites que tenho e/ou administro (o Tiago também se amarra, eu não sou o único louco). Para quem não sabe o Google Analytics é uma ferramenta que gera estatísticas de acesso diversas de um site, como por exemplo: a quantidade de visitantes por período de tempo, sistemas operacionais e browsers mais utilizados, palavras mais buscadas e várias outras coisas mais, tudo disposto de forma organizada e com gráficos bem bonitinhos.

Analisando estas informações percebí que, enquanto em alguns sites de entretenimento da minha empresa aproximadamente 10% dos visitantes usam Firefox, no meu blog 70% dos visitantes usam ele!

Todos os meus amigos desenvolvedores (ou quase todos) usam o Firefox. Sem brincadeira, hoje em dia praticamente ninguem cogita a hipótese de usar Internet Explorer mais. O Toninho (gerente da minha área) até brinca que vai mandar embora quem não estiver usando o Firefox.

Em compensação, das 10-15 pessoas da minha família ou conhecidos próximos que perguntei, nenhuma delas sequer tinha ouvido falar do Firefox. Nem o meu irmão que tem 20 anos e é mais espertinho conhecia. A única que conhece é a minha esposa (que aliás é o meu orgulho porque é a única mulher que eu conheço pessoalmente que sabe usar Linux, Mac e Windows/Safari, Firefox, IE, Opera, Camino e mais algum que eu possa ter esquecido… – não que ela goste dessas coisas mas como sou eu que administro o departamento de TI da nossa casa, ela tem que usar o que eu decido que é bom).

Dá para perceber que as pessoas leigas acham que internet = Internet Explorer. Em compensação as pessoas com um pouquinho mais de conhecimento já entendem os problemas de segurança e bugs do IE e por isso usam o Firefox.

Isso tudo de certa forma explica o porque dos números do meu blog serem completamente diferentes de um site de entretenimento. O público alvo do meu site são desenvolvedores e o público alvo de um site de entretenimento é… qualquer pessoa!

Alguém aí pode passar suas estatísticas para compararmos?

AJAX Compilation

Tuesday, July 3rd, 2007

Ajax Compilation é uma compilação de referências para diversas APIs e bibliotecas AJAX que você pode usar em seus sites para torná-los mais interativos.

Basicamente o dono do site teve o trabalho de catar para nós um monte de sites legais na internet e criar um catálogo deles, colocando um link para o site da ferramenta e para o demo online (quando é oferecido pelo site da ferramenta).

Nem tudo catalogado lá é AJAX, algumas coisas são em Flash e outras são em puro Javascript mesmo. Mas o que importa é que tem um monte de coisinhas legais e vale apena dar uma olhada. Recomendado para o cinto de utilidades dos desenvolvedores web. ;)

Programadores ou apertadores de botão?

Wednesday, June 27th, 2007

Ontem estava conversando com uns amigos sobre os novos programadores que estão surgindo por aí, especialmente os que usam o Visual Studio .Net. O Visual Studio nem parece que foi feito para pessoas que sabem programar. Muitas vezes não dá para fazer certas coisas programando código mesmo, você é obrigado a usar um dos milhares de wizards da ferramenta.

Um dos meus amigos estava contando que quando ele começou a programar estava precisando colocar um combo box numa página e os itens deste combo precisavam ser lidos de uma tabela do banco de dados. Ao procurar na internet para descobrir como isso era feito, as únicas referências que ele encontrou eram de wizards! Simplesmente ele não conseguia encontrar uma página que mostrasse o código para fazer o que ele queria.

Eu ainda não tirei minhas conclusões definitivas sobre isso. Ás vezes eu acho que as pessoas estão ficando preguiçosas, ás vezes eu acho que falta mesmo qualificação para os programadores e ás vezes eu acho que é tudo isso ao mesmo tempo. Ultimamente a quantidade de gente desse tipo tem aumentado muito por aí. As novas ferramentas de desenvolvimento estão tornando os programadores em apertadores de botão!

Programar é uma atividade intelectual que exige conhecimento técnico (linguagens, plataformas, sistemas operacionais, tecnologias), conhecimento específico sobre o negócio para o qual o sistema é desenvolvido, capacidade de resolver problemas e criatividade. Quanto mais as pessoas se preocuparem em aprender sobre ferramentas ao invés de tecnologias e práticas de desenvolvimento, mais vão surgir os apertadores de botão e as características acima vão sendo substituídas por conhecimentos de wizards, opções da ferramenta e botões diversos que fazem coisas mágicas.

Na semana passada saiu um artigo na Artima entitulado Visual Development versus Coding que fala exatamente sobre isso.

A opinião do David Intersimone é a mesma que a minha: é muito legal ter ferramentas visuais para te ajudar a fazer as coisas, note bem, para AJUDAR. Mas se você precisar (e vai), você tem que saber codificar.

Asshole-Driven Development

Thursday, June 21st, 2007

Isso mesmo: desenvolvimento guiado por idiotas.

Scott Berkun, autor do livro The Myths of Innovation (que está na minha fila de livros para ler) escreveu um post muito bem humorado no seu blog, entitulado Asshole-Driven Development. Ele descreve várias “metodologias” de desenvolvimento de software amplamente utilizadas em várias empresas (pelo visto não só no Brasil).

A metodologia que eu mais gostei foi essa:

Asshole Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.

Otimização prematura

Friday, June 15th, 2007

Dando uma olhada em uns projetos que estavam no meu Eclipse encontrei um projeto antigo de uma empresa que eu trabalhei. Esse projeto teve o desenvolvimento mais curto da história: 1 dia! É sério, ele acabou no mesmo dia que começou por uma série de razões.

Mais isso foi só uma pequena introdução, a história de verdade não é essa. Dê uma analisada num trecho de código deste projeto que foi desenvolvido por alguém lá da equipe (detalhe: leia atentamente o comentário):

public class Usuario implements BussinessObjectModel {
 
    protected UsuarioDTO usuarioDTO;
 
    public void login() throws Exception {
        if(this.usuarioDTO == null || this.usuarioDTO.getSenha() == null || this.usuarioDTO.getUsuario() == null) {
            throw new Exception("Erro");
        }
 
        /**
         * TODO: codigo do login.
         * ir no banco de dados, decriptar a senha, comparar
         * com o cara. logar no JMS, mandar um SMS, atualizar
         * o cache de usuarios, fazer uma chamada ejb remota
         * dizendo que o usuario entrou.
         */
    }
}

Donald Knuth já dizia que a otimização prematura é a raiz de todo o mal. Mas acho que quando ele disse isso jamais imaginaria uma otimização TÃO prematura. Em toda a minha vida esse foi um dos maiores exemplos de overdesign que eu já ví!

Repare: era o primeiro dia do projeto. Nem sabíamos direito o que precisava ser feito e o cara já decidiu que a aplicação deveria ter DTOs, JMS, EJB e cache de usuários… Sem sequer pensar no problema o programador decidiu adicionar uma complexidade enorme e desnecessária ao sistema.

Quando se desenvolve um projeto de software, a primeira coisa que deve-se fazer é atender aos requisitos funcionais do cliente da forma mais simples e rápida possível. Em seguida faz-se refactoring do código para que ele seja melhorado e no futuro possa se adaptar melhor a eventuais mudanças. E só.

Isto significa que neste momento você não se preocupa com cache, por exemplo. Se por acaso algum dia houverem problemas de performance, aí sim, pensa-se em cache, distribuição da aplicação e etc. Neste caso esta aplicação estava prevista para ter pouco mais de 10 usuários simultâneos, uma quantidade de acessoss ridícula para se pensar em otimização.

Os desenvolvedores têm uma mania horrorosa de overdesign, especialmente os desenvolvedores Java. É preciso parar de tentar adivinhar o futuro e se concentrar mais nos problemas que precisam ser resolvidos agora. Deixe os problemas do futuro para serem resolvidos no futuro!

Como produzir software “coxa”

Friday, June 8th, 2007

Acabei de ler um post no blog do Phillip que me lembrou de uma história que eu queria escrever aqui.

A história que você lerá a seguir é uma dramatização do que acontece diariamente no mundo do desenvolvimento de software carinhosamente entitulada Como desenvolver software “coxa”.

Imagine uma empresa que está com necessidades de desenvolver um software. E imagine também que esta empresa (cliente) contratou uma empresa de 3 letras para fazer o trabalho.

Então, o projeto começa com a empresa contratada fazendo uma análise extensa do que será desenvolvido. Caso você não saiba, estas empresas te fazem acreditar que o RUP tem uma fase de análise antes de tudo, quando isso na verdade caracteriza um processo de desenvolvimento waterfall que é bem diferente do processo de desenvolvimento iterativo do RUP.

Depois de analisar exaustivamente tudo que precisa ser feito, eles acham que sabem tudo que o cliente precisa e com isso acham que sabem exatamente quanto tempo irá levar. Baseado nisso é estipulado um prazo de entrega do software para o cliente, assim como é estipulado um preço fixo para o trabalho.

Fechado o contrato, o projeto é iniciado. E quando começa o projeto sempre acontece a mesma coisa: a equipe de desenvolvimento começa a descobrir que certas coisas não são tão simples quanto pareciam ser. A equipe se depara com vários problemas que não haviam aparecido na fase de análise e cada vez fica mais chocada com a quantidade de coisas novas que vão surgindo. Nesse momento a equipe percebe que o projeto, que estimou-se que precisaria de 4 meses para ser desenvolvido, na verdade precisa de 8 meses para ser desenvolvido!

Então alguém surge com a brilhante idéia de contratar mais pessoas para a equipe. Afinal de contas, da mesma forma que nove grávidas conseguem parir um filho em um mês, 20 desenvolvedores conseguem fazer na metade do tempo o trabalho que 10 fariam – parece perfeito!

Mas espera aí, o preço já está combinado com o cliente desde o início. Então contratar mais pessoas é a maior furada, porque o cliente não pagará nada a mais por isso e se o custo do projeto for maior a empresa não terá lucro. Pior ainda, a empresa pode ter prejuízo! Neste momento a empresa decide comuncar ao cliente que o projeto terá que atrasar.

Quando a empresa vai dar a notícia para o cliente o cara normalmente quer matar o gerente do projeto, quer se matar, ou OS DOIS (depende do tamanho do projeto)! Afinal de contas ele pagou 50% adiantado e quer logo o retorno do seu investimento. Se o projeto ia demorar 4 meses e agora vai demorar 8, significa que todo o seu planejamento financeiro e de retorno de investimento do software foram por água a baixo. Nesse momento o cliente bate na mesa com força e diz: “se virem, eu não quero nem saber como vocês vão fazer mas eu quero o meu software na data combinada!”.

Exatamente neste momento foi parido um software “coxa”!

Vou explicar fazendo uma analogia: qualquer criança de 10 anos sabe que não existe “bom, bonito e barato”. Ou é bom, bonito e CARO; ou é RUIM, bonito e barato; ou é bom, FEIO e barato. Não tem jeito, é assim que funciona, não é possível ter tudo ao mesmo tempo.

Com software funciona exatamente da mesma forma. Só o que muda são as dimensões: qualidade, tempo e custo. Da mesma maneira que não existe nada bom, bonito e barato, não existe software “bom, desenvolvido rápido e barato”. Ou é bom, desenvolvido rápido e CARO; ou é bom, DESENVOLVIDO EM MUITO TEMPO e barato; ou é RUIM, desenvolvido rápido e barato.

No caso deste projeto repare que duas das dimensões do software não podem ser alteradas: preço (porque já foi combinado com o cliente e está em contrato) e tempo (porque a data de entrega já está estipulada). Sendo assim, como não dá para ter tudo ao mesmo tempo, a qualidade vai para o brejo. Neste momento é que vem a ordem do gerente de projeto: “gente, faz qualquer coisa aí, o importante é entregar o que foi combinado com o cliente, não importa como, faz tudo nas coxas mesmo!!”. E mais um software “coxa” será entregue.

Se eu contar os softwares “coxa” que eu já ví por aí ninguém acredita. O mais bizarro deles e que não poderia deixar de ser citado tinha o seguinte código na tela de autenticação (PHP):

if (($_REQUEST["login"]  == "admin") && ($_REQUEST["senha"]  == "1234")) {
    header("Location: index_autenticado.php");
} else {
    header("Location: index.php?mensagem=Login%20invalido");
}

No final das contas, quando o projeto é entregue, o cliente vê as telinhas e se as telinhas estiverem aparecendo e estiverem no mínimo bonitinhas ele vai dar pulos de alegria! Eventualmente até irá contratar a empresa para outro projeto ou indicar para amigos e outros projetos dentro da sua empresa. Por baixo dos panos existe esse monte de lixo, mais ou menos como um vulcão que pode entrar em erupção a qualquer momento causando efeitos devatadores! Deixa só alguém pedir para trocar a senha do sistema para ver o que vai acontecer…

Para mim é claro como água: não adianta querer prever tudo que acontecerá no projeto e pré-fixar datas e valores. É receita certa para fazer lixo. Já está mais do que provado que não funciona, porque insistir no mesmo erro?

Se você que está lendo se identificou com a história (o que não é nem um pouco difícil), sugiro fortemente que você leia sobre um modelo de contrato de desenvolvimento de software proposto pelo XP que muito me agrada: o Contrato de Escopo Negociável. O artigo é bem grande mas vale apena ler até o final! Você vai perceber que as coisas não precisam ser assim tão tristes nos projetos de desenvolvimento do software.

“Gambi” Design Patterns

Wednesday, May 30th, 2007

Acabo de fazer minha humilde contribuição ao catálogo de “Gambi Design Patterns”, os padrões de projeto utilizados pelos programadores praticantes de POG (Programação Orientada a Gambiarras).

O padrão catalogado foi o Rest Assurance Memory Allocation Pattern que consiste em alocar uma quantidade “um pouquino” maior de caracteres que uma String precisaria, só para garantir.

Vale apena dar uma olhada nos outros padrões que também são muito interessantes. Eu já ví VÁRIOS deles em prática!!! :)