Dia da Programação, Dev em <T>, Patterns e Sapir-Whorf
6 min6 minutos de leitura
6 min6 minutos de leitura
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.
Autor(a)
Alexandre Aquiles
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
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.
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.
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:
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!
