Então é hora de remodelar todo o projeto, partindo de uma nova arquitetura.

A nova arquitetura tem sob seus ombros muita responsabilidade. Principalmente a de conduzir o projeto à dias melhores. A partir da nova arquitetura, gerentes, arquitetos, desenvolvedores, testers e clientes, todos serão felizes cumprindo suas demandas.

Será mesmo?

E se eu te dissesse que o tal caos arquitetural, pode não ter nada a ver com a arquitetura em si?

E que, embora uma nova arquitetura seja um marco importante e uma chance de fazer diferente, ela pode não ser o suficiente. De tal forma que se não for dada a atenção para a forma de resolvemos problemas, a nova arquitetura fracassará “igual, só que diferente”.

Será que você já viu isso acontecer em algum lugar?

Todos buscam o sucesso, de formas diferentes

Ninguém acordada de manhã e pensa: — Como vou ferrar essa arquitetura e/ou projeto hoje!

Todos querem fazer o melhor para alcançar os objetivos de negócio.

Você já deve ter escutado a frase: “De boas intenções o inferno está cheio”.

Pois bem, aqui essa frase também se aplica.

Muitas vezes a afobação por atender demandas do cliente no menor prazo e custo, parecem ir de encontro aos anseios imediatos do cliente.

Boas são as chances de que estejamos trocando um benefício imediato, por um débito a ser pago no futuro.

Essa visão equivocada de que prazo e custo importam a qualquer custo, sempre, incondicionalmente, sabota qualquer projeto, qualquer arquitetura.

Esse é um mal conhecido e que já vi diante dos meus olhos em diversos momentos. Considerar que objetivos técnicos, não são objetivos de negócio, gera caos.

Objetivos técnicos são objetivos estratégicos de negócio

Então quando seu cliente quer que o projeto seja fácil de manter, seja escalável, esses são requisitos que não entregam funcionalidades. Entretanto, a cada nova feature, a cada nova evolução precisamos considerar esses aspectos para não comprometer esse objetivo.

Esses requisitos são chamados de requisitos não funcionais. Pois apesar de serem requisitos, eles não entregam funcionalidades em si, em vez disso, dão suporte às funcionalidades.

Requisitos não funcionais — Analogia com a medicina

Requisitos não funcionais se desdobram em protocolos que asseguram que esses requisitos sejam atendidos. São as recomendações (protocolos) que seguimos para cuidar de que o projeto continue atendendo esses requisitos. Neles encontramos estratégias para assegurar alguma característica importante para o projeto.

Esses protocolos podem tocar diretamente e afetar 100% do código que você escreve.

Vamos aos exemplos.

Abaixo trago 2 exemplos que juntos vão assegurar um único objetivo.

---

Exemplo: Sessão

Então quando o protocolo sobre Sessões do ASP.NET, é proibir seu uso, adotando uma abstração ou o acesso direto ao REDIS, estamos considerando alguns aspectos:

• O ciclo de vida da sessão prevê leitura obrigatória de toda a sessão no início do request
• O ciclo de vida da sessão prevê escrita obrigatória de toda a sessão no final do request.
• O acesso manual a chaves específicas do REDIS é mais otimizado do que obter toda a sessão a todo request.
• Há requests que precisam de menos dados que outros e outros que não precisam de dado algum.
• Cada operação saberá lidar com a parte que lhe cabe da sessão, sabendo a hora de lidar com leitura (sem escrita) e escrita, por demanda, sem operações desnecessárias.
• O uso centralizado do REDIS, permite que sua aplicação trabalha tanto em webgardem (várias instâncias em um mesmo servidor) quando em webfarms (vários servidores), de forma transparente, sem necessidade de refactoring.
• O uso de sessões no ASP.NET em cenários mais de uma instância da aplicação demandam algum tipo de State Server, podendo inclusive ser o próprio REDIS.
• Pela natureza genérica do provider de sessão, não é possível determinar se e qual estado da sessão foi alterado ou não, portanto ao fim da execução do request toda a sessão é enviada para o State Server.

O protocolo consiste apenas em negar o uso da session, dando um modelo mais eficiente em sua substituição, enquanto todo o resto no texto é argumento que sustenta a decisão.

Exemplo: Dados em variáveis estáticas

Outro protocolo define que não devemos usar propriedades estáticas que sejam voláteis. Trocamos essa abordagem pelo uso do REDIS novamente.

Objetivo

O objetivo desses protocolos é assegurar que em caso de necessidade, possamos subir uma segunda instância da aplicação, sem nos preocuparmos com refactoring.

Ambos atendem aos requisitos de escalabilidade.

Escalabilidade é a capacidade de sua aplicação escalar horizontalmente (com mais instâncias). É algo muito falado há anos, e essencial para muitas aplicações.

Há um paralelo bem interessante e podemos usar a medicina para explicar com uma analogia.

E se fosse um médico?

Da mesma forma que esperamos que um médico-cirurgião siga os protocolos clínicos e as medidas de higienização em uma cirurgia.

Nós não questionamos se ele usará ou não o protocolo médico!

O médico não nos dá a opção de não seguir o protocolo, e, em contrapartida, nós também pouco pensamos a respeito. Presumimos e partimos do princípio que seguirá o protocolo.

Tudo que negociarmos com o médico a respeito de tipo de cirurgia, duração, período de cicatrização, etc etc toda a negociação, seja ela qualquer, parte do pressuposto de que o médico seguirá um procololo seguro.

Com software, o cliente parte do mesmo princípio. (Ou deveria partir)

O cliente não tem noção de que a ausência de testes unitários, gera um risco alto de bugs. Ele simplesmente quer o mais rápido possível, com a menor quantidade de bugs possível. E dependendo do nível de interação com o detalhe das tarefas.

O cliente não sabe se nós vamos adotar session ou não, ele quer que um dado selecionado no Login influencie o resto do comportamento da aplição para aquele usuário naquela sessão.

E se olhamos para o cliente como alguém com o mesmo nível de clareza técnica que nós, estariamos em apuros.

Lembre-se de que a relação do seu cliente com você é muito parecida com a sua relação de uma pessoa com um médico.

Acho que assim tudo fica mais claro.

O cliente pode e, em geral, pedirá o que é contraditório para o bem da empresa, se for feito exatamente, milimetricamente, da forma como foi dita por ele.

É importante digerir e entender o que é o melhor para o projeto, com base em premissas de requisitos não funcionais. Essas premissas são nossos protocolos.

Solicitações possuem expectativas implícitas

Meu ponto, nessa parte 1 (primeiro post da série) é lembrar que requisitos não funcionais, são estratégicos.

Ao mesmo tempo quando abraçamos um requisito não funcional como essencial para o projeto, tudo que fazemos no projeto deve considerar todos os requisitos que não se perderam pelo caminho.

Há momentos em que uma solicitação entra em contradição com um desses requisitos. Nós devemos fazer essa avaliação e voltar com um feedback claro sobre isso, a decisão não é sua, é do cliente.

Se um requisito cai, é o cliente quem tem de aceitar que caia.

E você, enquanto não recebe um Ok para a queda do requisito, precisa assegurar que cada implementação nova considerará tal obrigação.

Continuamos no próximo post

Esse é um assunto complexo, que preciso dividir em partes para dar atenção a cada um dos assuntos que envolvem essa dinâmica.