Não é novidade que no coração dos projetos de software bem-sucedidos (e, francamente, conduzindo carreiras) está o bom design. Também não é novidade que definir o que "bom design" realmente significa tem sido o centro de uma lista infinita de debates, artigos, palestras, livros, discussões, etc, por décadas. Para ajudar, J.B. Rainsberger e Scott Bellware oferecem alguns conselhos a seguir até que surja uma verdadeira definição.
Recentemente, o Agilista bastante respeitado e líder do pensamento TDD J.B. Rainsberger comentou sobre o modo como ao longo dos anos ele tem "assistido uma série de tentativas para desenvolver uma definição construtiva e completa do bom design". Sua primeira observação e revelação pessoal:
Algumas pessoas lamentam a falta de uma definição construtiva e completa do bom design. Eu não, e hoje eu finalmente descobri por que penso que não temos de nos preocupar com isso.
Ele continua com uma retratação que ele não discorda de ter um "teste claro para decidir quão 'bom' é o design"" seria uma coisa útil (com exemplos como o porquê), mas em seguida se continua dizendo porque não se preocupa como fato de que talvez ainda não tenhamos "um verdadeiro caminho". Ele aponta para sua experiência, para o que ele acha que nós temos que fazer para ajudar a otimizar nossas chances de conseguir um "bom design":
Nos últimos dez anos eu aprendi algumas coisas incrívelmente úteis sobre o design:Eu aprendi estas coisas na prática, através de proramação em par e observando outros programadores no trabalho. Acho que é mais importante notar que só com apenas estas três observações, nós melhoramos o valor do design do software consideravelmente.
- Quando os programadores escrevem testes de design, eles tendem a achar mais de seus próprios defeitos mais rapidamente, que reduz o custo total de compreender seu design.
- Quando os programadores duplicam o código, os índices de defeito aumentam, e quando eles reduzem a duplicação, os índices de defeitos diminuem.
- Quando os programadores começam a mudar código desconhecido, eles começam a esclarecer os nomes obscuros no código: nomes de variáveis, nomes de métodos, nomes de classes. Esta prática ajuda-os a alterar o código com mais segurança e de forma mais barate.
J.B. termina com uma reflexão sobre o que muitas vezes ele usa para identificar um bom design, "Eu me viro com o Teste do Miller: Eu reconheço quando o vejo."
Interessantemente, um dos temas chave do que J.B. está dizendo tem a ver com a idéia que para um design ser bom, deve ter "boa aparência" aos olhos de alguém novo para ele; (parafraseado) "..código desconhecido? Esclareça os nomes e então até você entenderá melhor...", "Eu sei quando eu ovejo". Para não esticar a mensagem do J.B. além do que ela significa, mas alguns poderiam usar isso para dizer que um bom design é "facilmente compreendido", e escrito sob a idéia recente do Scott Bellware. Em suas palavras:
A essência do "bom design" é a capacidade de ser absorvido pela mente humana. O design é "bom" quando ele pode ser facilmente compreendido.
...
Design bom é sobre conhecimento. Nós o envolvemos em todos os tipos de terminologia, mas no fim, é sobre fazer pequenos pedaços de software que são fáceis de entender por conta própria, que se encaixam para compor coisas maiores que si próprios e que possam ainda assim serem facilmente entendidos.
Bellware aprofunda sobre como o termo "testabilidade" refere-se a idéia de um bom design, mas não necessariamente na forma como muitas vezes é utilizado. Ele salienta que a "testabilidade" do código não é sobre "se ele pode ser testado", mas sim se ele "está [atualmente sendo] facilmente testado", e que "testes" tem tudo a ver com a compreensão:
Lembre-se, testar é fazer observações, e observações são para aprender.
...
Se é difícil criar um objeto afim de saber o que ele faz e se ele faz certo, então você provavelmente tem um objeto com o design pobre. Isto sugere que você usa codigo de teste para provar que você tem o design correto. E isto é o que testabilidade significa.
...
Não importa quão bom eu me torne em design orientado a objetos, a única prova de que um design é bom é código que prova concretamente que eu alcançei o mais elevado nível de facilidade de criação de um objeto para uso.
Assim, como aponta J.B., definir "bom design" sem ambiguidades pode ser aó mais uma daquelas cenouras numa vara; está sempre um passo a frente de nós, não importa quantos passos damos para frente. Mas ele também destaca, e como parece sugerir Bellware, há ferramentas à nossa disposição hoje em dia, para ajudar a nos guiar em direção a designs que nos mantenham produtivos e felizes, aproveitando nosso dia-a-dia como programadores. O que você acha disso?