Mas, perché ?
Simples ! O que significa refatorar ?

Essa palavra que está na roda de conversa dos developers atualmente nem sempre é utilizada com sua real definição. Pare para pensar na última vez em que você refatorou algo. Responda a si mesmo as perguntas:

• Qual o objetivo do refactoring ?
• Quantas coisas (pontos de função, pacotes, formas (?)) foram alteradas ?
• Após, o que mudou ?
• Por quê necessitou refatorar ?

1. Qual o objetivo do refactoring ?
Fazer valer os princípios trazidos do alto da montanha descritos por developers como Uncle Bob e Barbara Liskov.
Em outras palavras: não repetir a mesma coisa duas vezes; ser coeso; ser claro e objetivo; cada “coisa” precisa ter sua responsabilidade e esta deverá ser única; e etc, etc e etcetera.

2. Quantas coisas (pontos de função, pacotes, formas (?)) foram alteradas ?
Uma e somente uma. Se você resolveu mudar uma funcionabilidade e junto adicionou uma coisa por menor que mínima, você aumentou a probabilidade de dar tudo errado. A dica aqui é: não é possível assoviar e chupar cana ao mesmo tempo.

3. Após, o que mudou ?
Nada. Você não tinha como objetivo mudar um comportamento, apenas melhorar algo que já existia. Se fez um refactoring por causa de um bug, então você não refatorou, mas sim, inseriu um ou mais novos bugs. Leia o item 2 novamente se ficou com dúvidas.

4.  Por quê necessitou refatorar ?
Vários motivos podem levar você a isto, mas a finalidade sempre acaba recaíndo sobre: melhorar o processo, a atividade ou relacionamento entre eles.

Processos, atividades e relacionamentos.

Repare que eu evitei falar de código diretamente. Isso pois eu vejo a refatoração algo possível para qualquer um em qualquer área. Tente aplicar os 4 itens acima em sua área. Se for um gestor, veja a refatoração como evolução e adequação dos processos existentes; No item 2 eu falei sobre formas(?) justamente com este propósito. Refatore a forma como você faz algo.

Nós da área Web da Vex, mantemos dentro do repositório dos projetos os arquivos SQL que geramos ao decorrer de cada alteração/adição feita aos projetos. Em meados do primeiro semestre de 2009, os arquivos .sql eram salvos da seguinte forma:

/data/projetoXPTO/moduloABC/umNomeDescritivo.sql

O umNomeDescritivo.sql parece algo legal. Vamos fazer um teste de mesa com isto:

/data/erp/relatoriosFinanceiros/engineDeGraficos.sql

Woow! Funciona perfeito. Tudo referente à engine de gráficos ficará neste arquivo .sql e done deal.

Com o tempo, aquilo ficou impossível de controlar pois a cada nova atualização, os arquivos ficavam maiores e o pior: quando o deploy da aplicação era realizado, como saber exatamente o que atualizar no banco de dados de produção ?

A partir deste problema, uma refatoração na forma de salvar arquivos SQL fora realizada. O novo modelo sugeria o padrão:

/data/projetoXPTO/moduloABC/YYYYMMDD_umNomeDescritivo.sql

Legal, problema resolvido ! Vamos ao teste de mesa:

/data/erp/relatoriosFinanceiros/20100301_engineDeGraficos.sql

A primeira vista, tudo perfeito. Contudo, nossos softwares são feitos com base em releases e acredite, temos muito código a cada novo release, gerando assim muito SQL para atualização. Processos manuais ou automatizados tornaram-se inviáveis pois a pergunta que ecoava na sala era:

Quais foram as datas dos Release 1.2.2 e Release 1.2.3 do software de autenticação mesmo ?

Pois é. E agora, José ? A partir disso eu pensei um bocado e resolvi dar palpite no processo. Porque não armazenar por release ?

/data/release-1.2.3/projetoXPTO/modulo_umNomeDescritivo.sql

Pronto. Agora consigo fazer uma análise do que mudou por versão. Essa refatoração no processo de armazenamento dos arquivos SQL mudou a forma como os arquivos são salvos e só.

