Conheça técnicas para refatoração de código - Revista .net Magazine 98

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Neste artigo será mostrado como funciona a refatoração de um código. Mais precisamente, quando e como refletir sobre a qualidade de um código, visando alterá-lo para que se torne melhor, mais expressivo e fácil de mantê-lo, sem que isso afete o programa de forma negativa.

De que se trata o artigo

Neste artigo será mostrado como funciona a refatoração de um código. Mais precisamente, quando e como refletir sobre a qualidade de um código, visando alterá-lo para que se torne melhor, mais expressivo e fácil de mantê-lo, sem que isso afete o programa de forma negativa.

Em que situação o tema é útil

Quando for necessário realizar diversas alterações em um código legado ou até mesmo aplicar uma melhoria em um código existente. As técnicas de refatoração auxiliam o desenvolvedor a mudar esse código sem medo que algo dê errado.

Conheça técnicas para refatoração de códigos

Qualquer desenvolvedor pode beneficiar-se por conhecer bons princípios e práticas de boa programação. O que a refatoração faz é trazer estes temas à mesa, visando a melhoria de um código problemático. Não obstante, o que acontece com o estudo para refatoração é que os desenvolvedores que se dedicam acabam escrevendo códigos melhores no futuro. Sendo assim, o estudo da refatoração é útil tanto para quem vai alterar código existente, quanto para aqueles que irão escrever novos.

Este artigo apresentará alguns aspectos, sinais clássicos e técnicas para refatoração de código, visando facilidade de manutenção através da expressividade do código.

Não importa qual tipo de software você desenvolve, pode ser um CRUD simples, um complexo sistema de controle e projeção de rendimentos de aplicações financeiras ou um jogo digital. Seja qual for o tipo de código que estejamos falando, ele está sujeito a uma constante conhecida: um dia o código que você está escrevendo será alterado, não importa por qual motivo.

Os motivos mais comuns que tornam esta constante um axioma, são alterações de requisitos ou correções de erros. Se os requisitos mudam, seu código muda. Da mesma forma que se há erros, você precisa corrigi-los alterando partes dos códigos. Por este motivo, gastamos tanto tempo e energia estudando e descobrindo formas de escrever códigos que sejam fáceis de alterar e estender. Nosso código deve expressar-se bem para que seja fácil de entendê-lo e para que seja possível alterá-lo de forma consciente.

Perceba que lendo os parágrafos anteriores podemos ter a falsa sensação que o ideal seria que o código nunca fosse alterado. Para colocar este pensamento à prova, imagine as seguintes possibilidades:

· Um software foi escrito de forma perfeita tanto em seu conteúdo quanto em sua forma logo na primeira tentativa.

· Um software recebeu meses de manutenção, está funcionando corretamente e tem seu ciclo estabilizado com pequenas correções e ajustes. No entanto, há no horizonte uma possibilidade real de alterações de requisitos que irão colocar esta estabilidade em risco.

A primeira possibilidade é linda, mas profundamente inocente. Isto não existe! A segunda, por sua vez, é bem comum.

O que vamos tratar no restante deste artigo é como tornar o processo de alteração do código parte da tarefa de desenvolvimento de software, visando melhorá-lo. Vamos fazer isto não porque haja algum erro ou porque os requisitos mudaram, mas sim porque entendemos o código como algo que deve evoluir juntamente com o desenvolvedor e seu entendimento do domínio do problema que ele visa resolver.

É fácil perceber o quanto de verdade há neste pensamento. Pense em você mesmo há seis meses. Será que se fosse escrever um código daquela época nos dias atuais você faria exatamente igual? O quanto seu conhecimento atual lhe permitiria escrever um código que modelasse melhor a realidade do domínio? A título de exemplo, imagine um desenvolvedor que jamais tenha tido contato com o princípio DRY e, que tenha escrito, um código há seis meses. Este mesmo desenvolvedor pode ter tomado conhecimento deste princípio neste intervalo de tempo, o que o tornaria um agente ideal para alterar o código e resolver todos os problemas de código repetido desnecessariamente (se é realmente necessário). Veja, o agente da mudança neste caso foi o próprio desenvolvedor, motivado pela evolução da sua “visão” sobre o código. Para os adeptos isso acontece o tempo todo.

Obviamente há riscos em “mexer em time que está ganhando”. Tornar a alteração de código algo comum em seu ambiente de forma que isto seja considerado seguro é uma arte muito sutil e que deve ser executada por desenvolvedores que saibam exatamente o que estão fazendo. A refatoração, ao contrário de uma alteração de código, motivada por um erro ou uma alteração de requisito, tem por objetivo melhorar a estrutura interna do código. E mais, fazer isto sem afetar explicitamente aquilo que o usuário experimenta.

Pensando no código como um texto bem estruturado

Os princípios e técnicas que serão discutidos terão como foco maior a expressividade. Ou seja, discutiremos formas de expressar soluções em código de forma clara e entendível por seres humanos. Uma boa atitude para começar é pensar no código como um texto bem estruturado. Tudo conta. Regras de ortografia, palavras bem escolhidas, ideias claras e em ordem correta. Se fizermos um paralelo com desenvolvimento de código, veremos que guardadas as devidas proporções, é possível estruturar códigos fontes de forma que possam ser mais fáceis de ler e consequentemente manter.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?