Muitas vezes, principalmente quando chegamos a uma equipe nova, temos um monte de ideias na cabeça e queremos implementar ou passar para os novos colegas. Hoje, eu me sinto muito desconfortável se tiver que trabalhar sem controle de versão ou testes unitários.

Acontece que nem sempre nós temos o controle do ambiente e não está em nossas mãos a decisão de tecnologia ou seja lá o que for. Portanto, aconselho a ter paciência e não tente impor suas ideias. Ao invés disso, procure compreender os problemas da equipe e aos poucos vá expondo sua bagagem de conhecimento.

Não é fácil para uma equipe que está acostumada a trabalhar com sistemas diretamente no FTP. Aliás, é praticamente impossível fazer uma equipe dessas aceitar um sistema de controle de versão como o git, mercurial ou até mesmo subversion. Quando chegar em uma equipe nova, não procure passar todos os conceitos de uma vez, vá com calma.

Experimente passar coisas que não afetem o dia-a-dia da equipe ou afetem bruscamente os procedimentos. Não tente chegar em uma equipe que trabalha em escala (design, html, programação, aprovação, upload) e tentar fazê-los aprender testes unitários com desenvolvimento pair programing e com controle de versão. Ao invés disto, experimente começar com algo mais simples, como padrões de programação.

Padrões de programação

Tomemos como base a linguagem PHP. Veja o código abaixo e tente descobrir qual é o problema:

class Pessoa {
    var $nome;
    function setNome($nome) {
        $this->nome = $nome;
    }
    function get_nome() {
        return $this->nome;
    }
}

Pode até passar desapercebido por alguns ou até mesmo pode parecer bobagem para outros, mas uma boa parte de bons programadores sentirão enjoo ao ver os padrões usados para nomear os métodos da classe Pessoa.

Um usa o padrão camelCase e o outro usa o padrão de underlines (aquela linha inferior que separa uma palavra da outra). Eu, particularmente, sinto um frio na espinha quando vejo códigos como o seguinte:

function plural($palavra) {
    if (substr($palavra, -1) != 's') {
      $palavra .= 's';
    }
    return $palavra;
}

O que?! Não percebeu o problema?! Pois eu explico: o problema é o espaçamento da identação, onde no bloco de função foram usados dois espaços e no bloco do if foram usados dois espaços.

Tá, pode parecer maluquice de quem não tem o que fazer, mas vai por mim, se você não for rigoroso em todos os detalhes, você terá dores de cabeça devido à falta de padrão.

O legal de seguir um padrão é que a equipe inteira estará escrevendo um mesmo código, então todos saberão como o código deve ser escrito e como ele deve ser lido.

Quando todos seguem um padrão, o próximo programador (que não estava no projeto no início do mesmo) não terá problemas em se focar no código ao invés de tentar descobrir qual padrão foi usado. Ou então tentar decifrar códigos que misturam coisas como formas de AND e OR misturados a & e ||.

if ($nome == 'Michael' || $nome == 'Maicol' OR $nome == 'Michell')

Adotando padrões nas equipes

Voltando ao assunto da equipe. Se a equipe tiver vários problemas que você apontou, experimente começar pelo básico. Aconselho a tentar fazer a equipe escrever um bom código.

Passe padrões de programação para ela, você encontrará muitas informações legais procurando por Code Standards no Google. Converse com a equipe, adote um padrão, e imprima – se julgar necessário, um exemplar das normas adotadas pela equipe. Deixe tudo bem mastigado para que os padrões sejam digeridos aos poucos pelos outros desenvolvedores.

Não exija que eles aprendam todos os padrões de uma vez. Também não fique atrás de cada programador com uma palmatória na mão forçando-os a escrever os padrões corretamente.

Todo aprendizado deve ser sútil e agradável para que seja levado à frente. O aprendizado não deve ocorrer pelo medo/exigência, e sim pelo prazer que ela proporciona. Eu sou uma pessoa muito chata com relação a seguir padrões, chego ao cúmulo de verificar a quantidade de linhas e colunas que um método tem para não sair do padrão e deixar o próximo programador feliz.

Padrões para adoção

A Zend – organização mantedora do PHP – não possui um padrão oficial para a linguagem. O que existem são indicações de algumas entidades que, muitas vezes por terem uma forte participação da comunidade, têm uma boa documentação de padrões que devem ser usados.

O Felipe Ribeiro fez uma ótima apresentação na edição do PHPConference em 2008, onde você pode ver várias práticas que melhoram o seu código e de sua equipe. Agora, se você procura padrões de programação para PHP, posso indicar os seguintes:

• CodeIgniter

• Zend Framework

• Pear

• Drupal

A maioria das IDEs que vemos no mercado hoje vem com um recurso que ajuda na identação do código e pode ajudar bastante no desenvolvimento dos seus arquivos.

Agora se você não quer ficar verificando a quantidade de espaços que o programador usou, linha a linha, talvez você esteja precisando usar o PHPCodeSniffer, uma biblioteca PEAR que roda na linha de comando (pelo menos no Linux, mas deve rodar no DOS do windows também), analisando linha a linha, verificando espaços e até ordem dos parâmetros na documentação.

Essa extensão ainda pode ser configurada para adotar o padrão adotado pela equipe na qual você trabalha. Isso economiza tempo e dinheiro na hora de validar códigos.

Outra ferramenta interessante que existe no Pear é o PHPBeautifier, que se dá ao trabalho de reescrever o seu arquivo no padrão especificado pelos seus padrões definidos.

Nos meus testes, eu achei que é uma ferramenta para auxiliar em arquivos com muitas divergencias no seu padrão, mas não consigo confiar cegamente se o arquivo ficou como deveria ficar. Mas pode ajudar pra caramba na hora do desenvolvimento.

E você? Usa algum padrão de programação? Qual? Usa alguma ferramenta para auxiliar nessa tarefa? Qual?