Sempre que uma pergunta técnica ou sobre system design, ou até mesmo arquitetura é respondida com “Depende!”, há quem se questione se realmente estamos trabalhando com exatas. Afinal, se estamos no mundo das exatas, porque tudo depende?

O que de fato faz os melhores profissionais responderem essas perguntas com um simples e singelo “Depende!”. Será que depende mesmo? Se depende, depende do quê?

Quando começamos a programar somos apresentados às variáveis. Já sabíamos desde as aulas de matemática, que variáveis diferentes tendem a produzir resultados diferentes. Isso é mais que óbvio. Mas quando começamos a construir software percebemos esse fenômeno de uma forma mais ampla. Não são apenas cálculos que possuem seus resultados alterados apenas. Uma variável que expresse um diretório, ou uma url, ou uma connectionstring produz um contexto diferente de execução de sua aplicação.

O ponto que quero ressaltar é que quando pensamos nessas variáveis técnicas, como connectionstrings, configurações, números, textos etc, estamos afundados nas variáveis do sistema. E simplesmente isso não é tudo.

Mas o fato é que sempre que uma pergunta sobre System Design ou Arquitetura é respondida com “Depende”, o que queremos dizer é que existem variáveis importantes que não estão expostas, não está claro ainda, sob qual contexto estamos falando, e acredite. Boa parte das vezes vai muito além do problema que você quer resolver tecnicamente.

---

Dica de leitura complementar

• Como definir a Arquitetura de um Software
• Comprometa-se a tomar a melhor decisão
• Eu tentei, tentei muito e falhei
• Roadmap de Arquitetura – Um exemplo real

Todos são posts que tocam no assunto “decisões técnicas”, eles expressam cenários e forma de pensar aplicada ao dia-a-dia.

---

O PROBLEMA não é a única variável, e talvez sequer seja a mais significativa

O PROBLEMA não é a única variável importante para se definir uma arquitetura, uma análise ou mesmo determinar um caminho a ser seguido.

O PROBLEMA é a variável que determina um dos critérios de aceite de uma solução.

O PROBLEMA é o motivador, a faísca que origina uma demanda.

Embora tenham ensinado que PROBLEM SOLVERS resolvem problemas, esqueceram de contar, que se sua busca acaba com a solução do problema é possível e até provável que pelo caminho você tenha CRIADO OUTROS PROBLEMAS.

E esse é o X da questão.

O que quero dizer e trazer com muita clareza é que não basta resolver o problema.

Resolver o problema é o critério mais básico para uma boa solução.

É o primeiro critério de aceite, e pasme, não é incomum vermos soluções sequer atendem esse requisito.

Mas quais variáveis são importantes?

Exemplo 1: Exportação para Excel

Por exemplo: Suponhamos que você tenha uma grid, o problema a ser resolvido é adicionar a funcionalidade de exportar os dados dessa grid para o Excel.

Pense em uma solução.

Parecem óbvios os passos a serem dados certo?

Não!

Você se perguntou se estamos falando de uma aplicação web, mobile ou desktop? Como você está aqui, provavelmente pensou em como resolver o problema com .NET e ASP.NET. Certo?!

Mas por acaso eu disse que se tratava de um projeto ASP.NET?

Claro que como você está aqui no gaGO.io, o contexto te direciona para .NET, e é óbvio que .NET estando no ponto central dos meus assuntos, faz todo sentido você presumir isso. Mas presumir que seja Desktop, Mobile ou Web, não.

Nota: Independente do problema, o contexto produz soluções diferentes. Se você considerar algo ainda mais específico como a arquitetura da aplicação em questão, talvez crie mecanismos para pegar uma lista genérica de objetos e converter em excel, ou dependendo de quão velha for essa arquitetura, pode ter de pensar em como converter datatables em excel.

O fluxo é sempre o mesmo, independente do contexto: Você precisa de dados, esses dados são processados, e como resultado produzimos um arquivo excel novo.

Dependendo do nível de maturidade, essa funcionalidade poderia estar embutida na GRID, e a partir de então, com uma única implementação, todas as grids do seu ERP conseguiriam gerar o arquivo excel a partir de sua própria visualização, com uma única implementação, trazendo potencial ilimitado de reuso.

O que quero dizer é que você pode pensar em algo pontual, em alterar uma tela, ou criar uma funcionalidade com alta capacidade de reaproveitamento, factível de ser adicionada em todo o sistema.

Quero trazer também a ideia de que, inevitavelmente, existe a possibilidade de estarmos falando de dispositivos e arquiteturas muito distintas.

