Este artigo foi publicado em 12/08/2015. Por ter sido considerado um dos melhores artigos de 2015, foi republicado hoje.

Tenho estudado design de software há muitos anos, e há muitos anos tenho mudado de opinião sobre design de software. Tive, diversas vezes, entendimentos que pareciam corretos naquele momento e que se mostraram totalmente equivocados com o passar do tempo, mas tive também entendimentos que mantenho ainda hoje como possivelmente corretos.

A grande motivação para todo esse estudo e pesquisa foi tentar compreender o que, efetivamente, é design de software – afinal, acredito, não há como fazer algo bem feito se não compreendemos o que é esse algo. Esta que descreverei agora é a minha compreensão atual sobre design de software.

Participantes

Meu entendimento atual sobre design de software enumera três participantes:

1. Fornecedor
2. Produto
3. Consumidor

Entendo esses três participantes como participantes de alto nível, que podem ser percebidos em quaisquer níveis do desenvolvimento do software. O software principal – produto – é aquele desenvolvido por alguém ou alguma equipe – fornecedor – e que será utilizado por um usuário – consumidor.

Essa relação fornecedor, produto e consumidor é percebida também em níveis mais baixos do software, por exemplo: a biblioteca X – produto – é desenvolvida pelo desenvolvedor Y – fornecedor – e utilizada pelo desenvolvedor Z – consumidor. Ainda, se eu faço parte de um time que está desenvolvendo um software, todo código – produto – que eu – fornecedor – escrevo, será consumido pelo restante da equipe.

Quando percebi a existência desses três participantes, minha visão sobre design de software mudou completamente porque eu, como fornecedor, passei a ter um cuidado muito maior com meu produto e um respeito enorme por meus consumidores. Como fornecedor, passei a querer oferecer a melhor experiência possível, que resolva um problema e que entregue um grande valor para o meu consumidor, mesmo que o consumidor, eventualmente, venha a ser eu mesmo.

Elementos de design

Padrões, princípios e metodologias estão para o design de software, assim como a tipografia e a paleta de cores estão para o design gráfico.

Durante muitos anos eu achei que conhecer uma grande quantidade de padrões de design, princípios de design, técnicas de refatoração e metodologias de desenvolvimento eram suficientes para se obter um bom design. Mas finalmente percebi que não, não são suficientes. Padrões, princípios e metodologias estão para o design de software, assim como a tipografia e a paleta de cores estão para o design gráfico. São apenas elementos que podem compor o design ou destruir a peça.

Design de software, seja aquele software que será consumido pelo usuário final ou aquele que será consumido pelo restante da equipe e integrado ao software principal, é pensar no software como um produto. Esse produto deve resolver um problema e entregar um valor para o consumidor. É pensar em como o consumidor irá se relacionar com o todo e em como fazer com que o todo ofereça para aquele consumidor a melhor resolução de seu problema.

Todas as decisões de design devem ter suas consequências mensuradas e todas, absolutamente todas as decisões de design devem procurar oferecer um valor para o consumidor. Porque é justamente o valor entregue ao consumidor do produto que define o design. Meu código pode ter n padrões de design e seguir n princípios de design e, ainda assim, ter um mau design. E pode ter um mau design se eu utilizar esses elementos individuais sem pensar no produto final.

As consequências da utilização desses elementos individuais sem pensar no produto final tendem a causar problemas sérios de design. Problemas de design causam problemas para o produto, que causam problemas o consumidor. Se o software deveria ter a função de resolver um problema do consumidor, e estamos lhe causando problemas, então não estamos desenvolvendo softwares, estamos desenvolvendo problemas.

Framework para tomada de decisões de design

Atualmente utilizo um framework mental que é orientado por questionamentos. É como se eu estivesse utilizando um método socrático comigo mesmo. Quaisquer que sejam as decisões de design que preciso tomar, sempre me faço as seguintes questões:

1. Qual é minha intenção com essa decisão?
2. Qual é minha motivação para essa decisão?
3. Quais serão consequências dessa decisão?

Intenção – Qual é meu propósito com isso?

É preciso que a intenção de uma decisão esteja muito clara, mas que esteja totalmente focada no produto. Se minha intenção não tiver seu propósito focado no produto, mas focado em mim mesmo, então é possível que essa não seja uma boa decisão de design.

Já me peguei diversas vezes próximo a tomar uma decisão de design para deixar meu código bonito e elegante. O problema é que, talvez, bonito e elegante seja a minha percepção sobre meu próprio código. Talvez esse bonito e elegante traga problemas de manutenção no futuro e, como dito antes, problemas no software trazem problemas para o consumidor.

Motivação – Por que quero fazer isso?

Os porquês! É nessa hora que realmente percebemos se estamos pensando no produto e nos nossos consumidores, ou se estamos domando decisões aleatórias de design. Se ao me questionar sobre o porquê de uma decisão, eu responder algo como: “porque é legal”, “porque é bonito”, “porque é elegante” ou “porque Fulano usa e falou que é bom”, então talvez eu tenha perdido o foco e não esteja mais pensando no produto.

A motivação de uma decisão de design deve ser sempre, absolutamente sempre, agregar um valor ao produto.

Consequências – Os benefícios superam os malefícios?

Tendo claras as intenções e motivações para uma decisão de design, é preciso estudar as consequências dessa decisão. Sejam benéficas ou maléficas, elas existem e precisam ser conhecidas.

Por melhores que sejam as minhas intenções e justas as minhas motivações, será que os malefícios causados por essa decisão não superarão no futuro os benefícios que ela poderá vir a causar ao ser aplicada? E se os malefícios vierem a ser maiores no futuro, será que esses malefícios não irão corromper as motivações, por mais justas que elas pareçam ser agora?

Conclusão

Eu ainda não cheguei a uma definição conclusiva sobre design de software. É muito provável que eu venha a mudar novamente de ponto de vista num futuro. Mas também é provável que mesmo que eu mude de ponto de vista num futuro, eu mantenha meu entendimento sobre os três elementos de alto nível de design e continue me vendo como fornecedor de um produto que será consumido. E é provável que eu mantenha esse entendimento porque quando eu penso no meu código como um produto, eu procuro produto melhor e que entregue mais valor para meu cliente. Me percebo tomando decisões mais responsáveis, mais maduras e que têm causado menos problemas para meus consumidores.