terça-feira, 28 de maio de 2013

Seu chefe, o cliente e a qualidade

Na área de desenvolvimento, muitos desenvolvedores são abençoados em ter gerentes que já foram desenvolvedores ou compreendem os processos envolvidos na construção de um software. Mas não raro é possível encontrar chefes que não entendem o trabalho que a equipe de desenvolvimento realiza.

Um desenvolvedor já precisa lidar no dia-a-dia com a pressão do cliente. Este não tem a obrigação de entender nos detalhes como é o processo de desenvolvimento de um software, mas estará sempre de prontidão para pressionar a equipe de desenvolvimento para realizar as entregas de funcionalidade. É comum que esta pressão passe antes pelo gerente da equipe. Se o seu gerente tem consciência de como é o processo de desenvolvimento de um software com qualidade, que exige algumas tarefas "incompreensíveis", como refatoração e testes, ele defenderá a equipe e irá absorver este pressão adequadamente.

Mas se o seu chefe não entende, a equipe ganha mais uma dor-de-cabeça.

Todos sabemos como funciona: "Isto precisa entrar amanhã!", "Precisamos disto para ontem!", "Por que ainda não terminamos?", "é pouca coisa, dá para fazer rapidinho e entregar"...

O recomendado é tentar fazer com que o seu chefe e cliente entendam o trabalho de desenvolvimento. É o desenvolvedor que é o profissional que vai construir o software, e ele deveria saber mais do que ninguém como fazer isto da melhor maneira possível.

Se alguém (gerente ou cliente) pedir a entrada de uma funcionalidade Y para amanhã, converse antes para saber o motivo. Em uma conversa, muitas coisas podem ser reveladas:

  • O seu chefe, ou cliente, não tem total consciência das consequências no sistema do pedido;
  • Deixe claro que as atividades que estão sendo realizadas neste momento serão atrasadas; alguns clientes tem a ilusão que ao pedir mais alguma coisa para determinada data, as que já estão em desenvolvimento não terão qualquer impacto.
  • Enfim, muitas coisas são urgentes quando, depois de uma boa conversa, deixam de ser;

 Se o consenso é que este pedido é importante, e que a data na qual esta funcionalidade precisa entrar não vai encaixar-se no processo adequado de desenvolvimento, deixe claro:

  • A funcionalidade Y será entregue na data prometida, mas no próximo dia um dos desenvolvedores deixará de continuar a trabalhar na funcionalidade X para refatorar o código ruim, escrito às pressas, deixado pela funcionalidade Y.
  • Se a conversa chegou no assunto "horas extras", seja prudente; nenhum ser humano é uma máquina que pode trabalhar por longas horas.

Agindo assim, tanto o seu chefe quanto o cliente não criarão a ilusão que podem realizar qualquer pedido para a equipe sem compartilhar as consequências negativas deste caminho. Até porque, se a equipe de desenvolvimento não corrigir o código ruim deixado, ou tomar qualquer outra ação para preservar a qualidade do software, as consequências serão muito piores para todos no futuro. É importante fazê-los entender que um código ruim hoje, fica pior ainda amanhã. Já dizia o Uncle Bob (Robert Martin):

No matter who. No matter what. No matter when. Short term. Long term. Any term. Writing good code is always faster than writing bad code.

No próximo texto vou falar do papel da empresa. Depois, podemos ir para a parte divertida: o código!

segunda-feira, 20 de maio de 2013

A equipe e a qualidade de código

A equipe é, com toda certeza, a que mais tem responsabilidade e controle sobre a qualidade do código. É a equipe que tem consciência da qualidade geral do código e de técnicas que visam a melhoria ou manutenção da mesma.

Das principais técnicas disponíveis, podemos citar:

  • Pair programming: 2 desenvolvedores trabalham em um mesmo computador. Comumente usado para tarefas mais complexas, também é muito útil para compartilhar conhecimento quando um dos membros do par tem menos experiência que o outro.
  • Code review: seja durante ou ao final do desenvolvimento de uma funcionalidade, um membro da equipe olha o código desenvolvido pelo outro membro. Embora hajam diferentes maneiras de fazer um code review, a que vejo como mais produtiva é quando o desenvolvedor da funcionalidade explica o código para o outro membro. Apenas neste simples processo, é possível enxergar erros e melhorias, que podem vir tanto por parte do autor do código quanto pelo desenvolvedor que faz o papel de revisor.

