Design e Arquitetura 

Jan/21
18

Uma das d√ļvidas mais prementes em desenvolvimento √© entender a diferen√ßa entre Design e Arquitetura. E muita gente vai lhe explicar como eles s√£o diferentes. Como design tem mais que ver com c√≥digo e coisas como os Princ√≠pios SOLID e que arquitetura tem mais que ver com os atributos do sistema como Seguran√ßa e Escalabilidade.

Isso n√£o √© mentira, mas pode ser redutor. √Č como explicar a diferen√ßa entre cara e coroa sem dizer que ambas fazem parte da mesma moeda. Esses artigos s√£o bons para nos aprofundarmos nos detalhes de cada conceito, mas falta algo que os una. Veremos neste artigo como Design e Arquitetura est√£o relacionados e n√£o s√£o duas disciplinas desconexas.

A primeira coisa a entender é que tudo é Design e que, consequentemente, Arquitetura é Design.

Tudo é Design

Construir um software √© antes de mais uma atividade intelectual que tem apenas que ver com tomar decis√Ķes. N√£o √© realmente sobre escrever c√≥digo. Isso √© como, n√£o o qu√™ .Todas as decis√Ķes que voc√™ toma enquanto constr√≥i um software s√£o decis√Ķes de Design. Desde qual linguagem usar, qual c√≥digo escrever, quais entidades usar at√© como distribuir o sistema em que OS o sistema vai rodar ou que cor o bot√£o de login vai ter.

Nada √© deixado ao acaso, Tudo s√£o decis√Ķes. O conjunto de todas essas decis√Ķes s√£o o Design. Simples assim.

Design Incidente vs Design Emergente

Existem duas principais formas de como um desenvolvedor toma as decis√Ķes.

Algumas decis√Ķes s√£o tomadas conscientemente e com um prop√≥sito especifico. O conjunto destas decis√Ķes √© chamado de Design Incidente. Por exemplo, quando voc√™ escolhe a plataforma Java porque quer que o sistema rode em qualquer OS, e escolhe Kotlin para programar porque √© a linguagem com que sua equipe tem mais familiaridade voc√™ est√° tomando especifica e conscientemente a sua decis√£o.

Algumas outras decis√Ķes simplesmente decorrem das decis√Ķes incidentes ou s√£o for√ßadas por alguma circunst√Ęncia. Por exemplo, se o cliente quiser um sistema web, a sua decis√£o de usar um servidor HTTP n√£o √© realmente sua escolha. √Č algo que nasce da circunst√Ęncia de um sistema web ser baseado em HTTP.

Como o design emergente depende das circunst√Ęncias e as circunst√Ęncias mudam ao longo do projeto, novas decis√Ķes t√™m que ser tomadas para adaptar o trabalho que j√° foi feito √†s novas necessidades. Este acumulo de decis√Ķes n√£o controladas e n√£o previstas leva, se n√£o houver cuidado, a um design inintelig√≠vel. Design emergente tamb√©m pode ser considerado design ad hoc, ou seja, aquela se produz o resultado esperado, mas que n√£o sabemos por qu√™.

Atualmente muitos desenvolvedores acreditam que o design emergente √© algo bom e que Agile √©, n√£o apenas, adequado a ele, mas como uma necessidade. Isto adv√©m da confus√£o entre Design Incidente e Big Design Up Front (BDUF). Ha uma diferen√ßa entre todo o design ser consciente e com prop√≥sito – design incidente – e todas as features terem que ser desenhadas nos primeiros dias do projeto – BDUF. Ter algumas decis√Ķes conscientes e especificas de prop√≥sito no inicio √© sempre necess√°rio. Por isso, muitos advogam o conceito de Some Design Up Front ou Little Design Up Front, na tentativa de deixar claro que no inicio do projeto algumas decis√Ķes s√£o sim obrigatoriamente incidentes. Como por exemplo, qual linguagem usar. N√£o √© algo que voc√™ pode decidir depois. O mesmo √© v√°lido para a plataforma, por exemplo.

Decis√Ķes Revers√≠veis vs Decis√Ķes Irrevers√≠veis

As decis√Ķes de design se separam em decis√Ķes revers√≠veis (soft) e irrevers√≠veis (hard).

Em ingl√™s ouvimos falar de hard decisions (decis√Ķes irrevers√≠veis) e soft decisions (decis√Ķes irrevers√≠veis)

Decis√Ķes revers√≠veis s√£o todas aquelas que voc√™ pode decidir diferente depois. Por exemplo, voc√™ criou uma classe factory, mas depois decidiu que n√£o precisava e passou a usar o construtor diretamente. Tudo bem.Mas, algumas decis√Ķes s√£o irrevers√≠veis. N√£o quero dizer totalmente irrevers√≠veis, j√° que nenhuma decis√£o em software √© completa e totalmente irrevers√≠vel. Chamamos assim porque o custo, o tempo ou ambos, seriam t√£o proibitivos que realmente a probabilidade de haver a mudan√ßa √© muito pr√≥xima de zero. Para todos os efeitos pr√°ticos consideramos irrevers√≠vel aquilo que √© muito custoso e dif√≠cil (hard). Por exemplo, se escolher C#.NET para desenvolver e depois de 3 anos compreende que deveria ter usado Scala em Java, n√£o √© poss√≠vel reaproveitar o c√≥digo de um jeito f√°cil. No fim, ou continua com C# ou vai ter que escrever o software de novo em Scala.

Isto nos leva ao conceito de Arquitetura

Arquitetura é Design

Arquitetura √© o (sub)conjunto das decis√Ķes de Design que s√£o irrevers√≠veis.

Ent√£o acaba sendo que em arquitetura voc√™ ter√° de decidir sobre plataformas, linguagens, seguran√ßa, escalabilidade, performance … tudo coisas que n√£o ser√£o simples nem baratas incluir no software depois. Voc√™ pode mudar de uma arquitetura monol√≠tica para uma de micro-servi√ßos? sim, claro, mas ter√° um custo. N√£o √© algo estritamente irrevers√≠vel, mas √© muito custoso e dif√≠cil (hard).

√Č pela raz√£o da arquitetura lidar com decis√Ķes mais permanentes que ela ganha import√Ęncia e √© comparada √† arquitetura de casas (de onde tomamos emprestado o nome). Depois que voc√™ constr√≥i uma casa √© complicado mudar o banheiro ou a cozinha de lugar. Claro, n√£o √© imposs√≠vel, mas provavelmente √© mais barato e simples comprar outra casa.

Estas “coisas fixas” da arquitetura de casas s√£o realmente muito importantes e formam a base do livro A Pattern Language: Towns, Buildings, Construction (Christopher Alexander et all) de 1977 onde os autores falam sobre conceitos e dicas que elas consideram repetidas ou referencias absolutas, a que eles chamaram de Pattern (Padr√£o).

Esta foi a base para o celebre livro do Gang of Four : Design Patterns: Elements of Reusable Object-Oriented Software (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) de 1994. O livro absorve a ideia de que sempre que estão em causa certas forças, com certos constrangimentos, e se queremos seguir os Princípios de Design iremos percorrer um mesmo raciocínio e portanto tomar a mesma decisão.

O conceito de Padr√£o (Pattern)

Padr√£o √©, em software, um conjunto de decis√Ķes que t√™m por base um racioc√≠nio bem estabelecido em princ√≠pios de Design com resultados comprovados.

De uma forma muito simplista podemos dizer que Padr√Ķes de Design (Design Patterns) s√£o decis√Ķes pr√©-prontas ao mesmo tempo que s√£o rela√ß√Ķes conhecidas entre decis√Ķes. Uso o termo Padr√Ķes de Design em vez de Padr√Ķes de Projeto porque acho que n√£o √© uma boa tradu√ß√£o, fora que se acharmos coisas repetidas nos projetos como vamos chamar ? E sim, existem padr√Ķes em estabelecer e conduzir projetos como o Principio da M√≠nima Surpresa, o Principio de Pareto, o Principio de Dilbert, a Lei de Brooks e tantos outros… Bom, acho que afinal esses n√£o se chamam padr√Ķes, chamam-se princ√≠pios e leis. Imp√Ķe mais respeito.

Se temos Padr√Ķes de Design, teremos Padr√Ķes de Arquitetura, j√° que Arquitetura √© um subconjunto do Design. Normalmente os desenvolveres fazem grande distin√ß√£o entre os dois tipos. √Č realmente importante destingir j√° que um padr√£o de arquitetura tem que com algo que vai ficar permanentemente dentro do software e ser√° muito dif√≠cil de mudar. Exemplos s√£o destes padr√Ķes s√£o Separa√ß√£o em Camadas, Model-View-Controller, Pipe-Filter, Producer-Consumer e aquilo que redundantemente chamados de “arquiteturas” como Client-Servidor, MicroServi√ßos, Event-Bus, Peer-to-Peer, entre outros.

J√° os Padr√Ķes de Design que n√£o s√£o de Arquitetura, s√£o mais relacionados ao c√≥digo como Factory, Singleton, Bridge, Strategy, Command, Value Object, Repository, Entity entre outros.

Entenda que, na pr√°tica todos s√£o padr√Ķes de design e que todos influenciam o c√≥digo que voc√™ escreve. N√£o poderia ser de outra forma, j√° que software √© c√≥digo e todas as decis√Ķes que voc√™ toma s√£o sobre como escrever esse c√≥digo.

Código Sem Design

Estritamente falando n√£o √© poss√≠vel tem um c√≥digo sem design, porque n√£o √© poss√≠vel ter um c√≥digo sem ter tomado decis√Ķes, e o design nada mais √© que o conjunto de decis√Ķes. Mas da mesma forma que falamos que uma sala, ou uma mob√≠lia, tem design ou n√£o, tamb√©m falamos que de um c√≥digo ter design ou n√£o.

Quando falamos que algo tem design, n√£o nos referimos que decis√Ķes foram tomadas, mas sim que elas foram tomadas de uma forma consciente, causal e principalmente, correlacionada. Ou seja, n√£o foram decis√Ķes aleat√≥rias ou √† toa. Existiu um racioc√≠nio e uma apre√ßo pelas consequ√™ncias. As decis√Ķes t√™m um fio condutor, embora nem sempre seja √≥bvio qual √©, sentimos que ele est√° l√°.

Em software c√≥digo com design √© isso, um c√≥digo que foi escrito com inten√ß√£o e com conhecimento das implica√ß√Ķes e consequ√™ncias que ele tem no todo. Ele pode ser considerado mon√≥tono ou exc√™ntrico conforme a moda, mas ser√° com ou sem design considerando a inten√ß√£o.

Isto nos leva de volta ao conceito de Design Incidente. Todo o c√≥digo tem design, mas o melhor c√≥digo tem Design Incidente. Nem todo o c√≥digo pode ter design incidente e temos que viver com uma parte de Design Emergente de vez em quando, mas quanto mais Design Emergente seu c√≥digo tem, pior. Mais dif√≠cil de mudar ele ser√°, por que por defini√ß√£o voc√™ n√£o entende ou controla essa parte do design. √Č um design espont√Ęneo dif√≠cil de controlar.

Usar Design Incidente n√£o √© simples. N√£o brota das pedras como o Emergente. Design Incidente requer estudo e constante evolu√ß√£o. O design Incidente de ontem n√£o mais vale hoje porque aprendemos certas coisas no meio tempo. √Č preciso ter muito cuidado com o que decide. Especialmente se a decis√£o √© revers√≠vel ou n√£o. Um c√≥digo com design √© aquele que minimiza as decis√Ķes e aos mesmo tempo maximiza as decis√Ķes revers√≠veis. Um c√≥digo com design toma poucas decis√Ķes e todas s√£o revers√≠veis. Na pr√°tica, n√£o h√° como s√≥ tomar decis√Ķes revers√≠veis. Como vimos, a escolha da linguagem, por exemplo, √© um decis√£o irrevers√≠vel que √© imposs√≠vel n√£o fazer.

