Decis√£o Aberta 

Jul/12
13

Todo j√° nos deparamos, em algum projeto ou outro, com tomada decis√Ķes de arquitetura e design com as quais n√£o nos sentimos confort√°veis. Ha um peso de que temos que escolher logo porque o desenvolvimento n√£o pode ficar parado enquanto pensamos na melhor forma de fazer. Somos obrigados a escolher. E em arquitetura somos obrigados a escolher algo que n√£o fique obsoleto antes do projeto terminar. Como decidir ? Como eliminar as op√ß√Ķes ruins e escolher a melhor para ser implementada ? A resposta √© : n√£o precisamos eliminar , n√£o precisamos saber qual √© a melhor.

Vamos usar como exemplo a necessidade de colocar gráficos num sistema web. Imagine-se em 2000 quando o ajax ainda era desconhecido , e o canvas não existia. Como adicionar esta funcionalidade ? Podemos usar applets.  Podemos usar flash. Podemos usar AWT/Swing e desenhar o gráfico na mão e enviar para png, ou podemos usar o JFreeChart e produzir imagens dos gráficos em png.  Então escolhemos JFreeChart. Simplesmente geramos o gráfico em formato de imagem e mostramos num tag img do html. Funciona. E o que pode ser mais baba que isso ?
Agora imagine-se de volta  em 2012. Você ainda usaria este modelo ? seus clientes o achariam atraente ? Seria possivel em 2000 que anos mais tarde gostaríamos mudar ? Não gostaria de usar uma API javascript , baseada em JQuery , por exemplo. Ou quiça uma que use HTML 5 e canvas ?

Que pena. N√£o pode mais.

Quando a op√ß√£o foi feia para usar jfreechat+img fechamos as portas para todas as outras op√ß√Ķes. Inclusive as op√ß√Ķes da √©poca como applets e flash. Foi uma decis√£o de tencologia de gera√ß√£o de gr√°ficos, n√£o uma decis√£o de arquitetura de como desenhar o componente de gr√°ficos. √Č por termos fechado a porta, que anos mais tarde estaremos impossibilitados de alterar a renderiza√ß√£o dos gr√°ficos sem mexer na l√≥gica de neg√≥cio.¬† Sim, claro, podemos refazer tudo de novo, a l√≥gica de neg√≥cios, a renderiza√ß√£o etc, usando uma nova tecnologia. E daqui a 10 anos, teremos que refazer de novo ? N√£o parece uma solu√ß√£o econ√īmica.

√Č justo dizermos que esta foi uma m√° escolha e que o arquiteto deveria ter deixado op√ß√Ķes mesmo se naquele tempo n√£o se sabia o que vinha a seguir ? Podemos.

N√≥s n√£o sabemos o futuro. Nem sabemos prev√™-lo. Mas uma coisa que temos a certeza √© que¬† a tecnologia ir√° mudar. Ent√£o temos a certeza que novas op√ß√Ķes ir√£o aparecer.O que √© bom hoje , ser√° obsoleto amanh√£. Isto nos leva √† primeira regra da arquitetura [1]: n√£o fa√ßa escolhas irrevog√°veis. Ou seja, n√£o fa√ßa escolha que fecham as portas para outras op√ß√Ķes. No exemplo, sab√≠amos que applet era uma op√ß√£o, e flash tamb√©m. Isto nos diz que jfreechar+img n√£o √© a √ļnica op√ß√£o, que existem outras. Mas isso n√£o significa que temos que implementar a op√ß√£o flash, a applet e com o tag img e depois decidir pela melhor. N√£o. Significa que temos que nos valer de ferramentas t√©cnicas de forma a que possamos manter os conceitos e mudar as implementa√ß√Ķes. Mais que isso, precisamos de ferramentas que estejam provadas como solu√ß√Ķes ao nosso problema. Precisamos de usar padr√Ķes (patterns) sejam de arquitetura ou de design. Os padr√Ķes nos dizem como solucionar problemas como este: como implementar um mecanismo de gera√ß√£o e renderiza√ß√£o de gr√°ficos sem fechar as op√ß√Ķes presentes e futuras?

