Já referi em outras ocasiões como a  palavra “design” usada na literatura em inglês tem fraca tradução para português ( Design Patterns => Padrões de Projeto). A ideia de que existe um “desenho” a ser feito é perdida.

A ideia de um desenho é a de criar um esboço funcional daquilo que a coisa é, antes que começar a fazê-la. É algo bem diferente em propósito daquilo que seria uma planta (blueprint), em que todos os detalhes tecnicos têm que estar presentes.

Tradicionalmente projetos de software são encarados como projetos de engenharia civil em que o software é um edificio a ser construido através de uma planta. O problema é que raramente essa planta contém todos os detalhes tecnicos. A base tradicional para a construção de um software é um conjunto de requisitos;  o que, convenhamos, é bem longe de um planta tecnicamente detalhada.

É ai que entra o design. A ideia é vislumbrar como os requisitos podem ser transportados para um conjunto de artefactos de software ( classes, sistemas, serviços , etc…)

É ai também que entra aquilo que é designado  (prejorativamente) de Big Design Up Front- BDUF (Grande desenho logo no ínico / antes de tudo). A ideia que é designada por esta sigla é a ideia de construir a planta do sistema. Isto assume que é possivel saber todos os detalhes tecnicos e não tecnicos para o software antes de iniciar a sua programação, e pior que isso, assume que não existirão alterações futuras durante o desenvolvimento.

Historicamente a verdade é que é bem improvável que um plano assim nunca seja alterado devido às verdades universais como  “o cliente nunca sabe o que quer”. Aliás o mesmo problema do desenvolvimento em cascata (Waterfall) em que o BDUF é usado.

As críticas ao BDUF  ( sobretudo do pessoal da linha ágil, mas também de outras metodologias que não o waterfall) são provadas por imensas estatisticas simples de quantas alterações a “planta” sofreu ao longo do projeto. Se o projeto terminar ( se terminar – porque esta metodologia consume muito tempo e dinheiro) é facil provar como a planta original foi alterada várias vezes apenas olhando o históricos dessas alterações.

O pulo-do-gato para o precipício é extrapolar que todo e qualquer trabalho de desenho feito antes da escrita do código do  software é BDUF e portanto ruim e a evitar. E isto é uma falácia.

É preciso planejar o software de um ponto de vista abrangente o suficiente para entender pontos de risco e técnicas de desenvolvimento para os mitigar. Uma coisa tão simples como a escolha de qual tecnologias utilizar pode ser um problema a longo prazo se não for bem pensando com antecedência. Por exemplo, o uso de linguagens não compiladas como Ruby em sistemas que necessitam de alto desempenho pode se provar um erro no futuro.  Ou algo mais simples : escolher um plataforma sem suporte à geração de relatórios para um sistema de ERP.

A resposta à falha de ter desenhado o sistema tem duas vertentes: a gambiarra e a refactoração. A gambiarra, como todos já devem saber neste momento não é saudável e pode causar prejuizos elevados aos donos do software e à sua saude pessoal, quer mental quer material.  A refactoração é a arte de mudar o como o software faz o que faz sem alterar o que ele faz. Isto, básicamente, significa que ao refactorar um código você nunca irá acrescentar funcionalidades ao sistema. O argumento que a refactoração pode alterar a estrutura do codigo de forma a ser mais facíl adicionar novas funcionalidades é válida, mas apenas relevante para sistemas mal desenhados.  Sistemas bem desenhados têm pontos de extensão por construção, por design, e portanto a refactoração torna-se irrelevante.

A única resposta para ter um sistema bem estruturado é estruturá-lo desde o começo. Estruturar um software tem dois passos : Arquitetura e Design ( desenho).

A arquitetura escolhe as tecnologias necessárias para suprir os requisitos não funcionais do sistemas como estabilidade, escalabilidade,   baixo custo de execução e manutenção. Aqui as dependências externas do sistema como o uso de banco de dados, ou serviços especializados de terceiros são equacionadas de forma a que alterações desses serviços e sistemas tenham o menor impacto possível na aplicação a ser desenvolvida. Também a disponibilzação do software ao seu usário tem que ser pensada.

O desenho serve para atar estas partes ‘por dentro” do sistema. Definição de camadas, classes, aplicação de padrões, etc. O design é feito para apoiar a decisão da arquitetura mas flexivel para suportar a uma mudança de arquitetura. Isto pode parecer complexo e caro, mas não é.

Da mesma forma que o bom design isola as decisões arquiteturais ( por exemplo, de dentro de uma classe não ser possivel saber se o sistema está correndo standalone ou em rede) ele também tem que isolar as decisões de escolha de tecnologia. É comum escolhermos o framework X porque ele está na moda ou até parece ser o melhor para o que necessitamos. Mas depois de 6 meses decobrir que a implementação é cheia de bugs ou a documentação não é suficiente para sabermos atender um certo rquisito do cliente final. Imagine escolher uma biblioteca de gráficos quando o requisito é fazer gráficos de pizza  e depois decobrir que ela não faz gráficos de barras quando daqui a 6 meses um relatório com isso for pedido.

Com um Big Design Up Front a ideia não é detalhar todas as minucias de como será o software mas prover o software de suficientes pontos de dobra para poder ser flexivel face às mudanças de tecnologia.No caso do gráfico, por exemplo fariamos uma casca de framework seguindo o padrão Bridge. Dessa maneira podemos plugar depois outros geradores de gráficos.

Ser previdente e pensar no design da aplicação traz vários beneficios porque o software é desenhado para ter uma série de qualidades que aparecem sem trabalho forçado de codificação.

Agora, não confundir um “bom plano” com uma “boa planta”. A documentação de um BDUP é o próprio codigo, as proprias classes e interfaces. Ele está presente na boa separação de responsabilidades, programação para interfaces, boa nomenclatura, enxugamento tecnologico (não usar demais APIs não padrão ou de terceiros) e até nas boas práticas do dia a dia como a revisão continua do codigo , a escrita de testes e a integração continua.

Big Design Up Front é ruim se você o entender como “desenho de muitos bonecos que tentam especificar tudo em detalhes”, mas é imprescindível se você o entender como “entender o grande esquema das coisas antes de tomar micro decisões”