Monthly Archive for February, 2009

Você não é uma vaca leiteira

…então, por favor, não trabalhe como se fosse.

Vale a pena prestar um pouco de atenção nos aspectos ergonômicos do seu ambiente de trabalho. Coisas como monitores bonitos, uma quantidade absurda de portas USB e uma biblioteca de música praticamente inesgotável são importantes para qualquer programador. Mas algumas coisas mais simples são igualmente importantes, como a altura da sua cadeira, a posição do seu teclado e, muito surpreendentemente, o bom e velho espaço livre.

Espaço livre não parece estar muito na moda ultimamente. É raro encontrar alguém que dá alguma importância para isso. Afinal de contas, o trabalho de um programador (e de qualquer trabalhador do conhecimento, para este efeito) acontece dentro da cabeça. Não é necessário muito espaço para abrigar a cabeça de uma pessoa, mesmo se levarmos em consideração que ela é inseparável dessa massa inútil e disforme que chamamos de corpo. Talvez seja por isso que tantas empresas dão o mesmo espaço de trabalho para os programadores que uma fazenda intensiva daria para uma vaca leiteira. Uns só precisam das tetas, outros só da cabeça. Quanto mais programadores couberem no mesmo espaço, mais software será produzido por metro quadrado. Simples otimização de chão de fábrica, certo?

dairy_cowders

Sim, é fato que sua cabeça (ainda) não pode viver separada do seu corpo. Portanto, mesmo que você não ligue para seu corpo em si, é melhor cuidar dele se quiser continuar usando sua inteligência por muito tempo. Esse cuidado passa por aspectos bastante óbvios (e penosos) como praticar exercícios regularmente e manter uma dieta equilibrada. Pode não ser muito fácil cuidar disso, mas os aspectos ergonômicos do ambiente de trabalho são muito mais controláveis. Mesmo assim costumam ser negligenciados.

Este é meu escritório de casa atualmente (bom, pelo menos a parte sobre a qual quero falar hoje):

my_office

A mesa é em geral o espaço onde você vai passar a maior parte do tempo. Não importa se você tem acesso a uma mesa de sinuca e a três video-games diferentes para jogar Rock Band com seus colegas durante o horário de trabalho. Se sua mesa for desconfortável, você não vai produzir muito. Pensando bem, se lhe derem uma mesa inadequada, é bem mais provável que você passe mais tempo jogando Rock Band do que programando.

A primeira coisa que você vai querer garantir para sua estação de trabalho é uma cadeira confortável. Ela precisa ter ao menos encosto reclinável, ajuste de altura e apoio para os braços. E estofamento macio, claro. Você não vai querer ficar sentado o dia todo numa pilha gigantesca de algodão. Tampouco em um banco de praça. Ache um meio termo que pareça bom para você e use-o. Não é preciso gastar dois mil reais numa cadeira para ter todos estes recursos, mas também não é um valor assim tão absurdo se considerarmos a durabilidade do equipamento e o custo do programador para a empresa.

O próximo item da lista é uma mesa espaçosa. Segundo o Peopleware, um estudo encomendado pela IBM há muitas luas atrás descobriu que a superfície mínima que uma pessoa precisa para ser produtiva é de aproximadamente 2,5m². Minha mesa deve ter aproximadamente 1,75. Ainda estou abaixo da meta, mas com certeza é mais do que os dois caras da foto têm e pelo menos é o suficiente para caber com sobra meus dois monitores.

O que nos leva ao próximo item indispensável a qualquer pessoa que desenvolva software: muito espaço de tela. Com dois monitores de 1280×1024 você obtém uma área útil de 2560×1024 pixels, o que é suficiente para abrigar ao menos um editor com seu código e o programa rodando ao mesmo tempo. Se apertar um pouco, cabe até uma janela para monitorar os testes automáticos. Mas você pode achar útil ter algum material de referência aberto para consultar rapidamente e talvez precise de um terceiro monitor para isso. Como você está lendo isso aqui, provavelmente já tem um dos monitores. Um extra deve estar abaixo dos 600 paus hoje em dia e a maioria das placas de vídeo modernas já aceita duas saídas. É produtividade de graça se você jogar na conta o tempo (e a paciência) que se perde chaveando janelas numa tela só.

Você também vai querer ter seus vários monitores posicionados corretamente. Uma distância entre 40 e 75cm entre seus olhos e a tela é o suficiente. É preciso tomar cuidado para posicioná-los na altura correta também (vale usar livros velhos quando o monitor não tem regulagem de altura). Você não vai querer ficar com a cabeça inclinada nem para cima nem para baixo o dia todo. As dores no pescoço podem ser bastante irritantes depois de um tempo.

Além da altura dos monitores, você também precisa regular a altura da cadeira e da mesa para manter suas pernas e braços em ângulos mais ou menos retos a maior parte do tempo. Isso vai aliviar bastante a coluna e pode garantir boas noites de sono. Simplesmente procure um pouco na web sobre ergonomia no trabalho que você vai achar várias dicas, há bastante material por aí.

Quando não estiver trabalhando, não esqueça de comer seus vegetais e fazer seus exercícios e lembre-se de que se exercitar durante o trabalho também é importante. Você não precisa levantar para correr meia-maratona no horário do almoço. Alguns alongamentos uma ou duas vezes ao dia já são suficientes. Você também pode querer manter por perto algumas daquelas bolinhas terapêuticas, daquelas vendidas em lojas de animais. Elas são ótimas para exercitar a musculatura do punho que tanto castigamos ao digitar o dia inteiro e ainda servem para massagear a tensão acumulada.

Um último toque que você talvez não encontre em todo site sobre ergonomia fica bem no canto direito na minha mesa. Uma foto de pessoas que você gosta (de uma viagem com a esposa, como esta minha) é importante para lhe lembrar que por mais que seu código pareça perfeito e sem falhas (e, acredite, ele nunca é) e que você passe o dia conversando em linguagens estranhas com essa máquina maluca de duas cabeças, no fim das contas você é apenas humano e precisa de outras pessoas assim como qualquer outro ser humano.

Ninguém liga para sua relação teste-para-código

Tenho visto muita gente recentemente se gabando da relação teste-para-código de seus projetos. As pessoas medem a quantidade de linhas de código do sistema em si e a quantidade de linhas de código dos testes automáticos e publicam a relação de uma para a outra, como se isso quisesse dizer algo sobre a qualidade do sistema. Permita-me ser bem claro:

Ninguém dá a mínima para a sua relação teste-para-código.

Nem para sua taxa de cobertura de testes, se é que isso interessa.

A menos que a relação seja zero-para-um, não há absolutamente nada de informativo neste número. A partir do momento em que você está escrevendo algum teste, fazer este número crescer não garante melhoria nenhuma na qualidade do sistema. Talvez você esteja escrevendo testes inúteis para verificar se sua linguagem de programação consegue atribuir um valor a uma variável e recuperá-lo de volta. Talvez você esteja repetindo os mesmos testes o tempo todo. Testar é bom, mas alguns testes são melhores do que outros e este número não é calculado sobre a qualidade dos testes, só a quantidade deles. Não há nenhuma conclusão útil que eu possa tirar do seu número sem dar uma olhada no seu código.

Cobertura de testes é outra métrica bem vazia. Claro que você deve tentar se aproximar tanto quanto possível de 100%, mas a verdade é que chegar a níveis de cobertura acima de 90% não é tão difícil assim. Considere, por exemplo, este trecho de código adaptado do Code Complete do Steve McConnell:

    totalWithholdings = 0;

    for ( id = 0; id < numEmployees; id++) {
        if (m_employee[id].governmentRetirementWithheld < MAX_GOVT_RETIREMENT) {
            governmentRetirement = ComputeGovernmentRetirement(m_employee[id]);
        }

        companyRetirement = 0;

        if (m_employee[id].WantsRetirement &&
            EligibleForRetirement(m_employee[id])) {
            companyRetirement = GetRetirement(m_employee[id]);
        }

        grossPay = ComputeGrossPay(m_employee[id]);

        personalRetirement = 0;
        if (EligibibleForPersonalRetirement(m_employee[id])) {
            personalRetirement = PersonalRetirementContribution(m_employee[id],
                companyRetirement, grossPay);
        }

        withholding = ComputeWithholding(m_employee[id]);
        netPay = grossPay - withholding - companyRetirement -
            governmentRetirement - personalRetirement;

        PayEmployee(m_employee[id], netPay);

        totalWithholdings = totalWithholdings + withholding;
        totalGovernmentRetirement = totalGovernmentRetirement +
            governmentRetirement;
        totalRetirement = totalRetirement + companyRetirement;
    }

    SavePayRecords(totalWithholdings, totalGovernmentRetirement,
        totalRetirement);

É possível obter 100% de cobertura para este trecho completo com apenas um teste: você só precisa garantir que há ao menos um funcionário (para que o loop seja executado) e que as três cláusulas condicionais avaliem para verdadeiro. Obviamente um único teste não é o suficiente para testar todas as nuances deste código e, de fato, McConnel mostra no livro que são necessários pelo menos dezessete testes diferentes. Mesmo assim se tivéssemos escrito aquele único caso de teste, enxergaríamos cobertura total.

Parece que virou moda ultimamente supervalorizar os testes e divulgar estas métricas vazias. No fim das contas elas funcionam como qualquer métrica para software, só dão uma visão bem abstrata do sistema e podem muitas vezes serem enganosas. Não há substituto para uma boa leitura do código.

Tendo dito isso tudo, eu definitivamente não recomendo tentar desenvolver software sem escrever testes automáticos. Já é difícil desenvolver software usando testes, mas é ainda pior sem eles. Só porque você sabe que não é possível provar ausência de defeitos através de testes, não quer dizer que não deva usá-los. Então, por favor, continue escrevendo-os (ou passe a escrever se você não escreve ainda). Só não aja como se eles fossem a última salvação da humanidade. Eles são só a primeira.