Big Design Up Front 

Oct/09
1

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”

2 comentários para “Big Design Up Front”

  1. […] This post was mentioned on Twitter by Daniel Bussade. Daniel Bussade said: RT: @sergiommtaborda: Se eu lhe disser que BDUF √© bom, voc√™ fica escandalizado ? http://bit.ly/1UGT8u […]

  2. […] grande,representa um grande design logo no inicio (Big Design Up Front) . Sim. Precisa mesmo. E isso n√£o √© mau. O que √© mau √© um Big Implementation Up Front onde […]

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos