Nessas últimas semanas comecei a ler o livro “97 Things Every Software Architect Should Know” (“97 Coisas que todo arquiteto de software deve saber”). Achei interessante o título do livro, pois parecia ser o resumo de diversas dicas sobre comportamento, arquitetura, compromisso e análise de sistemas… E realmente este é o conteúdo do livro…

A obra reúne pequenos textos de diversos arquitetos de software de grande expressão no cenário de tecnologia mundial. Alguns dos profissionais que colaboraram com o conteúdo desta obra trabalham em empresas como: Google, ThoughtWorks, Oracle, InfoQ, Blue River Systems Group, Software Engineering Professionals Inc, entre outros.

O livro é bastante interessante para quem procura um resumo de experiências e lições aprendidas. Não necessariamente precisa-se ser arquiteto de software para ler esse conteúdo (mesmo porque eu não sou arquiteto de software =] ), o conteúdo não é voltado para tecnologia, e sim para a troca de experiências.

Seguem algumas dicas que achei interessantes, existem muitas outras, mas gostaria de inicialmente dar destaque a estas:

– Não coloque seus objetivos técnicos a frente dos requisitos do sistema: não utilize uma tecnologia sem que ela seja necessária. Não deixe que suas tendências tecnológicas direcionem os requisitos do software.

– A arquitetura da aplicação determina sua performance: Esta parece ser uma característica óbvia, mas para muitos não é. Muitas empresas investem no tunning de servidores como solução de ganho de performance, mas performance não é apenas isso! A performance esta diretamente atrelada no modo como seu software foi arquitetado e construído. Para obter ganhos de performance, antes de mais nada, reveja sua arquitetura e procure por pontos a serem melhorados.

– Entenda a necessidade dos requisitos: Procure entender a real necessidade pela qual os requisitos são necessários. Nem sempre o requisito desejado pelo cliente será aquele que melhor atenderá a sua necessidade. Questione, pergunte, julgue as escolhas dos usuários e procure entender sua real necessidade.

– Tudo um dia irá falhar: Hardware é falível, então adicionamos redundância. Software é falível, nós adicionamos monitoramento para nos contar quando a aplicação falha, mas este monitoramento é um software, e também é falível. Seres humanos cometem erros, por isso automatizamos processos e ações. Redes são feitas de hardware e software, redes são falíveis. Todo mecanismo que utilizamos para mitigar um tipo de erro adiciona novos modos de falhas. Então o que devemos fazer, se existe a certeza de erro em nossos sistemas? Devemos aceitar que falhas são inevitáveis, e assim construir em nossos sistemas reações para alguns tipos específicos de falhas, que controlem o erro e protejam o restante do sistema.

– Patologia de padrões: Design patterns são uma das mais valiosas ferramentas disponíveis na arquitetura de software. O uso de padrões favorece a criação de soluções fáceis de compartilhar e entender. Design patterns tornam-se um problema quando nós tentamos utilizá-los em todo problema que encaramos. Não podemos deixar que nossa admiração por design patterns torne os problemas de nosso projeto mais complicados do que o necessário. Design patterns não são mágicos, e não necessariamente qualificam sua solução como ótima.

– Se existe apenas uma solução, então peça uma segunda opinião: A arquitetura de software objetiva encontrar a melhor solução para um dado problema, é muito difícil conseguir cobrir todos os requisitos e restrições com a primeira solução que vem a mente. Se você possui apenas uma solução em mente, e não possui experiência sobre o domínio do problema, então é preciso pedir ajuda a alguém mais experiente.

Por
Fernando Henrique Inocêncio Borba Ferreira.