Muita pessoas citam estas 2 técnicas de desenvolvimento como se fossem opostas. No meu entendimento e experiência, a cada momento uma delas é mais interessante que a outra. Conforme mencionei anteriormente, se a atividade for mais complexa (seja tecnicamente ou pelas regras de negócio), o pair programming mostra sua força, pois atividades complexas abrem margem para um código com grande potencial de bugs e confuso. Com 2 desenvolvedores trabalhando no mesmo código, este risco é atenuado e mais para frente a tendência é economizar tempo, caso este código precise de correções ou evoluções.

O code review funciona bem quando um desenvolvedor com menos experiência termina uma funcionalidade e outro desenvolvedor com mais experiência olha o código. Neste processo, não só erros de lógica e regras de negócio podem ser detectadas, como também ocorre uma transferência de experiência e conhecimento.

Outra coisa interessante do pair programming e do code review, é que temos também um reforço contínuo do que precisa ser feito no desenvolvimento para a qualidade de código ser mantida ou conquistada. Como diria Samuel Johnson:

People need to be reminded more often than they need to be instructed

Voltando ao código, enquanto desenvolvedor, podemos dar o exemplo da checklist, do Code Complete:

  • Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
  • Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?
  • Are all output formats specified for Web pages, reports, and so on?
  • [...]

Enquanto equipe, podemos reforçar outros aspectos, também do Code Complete:

  • Have you defined how much design will be done up front and how much will be done at the keyboard, while the code is being written?
  • Have you defined coding conventions for names, comments, and layout?
  • Have you defined specific coding practices that are implied by the architecture, such as how error conditions will be handled, how security will be addressed, what conventions will be used for class interfaces, what standards will apply to reused code, how much to consider performance while coding, and so on?
  • [...]

Estes são apenas partes de diversas ações que precisam ser consideradas se a equipe realmente está preocupada com qualidade. Irei futuramente detalhar no blog estes e muitos outros aspectos.

segunda-feira, 13 de maio de 2013

O novato e a qualidade de código


Todos já fomos, um dia, um novato de desenvolvimento de software. Isto não é vergonha alguma. É natural, e até esperado, que os novatos cometam mais erros com frequência e encontrem mais dificuldades nas atividades diárias de desenvolvimento.

Muitos deles chegam nas empresas vindo de bons colégios técnicos, já sabendo programar em alguma linguagem, normalmente Java. O porém é que conhecer a linguagem de programação não é garantia que aquela pessoa saiba escrever um bom código. Não estou falando que ela vai precisar de anos para aprender isto também. Existe uma série de ações que poderiam ser feitas para/por esta pessoa recém-chegada na empresa, e que não é feito, que alteraria significativamente a qualidade do código escrito por ela.

Mas o que poderia ser feito? Estava eu outro dia na Amazon, olhando alguns comentários sobre um dos melhores livros de desenvolvimento de software já escritos, o Code Complete, livro este que citarei várias vezes neste blog. Foi quando me deparei com este comentário, e este trecho me chamou a atenção:
The most common criticism one hears about this book is that any decent software developer should already know the material covered in it. Ironically enough, this is true
Em uma tradução livre: "A crítica mais comum ouvida sobre este livro é que qualquer desenvolvedor decente de software deveria já saber do conteúdo coberto pelo livro. Ironicamente, isto é verdade".

Sim, é verdade. Há muito conhecimento que poderia ser facilmente passado para um desenvolvedor em início de carreira sem exigir necessidade de experiência para adquirir este conhecimento. Mas o que ocorre com frequência é que ele começa no projeto sem preparo e, dependendo da dinâmica do desenvolvimento, começa a cometer com frequência diversos erros. As consequências alguns já imaginam:
  • Código de difícil leitura;
  • Nomes ruins para variáveis, métodos, classes, etc;
  • Uso de variáveis globais;
  • "Reinvenção da roda";
  • Necessidade de refatoração posterior;
  • Estresse por parte de alguns membros mais experientes da equipe;
  • Bugs que poderiam ser facilmente evitados;
