Dia da Programação, Dev em <T>, Patterns e Sapir-Whorf

Nesse dia 12 de setembro de 2020, dia da programação, número 256 do ano, quero dar parabéns a todas as pessoas que desenvolvem software, são curiosas e gostam de enxergar outras disciplinas e a ciência. A Alura sempre comemora com uma home nova, homenageando a gente.

E eu quero aproveitar para aprofundar a discussão do Generalista versus Especialista falando de como Patterns podem influenciar na maneira como pensamos sobre software, nos ajudando a identificar problemas e a expandir nosso repertório soluções.

Patterns e linguagem

Nós, devs, somos resolvedores e resolvedoras de problemas. Com o passar da carreira, percebemos que alguns problemas acontecem repetidamente. Esses problemas comuns têm, em geral, soluções recorrentes.

Pessoas experientes coletaram esses problemas comuns e soluções recorrentes e os descreveram no que chamaram de Patterns.

Um Pattern tem:

um nome
o contexto e as “forças em jogo”
o problema que será resolvido
um molde de solução, que pode (e deve) ser adaptado
os Patterns relacionados e trade-offs (ou prós e contras)

Um Pattern pode ser usado para comunicar problemas e soluções com outras pessoas do nosso time.

A teia de problemas e soluções conectados forma uma linguagem: uma Pattern Language.

Há Pattern Languages para:

Design de Código, como os famosos Design Patterns (GoF)
Arquitetura de Software, como os Patterns of Enterprise Application Architecture de Martin Fowler ou a série Pattern Oriented Software Architecture
Integração de Sistemas, como os Enterprise Integration Patterns de Gregor Hohpe e Bobby Woolf
Microservices, como os Microservices Patterns de Chris Richardson
Cultura Organizacional, como os descritos no livro Fearless Change de Linda Rising e Mary Lynn

Há ainda diversos outros livros que foram influenciados por Patterns, mesmo que não se apresentem como Pattern Languages.

Sapir-Whorf e o desenvolvimento de software

“A linguagem determina o pensamento”. Essa é uma das interpretações do que é conhecido como hipótese de Sapir-Whorf. Em uma versão mais branda (e mais aceita por linguistas contemporâneos), a linguagem influencia o que percebemos e o que pensamos.

No artigo Sapir–Whorf, Linguagens de programação e Startups de tecnologia, Paulo Silveira, CEO do Grupo Alura, traz uma série de exemplos e referências de como o conhecimento sobre linguagens de programação de diferentes paradigmas destravam nossas capacidades e moldam a maneira como pensamos sobre nosso código.

Há outras áreas em que a linguagem influencia o desenvolvimento de software? Sim!

Segundo o Domain-Driven Design, a linguagem dos especialistas de negócio deve estar representada no código, o que é conhecido como Linguagem Ubíqua.

Outro exemplo são as Pattern Languages, que nos ajudam a expandir nosso vocabulário de problemas e soluções possíveis, moldando a maneira como pensamos sobre nosso software:

Como tratar erros em um sistema de Mensageria? Os Enterprise Integration Patterns trazem esse problema à tona e indicam uma solução: um Dead Letter Channel.
Quais as maneiras de implementar o pattern Service Registry, segundo os Microservice Patterns? Com Eureka ou Consul, cada serviço deve registrar-se ao iniciar. Já com Kubernetes, o próprio orquestrador é responsável por registrar os serviços.

Compreendendo código com Patterns

Ampliar nosso repertório por meio de Patterns nos ajuda a compreender trechos de código cada vez mais elaborados.

Por exemplo, o código a seguir usa o framework de integração Apache Camel, para enviar para uma fila de geração apenas os itens de um pedido que são ebooks, tentanto 3 vezes em caso de erro:

from("jms:topic:jms/TOPICO.LIVRARIA")
.log(LoggingLevel.INFO, "CAMEL: Recebendo MSG ${id}")
    .split().xpath("/pedido/itens/item").
.filter().xpath("/item/formato[text()='EBOOK']")
.to("jms:queue:jms/FILA.GERADOR_EBOOK");

errorHandler(deadLetterChannel("jms:queue:jms/DLQ")
.useOriginalMessage()
.maximumRedeliveries(3)
.redeliveryDelay(5000);

São utilizados os Entreprise Integration Patterns:

Dead Letter Channel, mencionado anteriormente
Splitter, para “fatiar” um pedido em vários itens
Message Filter, para manter apenas os itens que são ebooks

O curso da Alura de Apache Camel aborda esses e mais conceitos.

Confusões originadas na linguagem

Nem sempre a influência é positiva: ao falarmos sobre map, algumas pessoas podem pensar em uma Estrutura de Dados associativa, outras em Programação Funcional. E, para quem está começando na programação, é difícil não tentar associar à Geografia. A comunicação pode virar uma confusão!

Um outro problema surgido da linguagem é a tradução. Patterns são traduzidos como “Padrões”. Design Patterns como “Padrões de Projetos”. Mas a palavra “Padrão” em português pode ser a tradução de “Pattern”, de “Standard” e “Default”.

A acepção mais comum para “Padrão” no dicionário é “Norma” ou “Regra”, algo semelhante a “Standard”, em inglês. Pode ser um dos motivos porque, ao iniciarmos os estudos de Design Patterns, é comum pensarmos (de maneira errada) que são regras e devemos aplicar todo e qualquer Pattern a cada código que escrevemos.

Não à toa, costumo a usar o termo Moldes de Modelagem, para comunicar melhor a intenção original dos Design Patterns.

Dev<T> e polinização cruzada

Há cada vez mais liquidez nas carreiras de tecnologia. Um(a) Dev<T>, o/a profissional em T no mundo do desenvolvimento, é um(a) generalista que navega por várias áreas e, ao mesmo tempo, um(a) especialista que mergulha em um assunto específico.

Ter algum conhecimento sobre outras áreas nos auxilia a ter outras perspectivas sobre nosso próprio trabalho. O próprio movimento de Patterns em software é um exemplo da polinização cruzada de ideias.

Pattern Languages surgiram na Arquitetura e Urbanismo no fim da década de 1970. Essas ideias foram trazidas para o desenvolvimento de software no fim da década de 1980. Entre os pioneiros estava Ward Cunningham, criador do primeiro Wiki, que era um repositório de Patterns de software.

Pattern Languages e a sua carreira

Expandir o repertório de problemas e soluções por meio de Patterns pode ser interessante em vários momentos da carreira. Patterns ajudam:

iniciantes a zarparem, levantando âncora e aprendendo sobre os diferentes problemas que surgem ao desenvolver software.
alguém com conhecimento intermediário a navegar, usando Patterns como guias para a implementação de soluções.
experts a mergulharem, focando na relação entre os Patterns, nos trade-offs e até a coletar novos Patterns.

Na Alura, os mais de 1000 cursos podem ajudar você a zarpar e navegar pelas diferentes áreas da Tecnologia e as formações podem auxiliar você a focar, mergulhando em um assunto específico. Dev em <T>. O Scuba Dev!