No ciclo de lives do DI, professor apresentou resultados de sua pesquisa sobre degradação e refatoração de sistemas de software
Para quem não é da área de engenharia e desenvolvimento de software talvez seja curioso pensar que sistemas de software possam ter “mau cheiro”. Mas eles têm. “Assim como na nossa saúde observamos sintomas que podem indicar uma possível doença, também nos projetos de software temos pistas, sintomas no código-fonte que podem expressar micro problemas de desenho de software, que são chamados os ‘maus cheiros’”, explicou o professor Alessandro Garcia no seminário “Degradação e Refatoração de Projetos de Software”, na sexta-feira (27), em mais uma edição do ciclo de lives da pós-graduação do Departamento de Informática (DI) da PUC-Rio.
O termo ‘mau cheiro’ é utilizado como uma metáfora para indicar que algo vai mal no desenho do software. Os “maus cheiros” são “sintomas” de problemas que vão se acumulando ao longo dos anos de vida de um sistema de software, causando o processo de degradação, que se alcançar um alto nível pode levar o programa a se tornar um software legado ou até mesmo ser descontinuado. “A degradação de software é relevante por vários motivos e deve ser monitorada de forma eficiente”, afirmou Garcia.
O processo de degradação muitas vezes é desencadeado porque o desenho de software vai sofrendo mudanças baseadas em decisões ruins ao longo do tempo. Uma série de novas decisões podem reverter boas decisões que foram tomadas no passado. Além disso, outras más decisões podem ser tomadas na inclusão de novas funcionalidades ao sistema. Estas decisões equivocadas podem levar a vários tipos de problemas nos mais variados níveis de abstração do desenho de um sistema, seja em um escopo maior (por exemplo, a arquitetura do sistema) ou menor (por exemplo, o desenho interno de um módulo do sistema). Então cabe ao desenvolvedor interpretar os sintomas, ou “mau-cheiros”, a fim de inferir qual é a “doença”, qual é o grande problema de design de software que está acontecendo, para realizar as atividades de reparo de forma eficiente.
Análise holística dos sintomas
Segundo Garcia, grandes problemas usualmente só podem ser inferidos a partir de uma análise combinada dos sintomas que foram sendo introduzidos no projeto, seja na mesma versão, ou em diferentes versões. Assim como um médico pergunta como você estava na semana passada, quando surgiu isso ou aquilo, para fazer um diagnóstico, é preciso saber o histórico do sistema de software. “Essa análise holística e histórica dos sintomas é que vai permitir que desenvolvedor conclua que ali realmente tem problema de design relevante e qual é esse problema. Não é necessariamente focado só em um sintoma. Os grandes problemas de design estão associados a múltiplos sintomas”, disse.
Leia também:
“Todo cidadão deveria saber programar’, diz Bruno Feijó em live
Alessandro Garcia e alunos do DI são premiados no SBES 2020
Mograbi sobre IA reproduzir emoções: ‘Acho difícil, mas não impossível’
Para combater e eliminar a degradação, ou ao menos suavizar ou tolerar esses “maus cheiros”, é preciso fazer a refatoração do código-fonte. Essa atividade promove uma série de transformações estruturais que visam otimizar algum atributo interno ou externo de qualidade do sistema. “O objetivo principal é melhorar o desenho do sistema, resgatar e controlar novamente a manutenibilidade, ou outros atributos não-funcionais que estavam associados com problema de design no ato da refatoração”, afirmou Garcia
Contudo, a própria refatoração também pode gerar “maus cheiros”. Nos estudos e pesquisas realizadas pelo professor e sua equipe, foi observado que 80% das refatorações tem como alvo módulos do sistema que têm um ou mais “maus cheiros”. E a análise destes módulos revelou que 73% daqueles que são tocados pelas refatorações contém vários sintomas. Portanto, o time de pesquisa liderado pelo professor Garcia também trabalha em busca de técnicas e ferramentas que possam sintetizar essa série de sintomas e ajudem o desenvolvedor a tomar melhores decisões sobre os “maus cheiros” que devem ser removidos e aqueles que não devem.
“Apesar de ser uma transformação que reduz a degradação, temos notado que muito frequentemente os desenvolvedores não tomam as decisões adequadas em relação às refatorações. As ferramentas deveriam apoiar uma análise que permitisse o desenvolvedor ver rapidamente a relação entre os sintomas e, com base nessa informação mais rica, planejar melhor as refatorações. Porém, as ferramentas disponíveis na indústria e na academia estão longe ainda de fornecer esse apoio direto para facilitar as decisões no combate à degradação”, alertou.