Boa parte destes problemas seriam evitados se ele tivesse uma boa comunicação com o restante da equipe. Mas estamos falando de alguém com sua primeira experiência de empresa, recém-chegado, querendo mostrar serviço, precisando lidar com outros estagiários "prodígio", com medo de fazer uma pergunta considerada "boba" por ele, recebendo pressão de entrega e até recebendo mais responsabilidade do que deveria... Devemos dar o braço a torcer e reconhecer que vários destes problemas acima citados são de responsabilidade da equipe também.

No próximo post, vou falar da equipe e o seu envolvimento na qualidade de código. Até mais!

quarta-feira, 8 de maio de 2013

Somos amadores chamados de profissionais?

O título é propositalmente provocativo. Embora somos considerados profissionais desenvolvedores de software (analista, engenheiro, etc...), eu observo, dia após dia, como somos ainda amadores no que fazemos.

Vamos, antes, a definição do termo amador (grifo meu):

Amadorismo é o nome dado ao desempenho de uma atividade profissional por pessoas sem conhecimento avançado do assunto e utilizando equipamentos e técnicas não-profissionais.

Se você utiliza-se de algum método ágil de desenvolvimento (Scrum, Kanbam, XP, etc), a equipe de desenvolvimento ganha uma grande (e necessária) liberdade. Liberdade esta essencial para a construção de um software que atenda as necessidades dos usuários, com o risco compartilhado entre o cliente e a empresa de desenvolvimento. Sendo a área de programação uma criança aprendendo a andar, os métodos ágeis já provaram ser o que temos de melhor para construção de um software atualmente.

Só que toda esta liberdade é confundida com libertinagem, e fazemos isto de uma forma inconsciente. Não é porque o desenvolvimento está livre de processos rígidos e desnecessários que devemos abandonar uma mínima organização e preparação.

Deixar de usar ferramentas que:

  • auxiliam no controle das versões;
  • controlam quais funcionalidades foram e estão sendo desenvolvidas;
  • procuram bugs;
  • executam automaticamente os testes;
  • etc;

Ou deixar de lado uma organização que poderia:

  • definir um padrão de nomenclatura para nomes de classes, métodos, ações do sistema;
  • crie um glossário dos termos mais comuns a serem utilizados;
  • centralizar as dúvidas e soluções para problemas comuns de ambiente ou tecnologia;
  • etc;

Estaremos abrindo mão da qualidade, não tenha dúvida. Abordaremos cada um destes itens aqui no blog no futuro.

Você pode estar irritado em eu levantar a possibilidade que fazemos um trabalho amador e nem nos darmos conta disto. Com experiência e maturidade, naturalmente aprendemos muito e passamos por diversas situações. Você, pode não ser amador e saber o tamanho da responsabilidade do seu código dentro do sistema. Mas e o programador novato ao seu lado? O restante da sua equipe? Sua empresa? E o seu chefe?

Nos próximos posts, vou comentar como cada um destes papéis citados anteriormente contribuem com a construção de um software de forma amadora, onde a qualidade certamente ficará aquém da desejada. Assim que terminar esta espécie de panorama da situação que muitas equipes estão com relação a qualidade do software que desenvolvem, partiremos para a parte técnica.

Agora vai!

Olá pessoal!

Bem-vindo a este blog recém inaugurado. Ele é fruto de uma ideia que tenho faz algum tempo, que é de ajudar os desenvolvedores brasileiros a produzirem software com mais qualidade. O foco será em divulgar boas práticas no código (inicialmente em Java, linguagem que mais domino), maneiras de organizar sua equipe para produzir código com qualidade, ferramentas, etc. Tudo muito direto e fácil de digerir, sem enrolação.

Esta motivação de criar um blog para falar de qualidade vem muito bem amparada. Sou desenvolvedor de software voltado para a área web já faz alguns anos e, a cada ano que passa, eu fico mais pasmo de como somos amadores no que nós fazemos e deixamos margem para cometer sempre os mesmos erros.

No próximo post já detalharei porque estou tão espantado na maneira como conduzimos a construção de um software... aguardem!