Como resolver Code Smells, Bad Smells e Clean Code

[rotulo-mentoring/][lead-mentoring]Este artigo discute boas e más práticas de programação em Delphi, tratando do uso de código limpo (clean code) e de problemas que dificultam a manutenção de sistemas Delphi (bad smells, ou code smells).

Conforme os sistemas Delphi são evoluídos, modificados e adaptados, seu código e outros artefatos envolvidos se tornam mais complexos, se afastam de seu objetivo original e perdem qualidade. Metodologias e ferramentas não resolvem este problema, pois sua utilização normalmente auxilia na aceleração do desenvolvimento, no caso de ferramentas RAD.

Em muitos projetos, boa parte do custo é dedicada à sua manutenção. Dessa forma, é necessário facilitar a manutenibilidade e legibilidade do código, melhorando sua qualidade interna. Usando boas práticas, veremos como alguns fundamentos de código limpo e refactoring podem tornar um software mais fácil de ser mantido e evoluído.

Veremos como resolver problemas comuns encontrados em código fonte (bad smells), usando uma abordagem de desenvolvimento corretiva e evolutiva[/lead-mentoring]

De acordo com Kent Beck, bad smells são estruturas no código que sugerem a possibilidade de refatoração, como nos exemplos a seguir:

• Rigidez – uma alteração em um ponto do código requer alterações em cascata (dependências entre units, por exemplo);
• Fragilidade – A modificação de um ponto do código quebra outras funcionalidades (form vs data module, por exemplo);
• Complexidade – Arquitetura muito complexa, pois foi preparada para manipular qualquer tipo de possibilidade;
• Duplicação – Código redundante, duplicado;
• Legibilidade – Código difícil de compreender.

Já o Código Limpo é uma prática que visa a escrita de código legível, funcional, pequeno, simples, fácil de entender e manter. Deve ser facilmente acessível a outros, com uma clara intenção, sem ambiguidades, boas abstrações, bons nomes para units, métodos, classes, forms, data modules, etc.

Se um código está difícil de ser entendido, ele deve ser refatorado. Normalmente programadores comentam código difícil de ser compreendido.

Refatorar é reestruturar um sistema de software aplicando uma série de transformações sem modificar seu comportamento observável, afim de torná-lo mais fácil de entender e modificar.

Cada pequeno passo melhora o projeto do código, mantendo seu comportamento externo observável. Existem várias motivações para o uso de refatorações, para aplicar técnicas de clean code. Primeiro, elas tornam mais fácil a adição de novos trechos de código.

Quando se inclui uma nova funcionalidade em um sistema de software, existem basicamente duas opções: programar rapidamente sem se preocupar com o quanto ela se encaixa bem no projeto existente, ou pode-se modificar o projeto existente a fim de melhor acomodar essa funcionalidade.

No primeiro caso, ocorre um débito de projeto, o qual pode ser pago mais tarde com refatoração. Segundo, as refatorações melhoraram um projeto de código existente, no momento que tornam o código mais simples, claro e mais fácil de trabalhar, manter e evoluir.

O uso de refatoração como uma abordagem simples estimulou vários esforços para desenvolver abordagens semiautomáticas para detectar falhas de projeto. A aplicação correta de refatorações apropriadas em um determinado contexto aumenta a qualidade do projeto, sem alterar o seu comportamento.

No entanto, a identificação de inconsistências no código fonte não é uma tarefa simples, tais como métodos, fragmentos de métodos e atributos que devem ser movidos para outras classes.

A motivação para melhorar o projeto de um sistema de software é encontrar problemas no código fonte e usar refatoração como uma possível solução. As limitações (bad smells) descrevem problemas e uma lista de refatorações relacionadas que podem ajudar a melhorar o código.

A refatoração se concentra principalmente no tratamento dessas limitações, mas a implementação de melhorias depende das habilidades do desenvolvedor, que realiza manutenções de software.

Encontrar limitações pode envolver inspecionar todo o código fonte, o que pode se tornar impraticável para sistemas de médio e grande porte. Neste cenário, o apoio semiautomático para detectar falhas é essencial. Felizmente, o RAD Studio oferece várias ferramentas para esse suporte.

Então por que as aplicações Delphi são as que apresentam os maiores débitos de projeto atualmente? Por que é difícil migrar para uma nova plataforma, um novo engine de acesso a dados, reaproveitar código, dar manutenção, trocar de versão do Delphi, enfim, evoluir sistemas Delphi?

Vamos fazer uma análise do desenvolvimento Delphi, rebuscando a história das linguagens RAD. Antes do surgimento do Delphi 1, que foi um marco para o desenvolvimento visual na época, tínhamos apenas o VB como forte concorrente.

Foi exatamente nesta época que surgiu o conceito de “desenvolvimento visual”, ou as “linguagens visuais”, incluindo aí o então IDE do Visual Studio a seguir. O termo “visual” se originou do fato de que as linguagens de programação não tinham um ambiente gráfico de design, basicamente você programava num editor de textos “às escuras”, compilava, rodava e torcia para que os elementos gráficos ficassem organizados como previsto no código. Esse “apelo” trazido pelas linguagens visuais, como Delphi e VB, tornaram o desenvolvimento extremamente rápido.

Aquela barra de menu que se levava duas semanas para construir estava ali pronta na caixa de ferramentas, basta fazer o “"