Durante a manutenção de uma parte do sistema, vi um código mais ou menos assim (alteramos os nomes para não comprometer os culpados):

(...)
     for(int i; i < widgets.length; i++)
        lstWidgets.get(i).setStatus(widgets[i] == 1);
(...)

Os nomes das variáveis e outras coisas que vi estavam bem pouco inteligíveis. Falei um pouco sobre o tipo de trabalho que ando fazendo aqui.

Pensando em clareza, esse pedacinho singelo de código chega a ser pavoroso. Como não entendi a intenção do método, fui conversar com o pessoal do C. Me explicaram que eram enviados 4 bytes onde cada bit representava o estado de um “widget”: “1″ para ativado e “0″ para desativado. Eles argumentaram que poderiam enviar até 32 “widgets” mantendo essa estrutura. Uma solução típica de quem vive no e do passado.

Com as informações que colhi, fiz uma pequena alteração para que outras pessoas entendam o significado de “0″ e “1″ no contexto dos “widgets”:

     private boolean isActivated(int widgetStatusIndex){
         return widgets[widgetStatusIndex] == 1; // 1 para ativado e 0 para desativado
     }

Também melhorei um pouco e adicionei um comentário explicativo ao parser do “array de bits”. Poderia ter utilizado um tipo enumerado para dar mais significado aos números cabalísticos “0″ e “1″, mas achei que seria preciosismo. Como estamos finalizando uma fase do projeto, é o que dá pra fazer. Refactorings e, se possível, redefinição das interfaces, ficam para a próxima fase.

Acho que um código limpo mostra comprometimento com a equipe e preocupação com a qualidade. Às vezes, basta alterar o nome de uma variável e já temos um bom ganho em clareza. Há ocasiões em que a aplicação de alguns patterns ajudariam bastante. Fico bastante chateado quando concluo que o que faltou foi um entendimento de orientação a objetos, fundamentos de programação ou conhecimento da API. Pouco conhecimento de negócio, dependendo do que for e da postura para procurar saber, é aceitável, pois essa aplicação é bastante complexa. Por isso, vou usar um exemplo fictício de outra área de negócio, mas que contém elementos que garimpei do nosso código:

private int calculateDiscounting(int c){
     // Se o cliente for uma pequena fazenda, não tem desconto
     int dis = 0;
     // Se o cliente for uma grande fazenda, tem um desconto especial
     if(c == 1){
         dis = 1;
     }
     return dis;
}

Esse método, mesmo sendo pequeno, apresenta vários problemas. Vale lembrar que para fazer um refactoring não é só o tamanho de um método que deve ser levado em consideração. A picada da aranha armadeira, um bicho minúsulo, pode te matar. O vírus da AIDS, invisível a olho nú, destrói o sistema imunológico e abre caminho para aniquilação do organismo. É assim que encaro um código ruim: um pequeno inimigo muito perigoso que precisamos combater.

Não vou fazer todas as alterações que gostaria de fazer nesse código. Vamos apenas aumentar a clareza. Se um dia surgisse um requisito que necessitasse de intervenção em código, partiríamos de uma implementação “refactoring friendly“.

Pelo nome, calculateDiscounting(…) afirma que faz um cálculo de desconto, mas o que vemos é uma decisão quanto à categoria de desconto. Os nomes do parâmetro e das variáveis também estão ruins. O que são “c” e “dis”? Vamos supor que pelo menos os tipos estão corretos e seus valores não podem ser alterados, pois são conhecidos fora do método. A propósito, o que são esses “números cabalísticos” testados? Outra coisa que chama a atenção são os comentários in-line. Esse é o chamado “mau cheiro de código” e geralmente marca pontos candidatos a refactoring.

public enum DiscountingCategory(){
     WITHOUT_DISCOUNTING,
     ESPECIAL_DISCOUNTING;
}

public enum CustomerType(){
    SMALL_FARM,
    BIG_FARM;
}

private DiscountingCategory findDiscountingCategory(CustomerType customerType){
     DiscountingCategory discountingCategory = WITHOUT_DISCOUNTING;
     if (customerType == BIG_FARM) {
         discountingCategory = ESPECIAL_DISCOUNTING;
     }
     return discountingCategory;
}