Como vimos todo o c√≥digo tem design, mas h√° diferentes tipos de combina√ß√Ķes de design que podem existir no seu c√≥digo:

ReversívelIrreversível
Incidente√ďtimo
√Č aqui que voc√™ quer estar. Tomando decis√Ķes conscientes que podem ser revertidas com pouco esfor√ßo. Mas isto exige conhecimento, treino e estudo.
Menos bom
N√£o tem como escapar de tomar um decis√£o irrevers√≠vel de vez em quando. Voc√™ quer minimizar este tipo de decis√Ķes. Tornar decis√Ķes Irrevers√≠veis em Revers√≠veis deve ser seu principal objetivo como desenvolvedor.
EmergenteNada bom
Tomar uma decisão emergente pode ser bem enganador e estranho de reverter depois, mas se a decisão é Reversível existe a oportunidade de a tornar Incidente e Reversível depois. Não é aqui onde você quer estar no seu processo de decisão, mas poderia ser pior.
Péssimo
Uma decis√£o emergente e irrevers√≠vel √© pior que pode acontecer. Porque √© irrevers√≠vel n√£o ser√° poss√≠vel mudar, mesmo quando descobrir que havia uma solu√ß√£o melhor e sendo emergente voc√™ nem entende bem a raz√£o que est√° comandando aquela decis√Ķes ou est√° t√£o amarrado pelas circunst√Ęncias que n√£o pode decidir de outra forma.

Como pode ver √© verdadeiramente importante tomar Decis√Ķes Revers√≠veis de forma Incidente. √Č isto que chamamos intuitivamente de “Bom design”. Um bom design leva a um c√≥digo de f√°cil manuten√ß√£o e f√°cil altera√ß√£o quando as circunst√Ęncias mudam. Isto n√£o significa que v√£o existir poucas classes. Significa que voc√™ vais entender todas as classes. O n√ļmero de classes n√£o √© m√©trica da qualidade do seu design.

Se você se achar em um dos outros quadrantes o que pode ser feito para voltar ao primeiro ? Vejamos.

  • Design Irrevers√≠vel e Incidente – voc√™ pode aplicar t√©cnicas como padr√Ķes de arquitetura e design para tornas suas decis√Ķes irrevers√≠veis em revers√≠veis. O objetivo √© isolar a parte irrevers√≠vel dentro de uma parte plug√°vel do design. Bridge e Strategy s√£os bons para isto. Aplicar padr√Ķes n√£o toma muito do seu tempo e √© uma boa forma de garantir resili√™ncia √†s mudan√ßas que vir√£o. Em contrapartida n√£o √© qualquer um que consegue analisar o c√≥digo e conseguir isto. Provavelmente ir√° precisar de um desenvolvedor mais s√™nior na sua equipe.
  • Design Emergente e Revers√≠vel – talvez este seja o mais f√°cil de lidar. Torne o design Incidente entendendo a raz√£o dos constrangimentos e das consequ√™ncias. Aplicar Padr√Ķes de Design pode ajudar a isolar o c√≥digo que corresponde com o que √© realmente emergente e o que √© incidente. Compreender mais os requisitos e a possibilidades de solu√ß√£o podem tirar voc√™ deste quadrante. Um bom analisador de requisitos e pessoas treinadas tanto em design como arquitetura podem ajudar.
  • Design Emergente e Irrevers√≠vel – este √© o mais dif√≠cil. Tente ao m√°ximo compreender por que √© uma decis√£o irrevers√≠vel. Talvez adicionando mais um camada ou alguma biblioteca voc√™ pode tornar a decis√£o mais revers√≠vel. Por exemplo, se voc√™ tiver que usar um certo banco de dados √© bom garantir que consegue mudar para outro com pouco esfor√ßo. A tecnologias escolhida para a conex√£o vai ditar a irreversibilidade da decis√£o, ent√£o escolha bem. Nem todas as decis√Ķes neste quadrante podem ser movidas para outro quadrante. Tente entender quais n√£o podem e seguir em frente. Por exemplo, a escolha da linguagem pode ser uma decis√£o emergente – quando √© imposta pelo cliente , ou a equipe s√≥ sabe uma linguagem – e sempre √© irrevers√≠vel. De novo, um bom analisador de requisitos e pessoas treinadas tanto em design como arquitetura podem ajudar.

