Desenvolvi uma lista com algumas questões que devem ser observadas por todo programador. (lista baseada no artigo de Alberto Gutierrez ).

1. Seja disciplinado:
No nosso dia-a-dia nos deparamos com diversas interrupções e tarefas paralelas. Telefone tocando, email, mensagem instantânea, colega chamando e diversas outras. Ser disciplinado significa estabelecer uma metodologia para que essas interrupções prejudiquem o menos possível o seu desempenho e produtividade. Utilização de técnicas como a técnica do pomodoro, por exemplo, é uma excelente metodologia para manter o foco em uma tarefa por vez.

2. Seu ego não é tudo:
Ser autoconfiante e ter uma boa auto-estima é diferente de ter um grande ego. Programadores precisam ter segurança e domínio do que fazem para serem colaborativos expressando sua opinião, mas, não exagere. Escute o que os seus colegas têm a dizer. Mantenha a mente aberta e analise as opções de todos antes de se apegar a sua solução como se fosse a melhor de todas. Se estiver errado sobre algo, não se envergonhe de dizer “você tem razão” ou “eu estava errado”.

3. Seja um bom comunicador:
Facilidade em falar e desinibição são apenas algumas das habilidades requeridas para uma boa comunicação. Seja conciso ao falar. Evite fugir do assunto e usar termos prolixos sem necessidade. Em uma discussão, procure ouvir e entender a outra parte antes de responder. Ser educado também faz parte de uma boa comunicação. Evite gírias fora de contexto.

4. De novo…o cliente:
Não faça de uma tarefa de codificação a sua diversão acima de tudo. Acredito que muitos programadores devem adorar ficar experimentando e especulando arquiteturas e algoritmos, mas não exagere. A entrega para o cliente nunca deve ser penalizada. Se houve um comprometimento de prazo com o cliente é melhor abrir mão de “seu código-arte” e focar na melhor estratégia que de retorno imediato para o cliente. Resolva o problema primeiro.

5. Não esqueça o que é prioridade:
Sempre existem funcionalidades que são mais importantes que outras, e essa priorização deve ficar clara e ser respeitada. Esse item é um complemento ao anterior. A procura por novas tecnologias, componentes e arquiteturas devem ser feitas com cautela de forma a não prejudicar o que foi priorizado.

6. Existe um mundo além do código:
Codificar é apenas umas das competências que um programador deve ter. Existe um mundo lá fora. Autogerenciamento, atenção aos prazos e metas, colaboração com a equipe, atenção aos horários, manutenção de um bom ambiente de trabalho evitando que o mau humor e o pessimismo contaminem os demais membros da equipe são apenas algumas das coisas que o programador deve ter em mente.

Se você e sua equipe são adeptos do scrum ou outra metodologia ágil provavelmente devem conhecer ou utilizar testes unitários, mas não necessariamente o desenvolvimento orientado a testes (TDD). O teste unitário consiste basicamente em validar dados válidos e inválidos via entrada e saída, já o TDD utiliza teste unitário como parte de sua metodologia cujo principal objetivo não é testar as unidades (é um dos objetivos, mas não o único).

Em um cenário de desenvolvimento ágil, sem uso de TDD, o programador geralmente não conta com um modelo de classes em forma de diagramas – como outras metodologias pesadas. Por isso é comum a modelagem ser feita apenas mentalmente, em algum outro formato (rascunho em papel de pão?) ou até mesmo diretamente no código. As classes, operações e atributos vão surgindo conforme a necessidade, e são constantemente alterados e implementados até a conclusão da tarefa associada. Eventualmente, alguns testes de unidade são implementados baseando-se nas classes já prontas.

Este tipo de abordagem implica em alguns problemas, entre eles:

• o programador não tem segurança em saber quando uma implementação acabou;
• o programador não precisa implementar a classe de forma que ela fique desacoplada das demais;
• o programador tende a não desenvolver para a interface e sim para a implementação;
• métodos não coesos (fazem mais ou menos do que deveriam fazer);
• nomes de atributos e operações não representam adequadamente a funcionalidade.

