A importância do DRY

Muitas vezes quando pegamos um código legado e temos que modificar alguma função utilizadas em vários lugares por causa de alguma regra de negócio, trememos.

Primeiro lugar, será que essa função está sendo usada como deveria ser? Segunda, será que essa regra de negócio está implementada só ali? Será que não há duplicação de código?

Don't repeat yourself, é um importante mantra dos programadores. Não repetir você mesmo nem sempre é mais rápido ou mais fácil no começo, provavelmente é muito mais fácil copiar e colar aquela função e fazer as modificações que você precisa. Mas e a dor de cabeça depois? Você vai lembrar desta duplicação? Mais importante, as pessoas que virão depois de você no projeto, vão saber desta função duplicada?

Existem milhares de maneiras de se fazer isso, os padrões de projetos são uma buzzword do momento juntamente com a orientação a objetos que teoricamente vieram também para suprir esse tipo de necessidade.

Acredito que este não é um tema novo, mas existe um lado que pouca gente comenta. Não se repetir, também significa não repetir informações que estão no código por meio de comentários que o sucedem.

A máxima "código bom é código comentado" está completamente errada. Um código nada mais é do que um texto ou uma formula matemática, ele mesmo pode se explicar...Se bem feito! Códigos bem feitos não precisam explicação. O livro O Programador Pragmático defende que comentários devem ser feitos unicamente para explicações macros. Ao invés de explicar que você está pegando uma tabela do banco de dados e colocando em um VO, que tal explicar o que aquela entidade representa para o negócio?

DRY é dificil e penoso no começo, mas ira salvar a sua pele no futuro. Não queira ser o culpado pelo próximo programador estar xingando a mãe de todo mundo por ter que fazer a mesma mudança em um bilhão de lugares :)