No caso, a resposta √© o padr√£o de componentes de ui que nada mais √© que MVC. Sabemos que queremos um componente de mostre gr√°ficos. √Č queremos inclui-lo nas nossas p√°ginas. Ent√£o podemos encapsul√°-lo em um tag lib ou um tag file. Isso nos permitir√° usar o componente nas p√°ginas sem ter que explicitar o como realmente ir√° funcionar. Isto √© o Controler. Depois queremos que os dados que alimentam o gr√°fico n√£o estejam presos √† op√ß√£o escolhida. Criamos objetos que sejam capazes de prover os dados sem realmente saber de onde (o cl√°ssico uso de interfaces) . Isto √© o Modelo.¬† Da mesma forma que estamos habituados a passar um objeto List para um tag <c:for> podemos pensar em passar um objeto Chart¬† para um <ui:chart> onde ui √© a nossa lib de tags. Nada de novo aqui e n√£o fizemos nenhuma escolha que nos prende ou impede de implementar qualquer das op√ß√Ķes. Podemos usar qualquer framework de controle de servlets que podemos sempre assegurar que teremos um objeto Chart para usar ; ou seja, se quisermos mudar algo, mudaremos a implementa√ß√£o do tag, n√£o a aplica√ß√£o. Mudaremos um componente, n√£o o sistema.

A implementa√ß√£o do tag √© agora live de escolher como ir√° apresentar a sua view. E podemos pensar at√© em view intercambi√°veis usando outros padr√Ķes como Factory. Podemos aumentar a flexibilidade do compoente. O ponto √© que conseguimos chegar na mesma implementa√ß√£o que antes jfreechart+img e ainda iremos implementar a mesma coisa e obter o mesmo resultado, mas n√£o fechamos nenhuma porta. N√£o fizemos nenhuma decis√£o irrevog√°vel. As decis√Ķes que fizemos nem sequer foram nossas. Apenas seguimos um padr√£o que √© bem estabelecido e provado. Se um dia, no futuro, quisermos mudar a renderiza√ß√£o mudaremos a implementa√ß√£o interna dos componentes, e nada mais.

Se entendeu at√© aqui, deve estar pensando que a resposta a todos os problemas √© flexibilidade. Sim, √©. Mas a flexibilidade √© tamb√©m um gerador de problemas. N√£o ha limite para o qu√£o flex√≠vel voc√™ pode fazer um design. Nem sempre precisamos de todas essas flexibilidade. Precisamos apenas de flexibilidade q.b. (quanto baste). Nem muita, nem pouca. N√£o podemos torna flex√≠vel o quanto quisermos. Temos que tornar flex√≠vel o quanto precisarmos.¬† Mas onde √© horizonte ? O que¬† “muito” ou “pouco” flex√≠vel significa ? √Č aqui que entra outro principio [2] : Pense Grande, fa√ßa pequeno.

Pensar Grande significa que devemos pensar em casos o mais gen√©ricos e abstratos poss√≠vel de forma a englobar todas as op√ß√Ķes. O que se chamar obter a “vis√£o de √°guia” do problema. O “big picture”. Depois que identificamos o que ha de op√ß√Ķes, estabelecemos um caminho e executamos apenas o menor esfor√ßo poss√≠vel. A √°guia ap√≥s encontrar a presa faz o menor esfor√ßo poss√≠vel apenas se deixando cair sobre a vitima. A gravidade faz todo o esfor√ßo e apenas basta pequenos ajustes de navega√ß√£o para ca√ßar a presa. Em arquitetura queremos um √ļnico design matador que n√£o feche as portas as nenhuma op√ß√£o. Um exemplo cl√°ssico da utiliza√ß√£o diste principio √© a lib de tags do struts 1. Quando o struts saiu, a ideia de usar tags que interagiam de forma simples e renderizavam os componentes foi tentadora para muitos. Mas estes componentes s√£o pouco flex√≠veis. Eles fecham a porta a poder modificar o como √© feita a renderiza√ß√£o.¬† Contudo a flexibilidade que bastava na √©poca era simplesmente poder usar css. Com uma capacidade de templating ou algum tipo de inje√ß√£o de renderizadores, poder√≠amos fazer o mesmo, deixando a porta aberta para quem quiser mudar, quando quiser mudar.

Pensar grande, √© considerado errado por muita gente. Com base em um mito de que “em √°gil n√£o se modela arquitetura e vai-se criando quando se precisa” as pessoas ignoram este passo. Isso cria sistemas complexos que s√£o muito dif√≠ceis de manter. N√£o ha componentes reaproveit√°veis, ali√°s n√£o ha componentes nenhuns. S√≥ existe um grande sistema.

Pensar 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 perdemos tempo implementando coisas que n√£o iremos usar. Criar uma interface para o modelo n√£o apenas √© r√°pido como √© a pr√°tica padr√£o ( Programe para Interfaces).¬† N√£o demora. Criar um tag , n√£o demora. E mesmo que criemos uma classe abstrata para dar suporte ao tag, √© simples. E apenas precisamos implementar uma das op√ß√Ķes. Dai o “Pensar grande, fazer pequeno”.

Repare que √© “pensar grande” e n√£o “desenhar grande” ou “documentar grande”. Para pensar grande basta ser humano e pensar. Algumas pessoas usam papel e l√°pis , ou quadro branco para ajudar a pensar, mas ainda estamos s√≥ pensando. N√£o estamos decidindo. √Č um brainstorm que se pretende amplo, que explore todas as op√ß√Ķes, inclusive as mais remotas. Depois iremos , com base nesse palco, criar um design que permita o m√°ximo de op√ß√Ķes sem fechar portas. Nem sempre isso √© poss√≠vel. Na pr√°tica voc√™ ter√° que fechar algumas op√ß√Ķes. Mas quando for tiver mesmo que fazer isso, tenha a certeza que n√£o outra op√ß√£o, que n√£o ha outro design poss√≠vel. Utilize-se de padr√Ķes. E quando tiver mesmo que fechar, feche algumas janelas e claraboias, n√£o portas. Finalmente execute pequeno, ou seja, use o design para implementar uma das op√ß√Ķes.¬† No final voc√™ ir√° apenas implementar uma op√ß√£o.

O trabalho, o esfor√ßo da implementa√ß√£o √© exatamente o mesmo da solu√ß√£o fechada mas apenas com um pouco mais de cuidado t√©cnico seguindo um padr√£o. A velocidade para fazer a primeira vez e deixar mais flex√≠vel n√£o tem que ser menor que a solu√ß√£o fechada para qualquer desenvolvedor s√™nior. Talvez para um j√ļnior o padr√£o ainda seja desconhecido ou n√£o bem entendido, mas mesmo assim a programa√ß√£o do c√≥digo em si, √© praticamente a mesma na solu√ß√£o fechada e na aberta. O trabalho de manuten√ß√£o ser√° reduzido e teremos uma pe√ßa flex√≠vel no nosso arsenal.

Arquitetura sempre foi, e sempre ser√°, sobre saber imaginar “O big picuture”, o “grande plano”¬† e dai isolar os componentes necess√°rios. Se diz que o Michael √āngelo pintou o teto da capela Sistina e √© lindo e por isso ele √© excelente artista e pintou. N√£o. Ele n√£o pintou ele mesmo. Ele delegou a outros. Ele √© um grande artista porque tinha a vis√£o do todo. E porque consegui delegar a outros pintores a sua vis√£o. Pessoas que trabalhavam isoladas , mas que eram guiadas pelo “grande plano”.¬† O arquiteto precisa saber ver o macro e o micro e saber navegar entre as escalas. Para aqueles que n√£o sabemos tudo isto, pelo menos podemos seguir regras simples como n√£o tomar decis√Ķes irrevog√°veis que fecham todas as portas e todas as janelas. Pensar √© algo que os seres humanos fazem muito depressa e o padr√Ķes ajudam a acelerar ainda mais esse processo ou mesmo tempo que d√£o a confian√ßa que n√£o estamos indo por caminhos escusos.

Quando voc√™ precisar decidir o seu pr√≥ximo passo no seu novo design, deixe a decis√£o aberta. Considere o macro, devida em componentes, aplique padr√Ķes, mantenha a flexilidade – n√£o tenha medo de refatorar para a obter – e deixe as suas op√ß√Ķes aberta. Mas nunca tenha mais trabalho do que teria se implementasse apenas uma das op√ß√Ķes. Porque √© isso que voc√™ est√° realmente fazendo : implementar uma op√ß√£o de entre todas as poss√≠veis, mas mantendo o fato que as outras ainda continuam poss√≠veis.

 

2 comentários para “Decis√£o Aberta”

  1. […] do projeto em termos de abstra√ß√Ķes, tentando deixar o¬†c√≥digo¬†o mais¬†flex√≠vel¬†poss√≠vel¬†adiando¬†decis√Ķes o […]

  2. […] A adapta√ß√£o acontece em v√°rios n√≠veis. Existe a adapta√ß√£o a novos requisitos como exemplifiquei,¬† a adapta√ß√£o a um novo modelo de dom√≠nio, a adapta√ß√£o a uma nova regra, a adapta√ß√£o a um novo design, a adapta√ß√£o a uma nova arquitetura, a adapta√ß√£o a uma nova forma de distribui√ß√£o, a adapta√ß√£o a um novo mercado, etc…¬† A adapta√ß√£o √©, como a inspe√ß√£o, constante e presente em todos os detalhes.¬† Sabendo que a adapta√ß√£o √© necess√°ria e ir√° acontecer, n√£o iremos desperdi√ßar for√ßas tentando resistir a ela. A mudan√ßa √© inevit√°vel, e portanto, a Adapta√ß√£o tamb√©m.Este principio est√° presente tanto no conceito de Refactoring,¬† como no Manifesto : “Responder a mudan√ßas“, como no conceito de Arquitetura Aberta. […]

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos