Simplicidade é tudo para seu software!
Simplificar (e manter) a estrutura de todas as áreas do seu projeto pode salvar muito tempo de trabalho (recurso preciosíssimo).
Quando digo simples, no entanto, não estou falando de algo inacabado ou mal feito. Muitas vezes é até mais difícil fazer as coisas de forma simples (por isso é comum vermos gambiarras que tornam as coisas tão complexas com o passar do tempo). Demanda um pouco mais de “tato”, planejamento e experiência.
Pensar “simples” mas planejadamente é algo que se desenvolve dia após dia, refatoração após refatoração, mas que acaba trazendo benefícios à curto e longo prazo.
Vamos tomar como exemplo um software que possui um módulo de “Labels”, etiquetas que podem ser atribuídas à determinados objetos (vamos supor que tais objetos sejam Posts, Produtos, etc).
Por conta de diversas decisões que deixavam a simplicidade de lado, com o tempo a estrutura dessas “Labels” foi ficando cada vez mais complexa, e sempre que era necessária uma mudança, perdiam-se muitas horas ou até mesmo dias de trabalho.
Veja o exemplo de um código antigo existente nesse software, responsável por obter as labels de um determinado objeto:
E essa era uma das partes mais sutis (o problema nesse caso estava na raiz/estrutura dos dados, o que acabava gerando as famosas “gambiarras”, para resolver os problemas).
Com o tempo as diferentes soluções para os problemas estruturais foram amontoando-se e tornando o módulo em um grande “código spaghetti”.
Em um determinado momento, era quase impossível ler o código sem ter um “nó na cabeça”.
Por isso foi feita uma reformulação total da estrutura deste módulo, desde o banco de dados, até o código, sempre com o conceito de simplicidade e objetividade em mente.
No final, o software contava com o seguinte código para realizar a mesma tarefa:
Apenas observando o código, é possível perceber que a simplificação da estrutura já gerou melhorias na legibilidade.
Para chegar nesse resultado foram necessários diversos passos:
- Revisar a estrutura atual (demorado e complexo, mas necessário)
- Decidir o que continua e o que sai das regras de negócio (algumas regras adicionadas com o tempo eram desnecessárias) — Essa é a fase de conversar e entender realmente o que se espera, e o que pode sair fora
- Reformular a estrutura, desde o banco de dados até o código
- Implementar (testando durante o processo) — É comum, nessa fase, ter que criar código para adaptar os dados à nova estrutura, renomeando e criando novas tabelas no banco, etc. É comum, durante essa fase, retornar ao passo anterior em alguns momentos, já que desenvolver é um processo de descoberta e algumas incongruências podem passar despercebidas.
O mais curioso é que a estrutura fora bem simples no princípio do sistema, e muitas das regras adicionadas depois, que acabaram gerando essa complexidade, foram descartadas.
O famoso princípio KISS (keep it simple, stupid) é um ótimo conceito para ser aplicado em qualquer projeto, seja desenvolvimento de software ou não. De acordo com este princípio, fazer e manter as coisas simples faz com que elas funcionem muito melhor que se forem complicadas.
De acordo com esse princípio e com o que vimos aqui, podemos concluir que é importante questionar tudo o que pode adicionar camadas de complexidade sem trazer reais benefícios.
Talvez, ter mantido tudo simples, analisando realmente a necessidade de certas regras e funcionalidades, tivesse evitado tantas dores de cabeça neste módulo.
E por último:
Mesmo o complexo pode ser abordado de forma simples.
Keep it simple!