O Arquiteto

Se tomamos emprestado o nome Arquitetura para nos referirmos ao design irrevers√≠vel (hard) , tamb√©m tomamos emprestado o conceito de Arquiteto. N√£o h√° muito tempo ser arquiteto era um escal√£o da carreira de um programador. Em algumas empresas ainda √©. Isto leva rapidamente ao anti-padr√£o conhecido como Ivory Tower. Hoje em dia se abomina essa palavra e esse cargo (deveria, pelo menos). O arquiteto de software n√£o √© um cargo, √© um conjunto de skills que uma pessoa tem. Se arquitetura √© um conjunto de decis√Ķes irrevers√≠veis, o arquiteto √© aquele desenvolvedor que consegue contornar essas decis√Ķes com melhor custo/beneficio para o projeto. O estudo e experi√™ncia v√£o acumulando, e perante um problema essa pessoa j√° sabe como decidir. O que vemos hoje em dia √© as empresas chegarem √† conclus√£o de que o cargo de Arquiteto √© um anti-padr√£o e com isso jogam foram o conceito e os skills em si, assumindo que qualquer conjunto de desenvolvedores num squad pode realizar o mesmo. Ou seja, assumem que X juniors + Y seniors = 1 Arquiteto. Nunca foi, n√£o vai ser agora, por m√°gica.

√Č vital ter uma pessoa com conhecimentos de arquitetura durante o processo de desenvolvimento do software. Especialmente no principio, mas n√£o apenas no principio. √Č necess√°rio que essas pessoa participe continuamente de forma a garantir que futuras decis√Ķes s√£o compat√≠veis com decis√Ķes anteriores. Como vimos, tomar decis√Ķes √© um processo continuo em desenvolvimento de software. √Č o pr√≥prio desenvolvimento de software. E muitas dessas decis√Ķes ser√£o irrevers√≠veis e/ou emergentes se decididas por pessoas despreparadas. √Č do interesse de todos que as decis√Ķes sejam tomadas por pessoas preparadas. E aqui n√£o se trata de apenas ter senioridade, mas de realmente ter capacidade. N√£o √© todo o mundo, nem todo o senior, que √© um bom arquiteto, mesmo quando a pessoas se intitula Arquiteto. Especialmente se a pessoa se intitula Arquiteto.

Como o processo de desenvolvimento √© um continuo de tomadas de decis√Ķes todos temos que ser designers de software, e como algumas dessas decis√Ķes ser√£o irrevers√≠veis, todos somos um pouco arquitetos. Mas sermos designers e arquitetos, n√£o significa que somos bons designers e arquitetos. Tomar boas decis√Ķes, e ser um bom Designer e um bom Arquiteto, requer estudo e experi√™ncia.

De M√©dio , de M√ļsico (, de Designer) e de Louco, todos temos um pouco. Mas se voc√™ quer ser um desenvolvedor profissional, precisa ter bem mais que um pouco de Designer. E para isso precisa estudar. Estudar padr√Ķes sejam de design ou de arquitetura √© um bom principio. Al√©m disso h√° que estudar os designs de outros sistemas e frameworks e praticar. Praticar bastante. Lembre-se que em desenvolvimento:

Tudo é Design.

Um comentário para “Design e Arquitetura”

  1. […] vimos antes, “uma arquitetura” √© o nome que damos a um conjunto de decis√Ķes especificas que […]

Comente

Artigos