Sinal verde: os testes passaram e agora as coisas fazem mais sentido. Troquei as constantes por tipos enumerados e alterei os nomes do parâmetro e das variáveis. Os “números cabalísticos” podem ser recuperados de fora pelo ordinal() do enumerado, ou seja, não modifiquei a dependência para os valores 0 e 1. Isso fica para o próximo refactoring. Acho que vou parar por aqui.

Conclusão

Em A Melhor Solução é a Simples, citei uma passagem do livro Modelagem Ágil, de Scott W. Ambler. Nesse trecho, ele aponta os problemas decorrentes de se modelar demais para tentar resolver todos os problemas imagináveis. Portanto, não perca tempo inventando requisitos: pare quando a luz verde acender e seu código estiver claro o suficiente.

SSH

Alguns módulos do nosso sistema rodam em servidores remotos. Para que algumas ações possam ser realizadas por um usuário (no caso dos testes automatizados o usuário é o próprio Robot), outras ações – esplícitas, dependentes de terceiros ou dependentes de temporização – devem ocorrer nos servidores. Para simular as chamadas “ações de terceiros”, precisamos executar scripts nos servidores via SSH.

O SSH (Secure Shell) é um protocolo de rede que permite a troca de dados entre dois dispositivos de rede através de um canal seguro. Servidores SSH necessitam de usuário e senha. Como nossos servidores utilizam um usuário fixo e os scripts que rodam lá dependem de permissões atribuídas a esse usuário, não seria a melhor escolha criar um usuário para cada desenvolvedor em cada servidor. Para emular um login automático, decidimos utilizar chave pública e privada. De acordo com a wikipedia:

A criptografia de chave pública ou criptografia assimétrica é um método de criptografia que utiliza um par de chaves: uma chave pública e uma chave privada. A chave pública é distribuída livremente, enquanto a chave privada deve ser conhecida apenas pelo seu dono.

Basicamente, quem detém a chave pública – criada no mesmo momento que a chave privada – pode acessar o dispositivo de rede, que é o detentor da chave privada.

Abaixo, segue o processo para criação do par de chaves pública e privada. Não é necessário repetir esse processo para cada host remoto. Basta fazer apenas uma vez e copiar a chave privada para o diretório .ssh de cada host remoto. Detalhe: segurança não é nosso objetivo .

Passos Para Criação das Chaves Pública e Privada

1. Autenticar no ssh server

$ ssh -l [USER] [HOST_NAME]

2. Criar o par de chaves pública/privada

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/atc/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/atc/.ssh/id_rsa
Your public key has been saved in /home/atc/.ssh/id_rsa.pub
$ cd ~/.ssh
$ cat id_rsa.pub >> authorized_keys
$ chmod 600 authorized_keys

Obs.: Não utilize passphrase.

3. Faça log out e crie, caso não exista, o diretório .ssh

$ cd ~
$ mkdir .ssh
$ chmod 700 .ssh

4. Copie o arquivo id_rsa gerado no servidor para o diretório local .ssh

$ cd ~/.ssh
$ rcp atc@[HOST_NAME]:/home/atc/.ssh/id_rsa .

5. Faça o login via ssh

$ ssh -l [USER] [HOST_NAME]

Agora não é mais necessário fornecer o password.

Resolvendo Problemas

Caso você enfrente algum problema, faça a autenticação em modo debugg para ter o mínimo de informações:

$ ssh -v -l [USER] [HOST_NAME]

Caso esteja tudo certo, algo assim será exibido no terminal:

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/res/.ssh/res-rsa
debug1: Server accepts key: pkalg ssh-rsa blen 151
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
Enter passphrase for key '/Users/res/.ssh/res-rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

Enfrentei dois problemas na primeira vez em que tentei gerar as chaves: falta da permissão 700 no diretório .ssh do servidor e falta da permissão 600 no conteúdo do diretório .ssh. No processo para criação das chaves já coloquei os passos para alteração de permissão.

Referências

http://www.snailbook.com/faq/publickey-userauth.auto.html
http://magicmonster.com/kb/net/ssh/auto_login.html
http://www.linuxquestions.org/questions/linux-security-4/ssh-public-private-key-authentication-problems-454445/