Cada característica dessas muda completamente o contexto. Em sistemas onde o reaproveitamento é pouco pensado, só te resta implementar na própria tela. Onde há maior apego ao reaproveitamento, essa mesma implementação pode servir a todo o sistema.

Isso se traduz em potencializar seu trabalho, seu esforço e trazer muito mais benefícios, bastando ter um olhar mais estratégico.

Exemplo 2: O SPA

Imagine que você é um dev .NET full stack, e já no final das decisões, chegou-se à conclusão de que deveria criar um SPA.

Afinal, Angular ou React?

Se o time que for escrever a UI for prioritariamente .NET, com expertise principalmente em .NET, angular é a melhor escolha. Já se você tem um time de UI, um time separadinho especialista em front para lidar com a UI, React tende a ser a melhor escolha.

Mas se seu time for composto apenas por profissionais de Delphi, a escolha de adotar um SPA será um problema.

Note que aqui, nesse contexto, podemos chegar a contestar o problema em si. Nesse contexto, a variável mais importante são as pessoas, e seus skills.

Claro que você pode pensar: ah, formamos nossos devs então, e contratamos outros para compor um time com experiência mista, de forma que a passagem de conhecimento aconteça.

Sim claro, mas note, aqui parte da solução envolve Contratação e Formação e não apenas criar um SPA.

Até que ponto O PROBLEMA importa? Podemos desconsiderar O PROBLEMA em si?

Nunca. O problema é sempre relevante. O problema é o ponto de partida para a solução, ele é o guia, como disse no início, O PROBLEMA é o cenário de aceite de toda solução.

Então, com o que devemos nos preocupar?

1) A resolução do problema.

2) Buscar a melhor solução, entre várias, de forma a não ferir outros objetivos e outras premissas de um projeto, arquitetura ou estratégia.

Se a estratégia para o projeto é de alto reaproveitamento, fazer aquela implementação de excel, somente na tela A, B ou C vai contra a premissa de reaproveitamento.

Nesse caso, devemos expor isso para o arquiteto, líder técnico ou quem quer que responda sobre a arquitetura e estratégia da solução.

Isso pode significar que você precise de mais tempo, isso pode significar que alguém dirá para fazer somente naquela tela. O que importa é que sempre que você vá ferir a estratégia, alguém responsável por essa estratégia precisa, necessariamente, tomar conhecimento.

Abaixo deixo um print de uma ferramenta chamada 5W2H. É um framework baseado em 7 perguntas, que se respondidas, vão dar total clareza sobre o que deve ser feito, como deve ser feito, onde deve ser feito, por quem deve ser feito, quando, a qual custo ou impacto financeiro.

Uma vez que você produziu o 5w2h, é hora de analisar as respostas e entender se alguma delas é incompatível com a estratégia do projeto.

What, mostrará se a proposta da solução afeta algum requisito não funcional, alguma estratégia.

Why, mostrará o motivo daquela demanda. Trará clareza sobre porque estamos fazendo aquilo. E muitas vezes conseguimos contrastar O que faremos, com o porquê original. É mais uma forma de validar o que faremos.

Where determinará onde você deve realizar a tarefa, no nosso caso, será centralizado no componente da grid ou simplesmente na tela em que ocorreu a solicitação original?

When determinará se você já pode começar, já tem tudo pronto para dar prosseguimento ou é melhor adiar. Ou ainda será que é melhor antecipar algum assunto para criar o alicerce para que essa tarefa possa ser realizada no futuro?

Who determinará quem fará. É uma tarefa exclusiva para um senior, para um time inteiro. Será que essa tarefa é estratégica e vale a pena ter mais de um desenvolvedor realizando-a para que, com apoio, você consiga disseminar a cultura estratégica no time?

How deteminará como a tarefa será realizada.

E How much determinará 2 aspectos: quanto custa sua realização e qual o benefício com sua execução.

Uma vez de posse de todas essas informações, é hora de validar se a solução proposta atende ou não atende o requisito primário, resolver o problema. E se também não quebra os objetivos secundários: cada projeto, equipe, empresa tem os seus.

É sobre fazer a coisa certa

O mais importante é entender que muitas vezes precisamos fazer a coisa certa, em vez de fazer a coisa mais fácil.

Estar certo, não depende apenas de resolver o problema, envolve respeitar as premissas da cultura do projeto, equipe, empresa. Envolve evitar ao máximo gambiarras, e soluções não ortodoxas.

Mas esse é um assunto para outro post.

Se você curtiu esse post, compartilhe!

E se quiser, comente!