Boas Práticas Para Uma Arquitetura Eficiente

Ao lidarmos com o desenvolvimento de softwares de grande porte e inúmeras regras de negócio, muito provavelmente estaremos lidando com camadas complexas e muitos fluxos de execução, este que deve ser bem arquitetado e planejado pelo desenvolvedor.

Para que o mesmo possa desenvolver uma arquitetura eficiente e com um código sólido, o desenvolver pode fazer uso de boas práticas para obter um código mais legível e bem manutenível.

Fail Fast

O conceito de Fail Fast (podemos traduzir como "falhar rápido") pode ser descrito como a prática de identificar e lidar imediatamente com problemas e erros em sua aplicação. Isso promove a estabilidade do software, uma vez que o mesmo não continuará sua execução com trechos e componentes instáveis.

O Fail Fast está em concordância com os princípios de Engenharia de Software pois o mesmo estimula a identificação e correção de bugs o mais cedo possível (tendo em vista que com o decorrer do crescimento do software, suas alterações e correções de bugs passam a ser mais caras) e promove um software mais legível e fácil de dar manutenção.

Importante destacar que o Fail Fast não se trata exatamente de uma prática sólida, mas sim de um conceito o qual buscamos através de atividades as quais descreveremos algumas a seguir.

Early Return

O Early Return se trata de uma técnica de programação o qual o resultado esperado de uma função se encontra no final do seu corpo. Durante a execução da mesma é realizada várias validações para garantir que no caso de um fluxo falho (não desejado ou inesperado) a execução seja cancelada.

Essa técnica promove maior legibilidade do código, além de diminuir a possibilidade de bugs e permite uma manutenção mais fácil.

Veja o exemplo abaixo :

public function fazerAlgo(AlgumaInformacao $informacao, OutraInformacao $outra)
{
    if ($informacao->temAlgumaCoisa()) {

        if ($informacao->temOutraCoisa()) {

            if ($outra->temSuaCoisa()){

                if (pode_fazer_uma_terceira_coisa($informacao, $outra)){
                    return true;
                } else {
                    echo 'não pode fazer terceira coisa';
                }
            } else {
                echo 'não tem sua coisa';
            } 
        } else {
            throw new NaoTemOutraCoisa('talvez em outro momento...');
        }
    } else {
        echo 'não tem alguma coisa';
    }
}

O código acima apresenta inúmeras condicionais e fluxos de execução, as quais dificultam a leitura do desenvolvedor e resulta em uma manutenção difícil.

Interessante notarmos a existência de alguns "anti-padrões":

• Else:

  • Dificulta a manutenção pois o mesmo apresenta um fluxo de execução alternativo para quando a condição apresentar valor oposto ao fluxo normal.

• Anti-padrão "Flecha" (ou "Arrow"):

  • Consiste na presença de inúmeras estruturas condicionais e/ou de repetição encadeadas, resultado no formato de flecha.

Estes problemas apresentados podem ser facilmente evitados caso o desenvolvedor aplicasse a técnica de "Early Return", a qual apenas invertendo os sinais de cada estrutura condicional, seria possível obter um resultado mais limpo e com um fluxo de execução mais claro:

public function fazerAlgo(AlgumaInformacao $informacao, OutraInformacao $outra)
{
    if (!$informacao->temAlgumaCoisa()) {
        echo 'não tem alguma coisa';
        return;
    }

    if (!$informacao->temOutraCoisa()) {
        throw new NaoTemOutraCoisa('talvez em outro momento...');
    }

    if (!$outra->temSuaCoisa()) {
        echo 'não tem sua coisa';
        return;
    }

    if (!pode_fazer_uma_terceira_coisa($informacao, $outra)) {
        echo 'não pode fazer terceira coisa';
        return;
    }

    return true;
}

O "early return" nos proporciona as seguintes melhorias de código :

• Código linear com apenas um nível de indentação, possibilitando uma leitura mais fácil

• O resultado esperado da função é fácil de encontrar.

• Promove um código mais fácil de testar.

KISS (Keep It Simple, Stupid)

O acrônimo significa "Mantenha Isso Simples, Estúpido" e seu conceito reforça a necessidade de mantermos as coisas simples, devido ao hábito de aumentar a complexidade buscando implementar algum design pattern ou conceito que por vezes é muito mais complexo do que de fato necessário.

Este conceito nos lembra de atingir o mesmo objetivo mas por caminhos mais simples, reduzindo complexidades desnecessárias e esforços redundantes.

