Big Ball of Mud, é um código bagunçado que é mal estruturado, desleixado e muitas vezes amarrado com fita adesiva. Com o passar dos anos tentamos introduzir vários guidelines tais como SOLID, GRASP e KISS, alta coesão e baixo acoplamento para lidar com a lama. Entretanto, a situação parece continuar e ainda vemos que a "Grande Bola de Lama" parece ser o jeito mais popular de fazer o design de um software.
Dave Nicolette, mencionou que ele recentemente se deparou com um pedaço de código feito escrito em Java parecido com o código abaixo
public Thing getThing(Integer id) {
return new Beta().getGamma().getDelta().getEpsilon().getOmega().getThing(id);
}
O código tem muitos code smells como:
- Mensagens encadeadas – a chamada para pegar a "coisa" possuí seis níveis de chamadas
- Intimidade inapropriada – o cliente deve conhecer os detalhes internos e a estrutura de outras classes
- Exposição indecente – beta, gamma, delta, etc permitem a exposição indecente para chegar a um terceiro objeto
De acordo com Dave, parecia que
Apesar da quantidade e riqueza de informações disponíveis sobre o assunto, parece que a grande maioria das pessoas que escrevem software são
(a) completamente inconsciente de quaisquer boas práticas para fazer o design de um software, OU
(b) compreendem mal os guidelines.
Do mesmo modo, FJ recordou a experiência do Agile 2009 relacionado a uma sessão de Brian Foote e Joseph Yoder.
As razões para acontecerem estes problemas no código são
- Código throwaway
- Crescimento fragmentado
- Mantê-lo funcionando
- Fenômeno do Copiar / Colar (código mal feito é reproduzido em muitos lugares)
Curiosamente, que assim como FJ, Yoder senti que muitos aspectos do Agile nos leva diretamente à lama. Estes incluem,
- Falta de um design claro
- Alterações tardias aos requisitos
- Alterações tardias da arquitetura
- Crescimento fragmentado
De acordo com Yoder, o Agile pode nos ajuda não como um processo mas por causa de suas práticas como atenção contínua para excelência técnica, retrospectivas, conversas cara a cara e indivíduos motivados. Uma das
ferramentas sugeridas por Yoder
são refatorações simples e testar sempre que o software estiver se degradando.
Como Dave disse,
Apesar do surgimento de métodos de desenvolvimento que incentivem e facilitem código bem feito, e o crescimento do movimento Software Perfeito, a grande bola de lama continua a ser o modelo mais popular para software.