O TDD pretende resolver todas as deficiências citadas acima e várias outras. Mas, o que é o TDD? TDD ou Test Driven Development pode ser considerada uma metodologia de design de software, onde escrevemos primeiro um teste e depois o código necessário para o teste passar. A idéia é que o desenho das classes seja guiado pelos testes. O TDD força o desenvolvedor a pensar primeiro em o que ele precisa, e em como fazer, via teste unitário, para testar se a implementação a ser feita fará o que deve, nada mais e nada menos. Com isso, se ganha em vários aspectos:

• as classes devem ser desacopladas, senão o teste não pode ser executado;
• os métodos são bem coesos, ou seja, fazem somente o necessário para o teste passar;
• o programador sabe exatamente quando concluiu uma implementação, pois o teste passou;
• o programador consegue validar rapidamente uma alteração que pode ter causado um impacto em outras unidades, apenas rodando um conjunto de testes;
• operações e atributos possuem nomes claros e representam exatamente o que fazem.

O workflow do TDD pode ser descrito basicamente em cinco passos básicos:

1. Crie a classe de teste e o primeiro teste
   1. Nesse ponto o programador deve pensar em como será a assinatura do método testado. O fato de ter que escrever um teste para o método, faz com que, tanto o nome quanto os parâmetros de entrada e saída sejam bem claros e coesos.
2. Compile o teste
   1. O teste não vai compilar. Neste momento, crie a classe e a declaração do método. Recompile e rode o teste. O teste deve falhar, pois o método testado ainda não está implementado.
3. Implemente o código testado de modo que o teste falhe
   1. O objetivo do teste é detectar defeitos, e essa fase é importante para averiguar se o teste está cumprindo seu papel. Geralmente codificar para que o método testado retorne um valor errado é o suficiente. Rode o teste e veja o teste falhar.
4. Agora corrija o código, de forma que o teste passe
   1. Implemente o suficiente para o teste passar. Você deve garantir que o teste exija o suficiente. Se precisar implementar mais do que o necessário para o teste passar, provavelmente seu teste não está bom o suficiente, ou seu método não está coeso. Neste caso, refaça o teste ou corrija a implementação do código testado.
5. Faça alguma refatoração necessária e reexecute os testes
   1. Na fase anterior nos preocupamos apenas em fazer o teste passar. Nessa etapa, faça uma revisão no código e veja se precisa de alguma refatoração. Em seguida rode todos os testes construídos até agora para certificar-se de que a refatoração não quebrou algum outro código.

Antes que me perguntem: TDD não é burocrático e demorado?.  Não. Usar TDD não implica em aumentar o tempo de desenvolvimento. Desconsiderando o tempo de adaptação de sua equipe, a tendência é que o desenvolvimento com TDD aumente consideravelmente a produtividade, e, consequentemente, a segurança e qualidade dos produtos desenvolvidos. Essa é a experiência de quase toda equipe de aderiu ao TDD, e provavelmente sua equipe só vai se sentir confortável com a idéia quando efetivamente aplicar os conceitos da metodologia.