Um bom exemplo seria um cenário em que um desenvolvedor pretende implementar um modelo de machine learning para resolver determinado problema, quando na realidade este problema poderia ser resolvido verificando algumas breves condições sem grande variabilidade de dados.

Alguns pontos que o desenvolvedor pode se atentar para reduzir a complexidade seria :

• Garantir que o nome de variáveis e de métodos transmitam corretamente seu propósito de acordo com o contexto inserido.

• Escrever comentários dentro de métodos APENAS quando for necessário.

• Garantir que suas classes tenham apenas uma responsabilidade.

• Deletar classes, variáveis, métodos e quaisquer trechos de código que não esteja sendo utilizado.

A maior importância de aplicar o princípio KISS, é garantir que quando trabalhando em uma base de código já existente e compartilhada entre vários desenvolvedor, qualquer modificação seja fácil de ser compreendida e até mesmo alterada se necessário.

YAGNI (You Ain't Gonna Need It)

O conceito traduzido "Você Não Vai Precisar Disso" segue o princípio KISS, reforçando a importância de manter simples tudo que for possível de manter simples.

Este princípio consiste na prática de desenvolver apenas aquilo que for realmente necessário, desencorajando o hábito que muitos desenvolvedores praticam de desenvolver algo que acredita que será necessário no futuro.

Isso porque alguns profissionais dedicam demasiado esforço em aplicar otimizações em cenários prematuros e desnecessários, ou mesmo alguma feature ou abstração a qual não se faz necessário atualmente, sendo que sua implementação no futuro pode também se tratar de uma incerteza.

Além disso, essa implementação muito provavelmente acrescentaria maior complexidade no sistema, o que seria prejudicial para o cenário da aplicação.

DRY (Don't Repeat Yourself)

Com o paradigma funcional, o mercado se encontrou com uma das maiores revoluções e progressos na área de desenvolvimento de software : as funções e procedimentos. Ambos representavam um ganho de velocidade muito grande no desenvolvimento do software, pois fornecia ao desenvolvedor recursos suficientes para que o mesmo replicasse trechos de código conforme sua necessidade, aumentando a eficiência do desenvolvimento e também facilitando a manutenção do mesmo.
A Orientação à Objetos foi outro grande passo dado nessa direção, através de classes, métodos e atributos, era possível que os desenvolvedores reutilizassem e encapsulassem funções de acordo com seu contexto.

No entanto, mesmo que os desenvolvedores tenham em mãos tais recursos, é comum que ocorra a implementação de códigos e linhas repetidas em um sistema, aumentando a complexidade do mesmo e dificultando em sua manutenção.

O princípio DRY afirma que uma lógica particular do sistema deve aparecer apenas uma única vez ao longo do código fonte, sendo reutilizado através dos recursos descritos anteriormente.

Exemplo :

class PHPDeveloper 
{
    public function saudacoes()
    {
        echo 'Olá ! Sou um desenvolvedor!';
        echo 'Eu programo em PHP!';
    }
}


class JavaDeveloper 
{
    public function saudacoes()
    {
        echo 'Olá ! Sou um desenvolvedor!';
        echo 'Eu programo em Java!';
    }
}

Neste caso, podemos fazer uso da Herança de Orientação a Objetos, e remover o trecho echo 'Olá ! Sou um desenvolvedor!' de ambas as classes e abstrair para uma classe pai, removendo código duplicado e promovendo a manutenção e legibilidade do sistema.

abstract class Developer {

    public function saudacoes()
    {
        echo 'Olá ! Sou um desenvolvedor!';
    }
}

class JavaDeveloper extends Developer
{
    public function saudacoes()
    {
        parent::saudacoes();
        echo 'Eu programo em Java!';
    }
}


class PHPDeveloper extends Developer 
{
    public function saudacoes()
    {
        parent::saudacoes();
        echo 'Eu programo em PHP!';
    }
}

Porém, é extremamente importante que o desenvolvedor se atente em não aplicar o princípio DRY enquanto não houver código duplicado no sistema, pois o mesmo pode buscar realizar uma abstração mesmo não havendo necessidade (vide princípio KISS e YAGNI).

Conclusão

Os princípios citados acima, descrevem boas práticas as quais foram estudadas e desenvolvidas por profissionais e pesquisadores ao longo dos anos.

Tais práticas promovem uma arquitetura eficiente e um código fácil de trabalhar.

No entanto, os profissionais que forem aplicas estes princípios, devem aplicar com sabedoria e cuidado, pois a má interpretação de um princípio pode resultar em conflito com outros, como consequência o código é prejudicado e afetado, dificultando sua manutenção.