<-- home

Primeiro Coding Dojo

Hoje participei do primeiro - mas de longe não último - coding dojo da minha vida. Tive uma impressão bastante positiva sobre o processo.

Um dos acontecimentos do evento, o qual prendeu meu pensamento, foi uma distinção feita entre reescrita e refatoração. O argumento utilizado foi que refatoração se trata de manter o design original apenas ajustando suas bordas e que reescrita significa destruição do design original em detrimento de outro mais adequado aos novos requisitos. Nunca tive em mente esta distinção, não obstante, a dúvida ficou pairada na minha mente e decidi pesquisar sobre o assunto. E, como eu suspeitava a definição de refacoring é o processo de alteração de software de uma forma que ele não mude seu comportamento externo (nenhuma menção sobre design). Não obstante, este fluxo de pensamento me induziu a pensar no caso da viabilidade da refatoração. Assunto que me deparei nestas duas últimas semanas em vista de uma refatoração substancial de um código apodrecendo.

Sou um programador. E acho que a postura correta do programador é que, em vista de um design melhor - para as necessidades atuais e futuras - sempre vale à pena a refatoração. Se você é um profissional na escrita de software é sua obrigação lutar pela base o mais limpa e concisa o possível. A postura de If It Is Working Dont Change quase nunca é eficiente para o programador. Defender a manutenção do “design original” na hora da refatoração apenas “ajustando as pontas” soa um tanto quanto os hacks que geram problemas de viscosidade. Em suma, se seus requisitos mudaram e seu software necessita de mudanças que o design não comporta, não me parece uma posição defensável para o programador - o profissional da escrita de software - defender a manutenção de algo insustentável.

Obviamente o mundo não é tão binário quanto eu gostaria. Os interesses variam no projeto. Um programador ideal se preocupa como o código, defende-o, mas existem outros stakeholders, o gerente de projetos por exemplo. Cabe a este, entre outras tarefas, controlar os prazos; para ele geralmente não é evidente a necessidade de refatoração de um código e, mesmo quando evidente, algumas vezes não lhe parece uma boa ideia.

Em vista deste conflito de interesses, para que as duas partes fiquem satisfeitas, é necessário um processo racional. Este post sobre Economia da refatoração aborda os fatores de influência na hora de considerar a refatoração, cabe a ambas as partes dialogar e decidir se o momento é adequado à refatoração ou não.

Referências

  1. http://c2.com/cgi/wiki?WhatIsRefactoring
  2. http://c2.com/cgi/wiki?EconomicsOfRefactoring