Neste artigo não abordei as ferramentas de teste unitário, pois não é o foco do TDD, porém praticamente todos os ambientes de desenvolvimento moderno possuem algum framework de testes unitários. Posso citar alguns: NUnit (C#), DUnit (Delphi) e JUnit (Java). Escolha o que melhor se adequar a sua realidade.

Programar muitas vezes é considerado como sinônimo de codificar, ou seja, escrever código para ser compilado. A importância de um bom algoritmo na qualidade final de um software é indiscutível e não pretendo levantar discussões a este respeito por aqui, mas colocar em pauta outro aspecto – que também é programação – porém nem sempre tem a atenção merecida: a interface gráfica, ou, mais precisamente, a interface de usuário (IU).

Assim como a parte que fica por debaixo dos panos (o código) a interface gráfica tem uma importância fundamental para o sucesso de seu sistema. Padrões de projeto (Design Patterns), Grasp, POO, POA e etc. São inúmeras as técnicas existentes para auxiliar a construção de excelentes softwares. Mas, quantos de vocês conhecem alguma para desenhos de interfaces gráficas? O que deve ter em mente o programador ou projetista de interface para construir uma boa IU?

Imagine a seguinte situação: você acabou de liberar uma nova versão de seu sistema com um novo e badalado recurso de cálculo de preço, baseado em uma intricada fórmula de previsão de custos, cujo código você morre de orgulho de dizer que foi de sua autoria. A janela que implementa este recurso possui alguns campos para digitação dos materiais aos quais o usuário pretende calcular o preço, e, eventualmente atualizar seu cadastro de produtos com os valores obtidos. O que parecia ter tudo pra ser um sucesso não repercutiu como o esperado, e você logo se pergunta: o que pode ter saído errado? O código está perfeito, fiz testes unitários e utilizeis todos os padrões GoF aplicáveis, entretanto, um recurso que teria tudo pra ser um sucesso não está sendo utilizado como o esperado.

Voltando a atenção à interface do usuário, constatamos que ela possui uma grave falha: o sistema possui um cadastro de produtos extenso, e a nova tela não permite que o usuário faça uma seleção para importar os produtos pelo grupo, por intervalo de código, por classificação ABC ou por algum outro critério. O usuário, frustrado por não conseguir digitar os produtos com facilidade, acaba evitando utilizar o novo recurso. Se uma análise de usabilidade fosse feita ANTES de o recurso ser liberado ao mundo externo, o resultado seria diferente.

A palavra chave, quando falamos em IU, é USABILIDADE. Interfaces gráficas foram feitas para – além de serem bonitinhas – facilitarem o trabalho de quem as utiliza. Beleza sem usabilidade é a mesma coisa que uma Ferrari sem volante. É linda, porém não vai servir para o propósito ao qual foi feita.

A tarefa do projetista de IU não é fácil. Cometemos vários equívocos ao desenhar uma nova janela ou página apenas porque não pensamos como um usuário. E não é pra menos: nós não somos usuários. Se colocar no lugar do usuário é uma tarefa difícil e é o segredo para o sucesso de qualquer IU. Com qual freqüência o recurso será utilizado? É crítico? Velocidade faz diferença? É acessível via teclado ou exige o uso do mouse?

Chega de perguntas. O objetivo é apenas um:

Uma boa IU é aquela que se comporta da forma como o usuário espera que ela se comporte.

Simples, direto, claro. Se você coloca um botão lindo com ícones em 3D, mas não deixa claro para o que ele serve, não está construindo uma interface boa para o usuário. Coloque legendas claras e, se possível, hints explicativos e teclas de atalho explicitas, pois nem todo mundo gosta ou pode ficar utilizando mouse (cansa mais que teclado, principalmente em tarefas repetitivas). Se o padrão do sistema operacional é que em caixas de mensagens o botão OK venha antes do Cancelar, siga desta forma. Se tem um recurso não implementado, não coloque o botão na janela apenas para que o usuário tenha que clicar e ver que nada acontece. Recursos incompletos são piores que a ausência total deles.

Outra característica interessante relacionada ao usuário: eles não gostam de ler. Não adianta fazer um manual explicando como utilizar a nova janela, pois eles não o lerão de forma alguma. Da mesma forma, não adianta escrever caixas de diálogos com textos explicativos muito grandes. Eles não lerão e sequer pensarão em clicar em OK ou Cancelar antes de apertar a tecla ENTER do teclado. Textos curtos e claros são ideais. Ao invés de dizer: ‘Você apertou a tecla X, tem certeza que quer executar o procedimento X?’ utilize ‘Executar X?’.

Muitos usuários também são inseguros, portanto, evite questionar as ações dele a menos que seja necessário. Mensagens do tipo: ‘Tem certeza que deseja fazer isto?’ ou ‘Isto vai finalizar o sistema, tem certeza que quer finalizar o sistema?’ tem efeito negativo, pois sugere ao usuário que ele fez algo que não devia. É mais adequado usar: ‘Sair agora?’ ou ‘Fazer X?’.

Usuários gostam de pensar que recursos parecidos devem se comportar da mesma forma. Então, se vai construir uma janela nova, pergunte-se se não existe um padrão a ser seguido. Não inove sem critério, um aplicativo cujas IUs tem aspectos funcionais diferentes umas das outras são difíceis de usar. Se o botão para sair da janela se chama ‘Sair’, utilize sempre assim e não ‘Fechar’, ‘Encerrar’. Se a tecla ESC fecha a tela, procure disponibilizar o mesmo atalho para todas as janelas. A janela de Contas a pagar pode ser redimensionada, então a janela de Contas a receber também o deve.

Tem dúvida sobre qual melhor abordagem para um recurso? Não invente, pergunte ao usuário, faça um teste de interface com ele, observe como ele interage com os botões, menus e mensagens. É a melhor forma de descobrir.

p.s. Acabei de digitar o texto aqui no Word, e tentei selecionar tudo usando a combinação de teclas CTRL+A, que é padrão na maioria dos editores de texto. Não preciso falar que não funcionou, lembrei que no Word é CTRL+T.

A programação orientada a objetos é, de longe, o paradigma mais utilizado em programação. Com várias décadas de existência, (apesar de muita gente não saber, a OO surgiu com as linguagens SIMULA I (1962-65) e Simula 67 (1967)) evoluiu bastante, porém, é muito comum encontrar projetos com problemas de arquitetura dos mais diversos tipos, entre eles, problemas de coesão, acoplamento desnecessários, generalizações inconsistentes e outras.

O intenção deste artigo é introduzir o conceito de GRASP (General Responsibility Assignment Software Patterns), que, conforme o nome já diz, tem o objetivo de tornar a distribuição de responsabilidade entre as classes uma tarefa mais criteriosa e eficiente, melhorando de forma significativa a qualidade de seu projeto e reduzindo os problemas de arquitetura mais comuns.

A maioria dos programadores aprendeu que em POO devemos mapear objetos reais para objetos em seu modelo de classes. Isto muitas vezes é seguido a risca, mas nem sempre é a melhor maneira de modelar suas classes, pois muitos detalhes cruciais só são visíveis ao se considerar o contexto geral, ou seja, a forma como esses objetos vão interagir e como eles vão colaborar uns com os outros. Os padrões GRASP surgiram exatamente para auxiliar nesta questão.

O GRASP descreve ao todo nove padrões ou princípios, a saber:

1. Especialista de informação (Expert)
2. Criador (Creator)
3. Alta coesão (High coesion)
4. Baixo acoplamento (Low coupling)
5. Controlador (Controller)
6. Polimorfismo (Polymorphism)
7. Invenção pura (Pure Fabrication)
8. Indireção (Indirection)
9. Variação protegida (Protected Variations)

Cada um destes padrões trata de um problema específico, e sugere uma solução de arquitetura para superá-lo. A solução pode utilizar alguns dos consagrados padrões GoF (que poderá ser assunto aqui no AgileZ), portanto é recomendável que o programador ou analista conheça bem soluções como Observer pattern, Proxy, Iterator, Adapter, Strategy, Singleton entre outros.

Antes de começar a descrever cada um dos nove padrões, convém conceituar o que é responsabilidade. Uma responsabilidade pode ser descrita como uma obrigação, seja obrigação de fazer ou conhecer alguma coisa.

Fazer algo:

• a si mesmo
• começar ações em outros objetos
• controlar ações em outros objetos

Conhecer algo:

• informações encapsuladas
• objetos relacionados
• informações que pode calcular

Exemplo: uma classe Memo pode ter obrigação de gerar linhas (faz algo a si mesma), ou pode utilizar uma classe Linha para isso (inicia uma ação em outro objeto) e controlar essas ações mantendo um contador de linhas (informações encapsuladas). Para isso, o Memo deve conhecer a classe Linha (objetos relacionados).

Não devemos, entretanto, confundir métodos/operações com responsabilidades. Um ou vários métodos devem ser utilizados para implementar uma determinada responsabilidade.

I. O padrão Expert (Especialista de informação)

O primeiro padrão que deve ser considerado para resolver o problema de atribuição de responsabilidade é o Expert, que diz que o primeiro candidato a receber a responsabilidade é aquele que possui a informação necessária para executar a tarefa.

O exemplo mais comum é o da venda. Nosso sistema precisa calcular o total de uma venda. Qual classe deve ser responsável por fazer este cálculo?

Sabemos que, para calcular o total de uma venda, precisamos somar os totais de cada item, além do desconto e juros, se houver. Olhando o diagrama, fica fácil observar que a classe Venda é a classe que mantém a lista de itens (dona da informação), portanto ela é a primeira candidata a calcular o total.

Utilizando o padrão Expert, atribuímos à classe Venda a responsabilidade por calcular o total da venda. Como será feito o cálculo internamente? A classe Venda deve iterar pelos itens, somando os valores de cada um e depois subtrair os descontos e somar os acréscimos. Mas, e o valor do item, quem deve calcula-lo? Aplicando novamente o padrão Expert, podemos observar que é o Item quem possui a informação necessária para essa tarefa (quantidade), e o produto é quem possui o preço, logo, as responsabilidades, seguindo o padrão Expert, ficariam assim:

É lógico que este foi um exemplo bem simples, e provavelmente nenhum analista precisaria conhecer o GRASP para chegar ao modelo proposto, mas, ao tratar de relacionamentos e projetos mais complexos, fica bem mais difícil manter um modelo consistente, altamente escalável e flexível, sem conhecer bem esses padrões.

Vamos continuar com os demais padrões GRASP em nossos próximos artigos. Fiquem a vontade para dar sugestões e críticas.

Existe uma cultura entre os programadores na qual a máxima ‘use comentários sempre que puder e deixe seu código bem explicado’ é praticamente uma lei fundamental da programação. Pouca gente discute isso, afinal, nada como um código bem documentado para torná-lo legível, certo? Nem sempre. E é sobre esta questão que eu vou falar neste artigo. Quando devemos usar comentários? Até que ponto comentar é uma boa prática? Existem outros artifícios que podemos usar para substituir um comentário?

Para começar, vamos voltar um pouco pela história. Há muito tempo, os compiladores tinham uma limitação de memória, onde existia um limite de caracteres por arquivo compilável. Em consequência disso, os programadores eram obrigados a serem muito seletivos e econômicos ao codificar, usando o menor número de caracteres para nomes de operações, variáveis e etc. Imagine um complexo código de ordenação onde todas as variáveis tivessem apenas um caractere. A primeira variável seria a variável ‘a’, a segunda ‘b’, a terceira ‘c’. Qual seria sua reação, ao ‘tentar’ ler esse código? Um pouco confuso, provavelmente. Nessa hora qualquer um rezaria por encontrar um código bem comentado.

Integer a = 0; //armazena o maior valor encontrado

Nota-se que a origem dos comentários teve motivações bem legítimas, e eram praticamente indispensáveis.

Desde então, os compiladores evoluíram, o hardware mudou muito, e hoje, finalmente, não temos problema algum relacionado a limite de memória (pelo menos não significativamente) que nos limite na hora de codificar. Porém, muito da antiga cultura ainda permaneceu. Programadores mais antigos não abriram mão de suas variáveis de um caractere e continuam usando comentários para explicá-las, influenciando muitos os novos programadores, e nem todos conseguem chegar a um nível de maturidade suficiente para superar esse limite auto imposto.

Veja como, na linha abaixo, o comentário torna-se desnecessário, ao contrário do código anterior.

Integer maiorValor = 0; //armazena o maior valor encontrado

Como não temos mais o limite de memória, fica fácil nomear a variável de forma a um comentário se tornar insignificante. Uma outra questão também deve ser citada: temos mais facilidade em descrever uma coisa do que dar nomes. Talvez por isso muitos programadores preferem comentar a ter que pensar em um nome que descreva o motivo da variável, função, classe e etc. Mas, mesmo assim, um bom nome é melhor e deixa o código mais fácil de ser lido e entendido. Vale a pena investir mais tempo para elaborar melhor os nomes em seu código.

Martin Fowler costuma dizer que, se seu código precisa de comentários para ser entendido, então é porque ele não está bem escrito. Essa idéia está presente também nessa outra frase bem conhecida, também de sua autoria.

Qualquer tolo pode escrever código que um computador pode compreender, mas bons programadores escrevem códigos que os seres humanos possam compreender. [Fowler 2000]

É lógico que não podemos ser extremistas a ponto de abolir os comentários do nosso código. Muito pelo contrário. Existem ocasiões – não raras – onde comentar é essencial ou, no mínimo, construtivo.

/*usei int p/ manter compatibilidade com uso da dll xz.dll*/

int indice;

Antes de comentar uma linha, devemos sempre nos perguntar se o comentário agrega algo, ou se apenas tenta desfazer a confusão que foi gerada pelo código. Como insistirei frequentemente daqui pra frente: bom senso é sempre fundamental.

Atualmente, como parte dos estudos dos princípios Grasp (abordarei o que é Grasp aqui no AgileZ em breve), na equipe em que trabalho, adotamos o costume de documentar a ‘motivação’ que levou uma classe a ser desenvolvida, usando para isso um comentário – de no máximo umas 3 linhas – que explica o motivo da classe existir. Isso, como veremos em artigos futuros, é bem interessante e é parte de uma metodologia adotada por nossa equipe.

Passou longe do objetivo deste breve artigo a intenção de esgotar o assunto. Pretendo voltar discutir a questão de comentários no código quando falar sobre refatoração e também sobre usabilidade aplicada a codificação. Continuem ligados.

Um conceito simples, mas nem sempre bem entendido e aplicado. ‘Programar para uma interface e não para uma implementação’, você sabe o que isto significa?

Apesar deste conceito ser aplicável a projetos de software, é mais antigo que ele, e é utilizado bem antes do primeiro compilador ser desenvolvido. Um exemplo bem obvio do que é isto, pode ser encontrado na casa de qualquer pessoa: um interruptor de luz. ‘Como assim José?’.

Um interruptor de luz é um exemplo muito bom. Consiste em um botão, que liga e desliga a luz. Uma interface simples, que esconde os detalhes de implementação de quem vai utilizá-la. Para ligar a luz, basta apertar o botão, e para desligá-la, adivinhem? Aperte novamente. A implementação está bem encapsulada – o usuário não precisa entender nada de pólo positivo, neutro, 127v, amperagem ou resistência. Qual foi o pensamento do designer ao projetar um interruptor de luz? Com certeza foi algo parecido com: ‘qual o mínimo possível de informação o usuário do meu produto precisa para usá-lo?’.

Falando em programação de software, podemos aplicar este conceito a vários pontos. Quando estamos codificando, ao criar uma nova classe, devemos sempre nos fazer a mesma pergunta que o designer do interruptor de luz fez: ‘quais operações e atributos eu devo tornar públicos para que o usuário possa usá-la de forma simples?’ e a cada nova implementação: ‘será que eu preciso expor estes parâmetros? E esse novo atributo?’. Classes com menos operações e atributos públicos, geralmente são mais simples de serem utilizadas. Lembre-se sempre: outros programadores terão que interagir com as classes e bibliotecas que você desenvolveu. Mantenha a simplicidade e procure ser objetivo.

Ao criar uma nova tela de cadastro, analogamente: ‘quais controles o usuário vai precisar para executar as operações a qual a janela se destina?’. Um erro muito comum cometido por projetistas de interfaces gráficas é transmitir a forma de funcionamento interno do algoritmo para o usuário. O clássico exemplo são as telas de cadastro. Todo mundo desenvolve, ou já desenvolveu, uma tela com os famosos botões novo, editar, cancelar, excluir e salvar, pois é a forma como o seu algoritmo funciona, e fica mais fácil publicar essa característica para o usuário. Mas, será que o usuário realmente precisa de um botão ‘editar’ quando ele quer editar um registro? Não seria mais fácil o seu sistema detectar que alguém está tentando alterar um registro e simplesmente entrar em modo de edição, como funciona, por exemplo, um editor de texto? Um botão a menos na tela, na maioria das vezes, pode significar uma interface mais simples – que é o sonho de todo usuário.

Poderia citar dezenas de exemplo aqui, mas a idéia não muda. Um carro com câmbio automático é muito melhor do que um no qual você precisa apertar a embreagem para trocar de marcha. E ambos funcionam, só que o primeiro é mais simples.

É lógico que, ao começar a pensar dessa forma, o programador vai sentir necessidade de amparo por algumas técnicas que ele pode ainda não dominar – técnicas que serão abordadas por aqui – como padrões de projetos ou Grasp. Um caminho que provavelmente não terá volta, e fará de você um melhor projetista de software.