Refatore sempre que puder. Mude e melhore aquilo que funciona, mas que não está na sua melhor forma. Tenha em mente que deixar algo que pode ser melhorado para trás, poderá custar-lhe caro amanhã. Porém, eu entendo que só há refatoração quando o objeto alvo está finalizado e funcionando. Antes disso o nome ao meu ver é implementação.

Keep refactoring

Artigo originalmente postado por mim no até então blog Ready to Sail, hoje, o planet da Vex.

Vejamos um exemplo nada científico que fiz:

Criei os seguintes exemplos:

<?php
class Estatico {

    public static function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
           echo Estatico::outraCoisa();
           $i++;
        }
    }

    public static function outraCoisa() {
        return "Conteúdo";
    }
}

Estatico::fazAlgumaCoisa();

<?php
class Instancia {

    public function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
            echo $this->outraCoisa();
            $i++;
        }
    }

    public function outraCoisa() {
        return "Conteúdo";
    }
}
$objInstancia = new Instancia();
$objInstancia->fazAlgumaCoisa();

Os resultados após rodar quatro vezes cada foram:

Ou seja: 91.09 ms para o estático contra 90.07 para a versão non-static. Obviamente foi apenas um teste sem qualquer relevância, pois rodei em minha máquina pessoal com várias outras aplicações rodando em background. É perceptível porém, que a diferença não é absurda que compense o uso de estático por este motivo.

Deixando a questão de “performance” de lado, partimos para questões arquitetônicas:

• Identidade
• SoC – Separation of Concerns (Principio de Separação das Responsabilidades)
• Encapsulamento
• Estado
• DRY – Don’t Repeat Yourself
• Associações – sejam elas composições ou agregações

Ao perder Identidade e Estado as possibilidades daquele método – ou da classe inteira, caso use estático em tudo – tem o leque de utilidade reduzido para:

• Service
• Facade
• Factory
• Helpers – no âmbito de serem apenas funções que realizam determinada tarefa na aplicação sem qualquer valor ao Domínio

Com isso, perdemos também o Princípio de Separação das Responsabilidades, ou seja, a classe perde o controle sobre a integridade dos dados que ela deveria controlar e proteger contra acesso ou alteração indevidos.

Listei o DRY também por um motivo simples: com métodos estáticos, perdemos a grande chance de usar as variáveis de instância da classe à favor da mesma. Exemplo:

class UsuarioEstatico {

    public static function login($usuario, $senha) {
        // valida o usuário e zaz
        $autenticador = new Autenticador();
        $autenticador->autentica($usuario, $senha);
    }

    public static function logout($usuario) {
        // verifica se a sessao está aberta
        $autenticador = new Autenticador();
        $autenticador->fechaSessaoPara($usuario);
    }
}

class Usuario implements Autenticavel {
    private $autenticador;

    public function __construct($usuario, $senha) {
        // manipula os dados de entrada
        $this->autenticador = new Autenticador($this);
    }

    public function login() {
        return $this->autenticador->autentica();
    }

    public function logout() {
        return $this->autenticador->fechaSessao();
    }
}

Repare no modelo estático: foi necessário instanciar o antenticador por duas vezes em pontos diferentes. Opa, repetiu ! Mesmo que o autenticador fosse estático, teriamos duplicação, pois teriamos que certificar que o usuário existe e tudo mais. Isso porque não comentei como ficaria o lado cliente dessa implementação estática. O cliente – seja Controller, WebService ou qualquer classe em outra camada no domínio – teria que conhecer muita coisa sobre implementação dessa classe para poder manipulá-la.

Como bônus, repare que perdemos neste caso também o Polimorfismo, uma vez que eu poderia ter esse Autenticador() como base de autenticação para qualquer tipo (Usuário, Funcionário, Gerência, Administradores…)

O uso de métodos ou funções – sim, há diferença – estáticas pode ser bem-vindo nos itens já enumerados. Alguns developers porém, ainda que nestes casos são contra o uso por achar a ideia estática demasiadamente anti-oo.