Dicionário de TI para designers.

Aprender alguns termos técnicos falados no dia a dia vai ajudar você a se comunicar melhor com os times de engenharia de software, infraestrutura, DevOps e afins.

Sempre trabalhei muito perto de produtos tecnológicos liderando times de desenvolvedores, engenharia, infraestrutura e afins. Então, por estar acostumado, estes termos sempre fizeram sentido pra mim.

Agora que trabalho apenas com designers, percebi algo que nunca tinha me passado pela cabeça: boa parte do que é falado em uma reunião de engenharia não passa de uma sopa de letrinhas na cabeça dos meus amigos designers.

Só tive um pouco dessa noção no meu primeiro churrasco da empresa. Eu ali me entrosando com o grupo, falando dos projetos em que trabalhei antes e ouvindo um pouco de cada um, quando alguém falou algo do tipo “que legal que você tem conhecimento técnico, vai poder ajudar a gente a entender um pouco mais o que a galera de TI sempre fala nas reuniões!”.

Em uma das conversas do dia a dia, tivemos a ideia de criar um glossário com alguns dos termos mais usados nessas reuniões, e assim aumentar o vocabulário técnico do nosso time de designers.

A seguir você encontrará uma lista com dezenove termos utilizados nessas reuniões, como podem ser agrupados (palavras que fazem parte da mesma frente de trabalho, como infraestrutura, arquitetura de sistemas ou aplicações, código e etc.), algumas analogias, bem como possíveis contextos e frases que podem ser faladas utilizando esses termos.

Amigos designers: não fiquem nervosos por esta lista não possuir uma ordem “lógica de organização”

_______
BARRAMENTO

Grupo: Arquitetura
O barramento disponibiliza com maior facilidade os serviços do sistema para os usuários e outras aplicações, acelerando processos de integração.
Pense em uma barra que centraliza o envio de informações de sistemas/aplicações diferentes, que precisam se comunicar entre si.

De uma forma visual a diferença de ter um barramento facilitando o acesso às informações em um ambiente com muitas aplicações.

Sem barramento:

Com barramento:

_______
WEBHOOK

Grupo: Arquitetura
Webhook é, na teoria, uma forma de recebimento de informações quando um evento acontece. Webhook, na prática, é a forma de receber informações entre dois sistemas passivamente.

Analogia: Podemos dizer que um webhook é tipo um office boy muito bem treinado, e a instrução que ele segue à risca seria “Sempre que chegar algum documento nesta caixa, você leva até o lugar X. Não precisa esperar ordem de ninguém, quando chegar o documento, você corre lá para entregar.”

Contexto: Exemplo de e-commerce - Quando a Visa confirmar um pagamento e retornar isso para plataforma, automaticamente é enviada uma confirmação para o e-commerce e essa mensagem dispara outras mensagens (e-mail para o usuário, por exemplo).

_______
SPA (Single Page Application)

Grupo: Arquitetura
Um SPA é uma aplicação web que roda em uma única página, se assemelhando a um aplicativo desktop ou mobile. Outro ponto é “quase toda” a aplicação é executada no lado do usuário/navegador.
Ou seja, elimina quase por completo as requisições ao servidor, e isso melhora a performance.
Um bom exemplo é o Gmail do Google, ele é um SPA, a navegação na aplicação rola toda em uma única página e todo o conteúdo é carregado de uma vez ou obtido dinamicamente.

Pontos positivos: Melhora a resposta ao usuário e possibilita trazer mais interações na aplicação.

Pontos negativos: Curva de aprendizado pode ser meio complexa no início. SEO não é tão simples de resolver como em uma aplicação convencional. A performance pode ser um problema se mal otimizado.

_______
MICROSSERVIÇOS

Grupo: Arquitetura
Microsserviços se referem a um software dividido em pequenos softwares (micro-softwares) que têm responsabilidades reduzidas e são independentes.

Contexto: Imagine que você tem uma loja virtual com diversas funcionalidades: cadastro de clientes, gerência de estoque, pedidos, catálogo de produtos, entre outras coisas. Sem microsserviços, você não consegue mexer só no cadastro, por exemplo. Se quiser colocar algo novo do cadastro em produção, será obrigado a tirar todo o sistema do ar. Com microsserviços, isso não acontece, pois cada parte da aplicação trabalha de forma independente.

Uma ilustração que mostra, numa visão de esforço, a diferença entre gerenciamento de serviços e microsserviços.

_______
MVC (Model, View, Controller)

Grupo: Arquitetura
MVC é um padrão de arquitetura de software que separa sua aplicação em 3 camadas. A camada de interação do usuário (view), a camada de manipulação dos dados (model) e a camada de controle (controller).

Model: O que o usuário vai ver. Ela faz a leitura, escrita e validação dos dados.

View: Como o usuário vai ver os dados que o model está mandando. É a camada de interação com o usuário.

Controller: É quem coordena a comunicação entre esses dois caras. Ilustrando como seria a comunicação entre estas três partes.

Analogia: Essa seria uma conversa entre View, Controller e Model:

View: "Fala, Controller! O usuário acabou de pedir para acessar o Facebook! Pega os dados de login dele aí."

Controller: "Blz. Já te mando a resposta. Aí model, meu parceiro, toma esses dados de login e verifica se ele loga."

Model: "Os dados são válidos. Mandando a resposta de login."

Controller: "Blz. View, o usuário informou os dados corretos. Vou mandar pra vc os dados dele, e você carrega a página de perfil."

View: "Vlw. Mostrando ao usuário em 3…2…1."

_______
DEPLOY

Grupo: Arquitetura
Em termos gerais, deploy significa colocar em posição.

Na prática, geralmente falamos de disponibilizar um sistema para uso, num ambiente de desenvolvimento, homologação ou em produção.
Imagine que você concluiu com os usuários todos os testes em homologação e, agora que está OK, já pode levar para produção. Ou seja, já pode fazer o deploy em produção.

Contexto: “Já testamos tudo em homologação e já podemos fazer o deploy em produção”.

_______
JENKINS

GRUPO: Arquitetura
O Jenkins é um servidor de automação de código aberto e gratuito escrito em Java. Ele ajuda a automatizar a parte não humana do processo de desenvolvimento de software, com integração contínua, e facilita os aspectos técnicos da entrega contínua.

Analogia: Imagine se não houvesse nenhum garçom no restaurante e todos os clientes fossem responsáveis por tudo que um garçom faz. Não seria uma bagunça?

Contexto: Imagine que estamos colocando muito código em produção e se for preciso, de forma humana, ler código todas as vezes antes do deploy, vamos precisar de umas 3 pessoas só para isso.
O Jenkins facilita toda essa validação de subida de codigo de forma automatizada, prevendo até erros durante a integração do código novo.

_______
HOMOLOG OU HOMOLOGAÇÃO

Grupo: Arquitetura
Ambiente utilizado para homologar um produto ou serviço antes de ser colocado em produção.
É um ambiente para testes e, como todo processo de testes, tem que refletir o mundo real (maioria das vezes não reflete).
Grandes corporações (normalmente quando são reguladas por algum órgão) são cobradas para ter um ambiente confiável de homologação.

Contexto: Como seria um dialogo entre dois desenvolvedores:

DEV Júnior: "Vamos já colocar isso no ar?!"

DEV Sênior: "Cara, ainda não testamos alguns cenários. Sobe em homolog primeiro pra gente testar."

_______
CDN

Grupo: Arquitetura
CDN é abreviação de Content Delivery Network (ou Rede de Distribuição de Conteúdo). É uma rede de servidores (pontos de presença) que armazenam réplicas do conteúdo de outros sites na memória (cache) e depois os entrega aos visitantes, baseando-se na localização geográfica para conectá-los ao servidor mais próximo e mais rápido.

Contexto: Imagine o CDN como se fosse uma franquia que vende/entrega o mesmo que a “matriz”, porém está mais perto de você.

Analogia: Podemos dizer que as franquias do McDonald’s são CDNs e possibilitam a todas as pessoas fora dos EUA acessar o restaurante.
Já pensou ter que ir até os EUA só para comer no McDonald’s?

Exemplo de uso: A Globo.com colocou CDNs no nordeste para que as conexões não precisassem ir até o Rio de Janeiro, reduzindo alguns milissegundos de tempo de resposta.

_______
BRANCH

Grupo: Arquitetura
Fazer uma cópia/espelho do código-fonte de uma aplicação web para um lugar que “só você” visualize.

Analogia: Imagine, na escola, aquela apresentação do trabalho feito em grupo. Se já estiver pronto, você vai querer fazer algum experimento e correr o risco de pôr tudo a perder ou vai fazer uma cópia só para você e implementar estes experimentos na sua cópia/branch?

Possível uso do termo: "Descobri um jeito de fazer isso mais rápido, vou aplicar primeiro na minha branch e se der certo podemos subir para o ambiente de homologação”.

_______
API

Grupo: Arquitetura
API significa Application Programming Interface, ou Interface de Programação para Aplicativos, cuja palavra-chave é interface.
API prove mecanismos/interfaces para comunicação entre dois pontos e nada além disso.

Contexto: Um grande provedor de APIs é o Google. A API do Google Tradutor fornece uma interface para outros softwares traduzirem e detectarem idiomas e etc. Para isso, basta conectar sua aplicação com a API deles e utilizar o tradutor. Outros exemplos do Google são Docs, Maps e Busca.

_______
UTM
Grupo: WEB Analytics
Os parâmetros UTM são “âncoras” que você pode unir às URLs de modo a fazer um rastreamento toda vez que houver algum clique nelas.
Os parâmetros informam para a ferramenta de analytics informações referentes à origem da visita a página.

Analogia: São informações do remetente + informações de envio que os Correios colocam em uma carta. Sem essas informações, o destinatário (Google) não consegue saber quem mandou, de qual correio mandou, em que dia, se foi Sedex etc.

Contexto: O uso de UTM, indicando para o Google Analytics que a partir dali serão enviados parâmetros:

Vamos usar como exemplo a url http://www.example.com/?utm_source=adsite&utm_medium=origem&utm_campaign=campanhadoanuncio&utm_term=palavra-chavedoanuncio

Quais são as UTMs que temos?
utm_source = adsite
utm_medium = origem
utm_campaign = campanhadoanucio
utm_term = palavra-chavedoanuncio

Segue a ferramenta do Google que te ajuda a gerar UTMs: https://ga-dev-tools.appspot.com/campaign-url-builder/

_______
LEGADO

Grupo: Infraestrutura/Aplicação
Sistemas, aplicações e infraestrutura antigas, que não atendem às atuais demandas tecnológicas.

Analogia: você vai construir uma casa sobre a estrutura de uma outra mais antiga. O engenheiro, ao fazer análise desse “legado”, fala que por ser construção antiga vão existir muitas restrições para construir algo por cima; além disso, se decidirem seguir em frente, o custo da obra será bem maior que o previsto.

Contexto: Agora imagine que, quando for construir uma nova aplicação, você se depara com uma aplicação antiga que é core do seu sistema. Esse “legado” tecnológico tem o mesmo efeito da construção: vai te limitar no desenvolvimento e também pode elevar muito o custo.

Conversa: “O que vocês construíram é bem bacana, mas devido ao nosso sistema legado não vamos conseguir responder sistemicamente na velocidade que vocês esperam”

_______
COMMITAR

Grupo: Aplicação
Gravar uma alteração de código-fonte/código principal em um sistema.

Analogia: Pense como se fosse um quadro branco com um texto original e alguém chegasse e escrevesse por cima do texto já existente, fizesse uma alteração, uma nova versão desse texto oficial.

Contexto: Brigas entre desenvolvedores: “quem foi que commitou esta merda de código aqui?!”

_______
GITHUB

Grupo: Aplicação
Git é um sistema de controle de versão de arquivos. Por meio dele é possível desenvolver projetos em que diversas pessoas podem contribuir simultaneamente, editando e criando novos arquivos e permitindo que estes existam sem o risco de suas alterações serem sobrescritas.

Contexto: Imagine a bagunça que seria ter 20 desenvolvedores, de forma simultânea, fazendo alterações e evoluindo um software. Quem controlaria esse monte de versões geradas o tempo inteiro?
O GitHub cria, armazena e controla todas as alterações feitas no código.

Desenvolvedor pergunta:
Desenvolvedor 1: “Qual é a versão da aplicação que está em produção?”
Desenvolvedor 2: "Algum outro responde: “Cara, não sei. Dá uma olhada lá no GitHub pra ver!”

_______
REFATORAR / REFATORAÇÃO

Grupo: Aplicação
Refatoração é o processo de alterar um software de maneira que não mude o seu comportamento externo e melhore a sua estrutura interna.

Analogia: Seria tipo você organizar toda a sua bolsa/mochila e jogar fora tudo o que não usa mais, mudar de lugar o que ficou para deixar o acesso mais fácil. Sua bolsa/mochila ficará bem mais leve e também você vai conseguir achar o que precisa de forma muito mais rápida. Concorda?

Lendas urbanas: “A cada 18 meses o Google faz refatoração de todos os códigos das suas aplicações”

Contexto: “Na correria, acho que vale refatorar para limpar, deixar mais elegante e ver se tem algum bug antes que dê pau em produção”

_______
COBOL

Grupo: Aplicação
A linguagem ainda é amplamente utilizada em sistemas legados armazenados em mainframes. Entretanto, devido à baixa popularidade e à aposentadoria dos programadores experientes, muitos dos sistemas estão sendo migrados para novas plataformas e reescritos em linguagens mais modernas.

Analogia: É uma linguagem antiga, que poucos desenvolvedores sabem…é tipo gostar de ouvir jogo de futebol pelo rádio AM.

Contexto: “Ih, rapaz. Temos como mexer nisso aí não, está em Cobol, e quem programou se aposentou há um tempo”.
O uso dessa linguagem é aplicado apenas para manter e eventualmente atualizar aplicações em produção (um possível legado). Hoje em dia, dificilmente uma aplicação nasce em Cobol.

_______
GET

Grupo: Aplicação
GET é um método que passa variáveis no cabeçalho da requisição (URL), normalmente utilizado em campanha de marketing (UTM) ou busca interna.

Analogia: Sabe o exemplo da carta que usamos para explicar o UTM? Vamos usar o mesmo. Alguém (pessoa ou aplicação) vai pegar (por isso o GET) as informações de origem que foram colocadas na carta e vai inserir tudo em um sistema de distribuição para posteriormente definir rota de envio, tipo de transporte que será usado e fazer análises.

Exemplo:
Termos usados na busca: liquidificador, preto, bivolt e copo de vidro.
Como será o GET destes termos em uma requisição: https://busca.magazineluiza.com.br/busca?q=liquidificador+preto+bivolt+copo+de+vidro

______
POST

Grupo: Aplicação
O POST também é um método de trafegar informações, mas, diferente do GET, envia os parâmetros no corpo da requisição e não é limitado a 255 caracteres.

Pegando o mesmo exemplo da carta (usada para GET e UTM), o POST seria o que está contido dentro do envelope, o conteúdo da carta em si, ou seja, não fica visível na URL.
______

Com o crescimento nas empresas da formação de squads, tivemos muitos ganhos na proximidade entre as duas principais frentes (UX e Engenharia), mas esse buraco na comunicação, muitas vezes, deixa as conversas triviais não tão fluidas, e isso não é difícil de resolver.

Ah, não fique com raiva do amiguinho da engenharia por ele falar esses termos todos que somente eles entendem, não é por mal. Eles são legais mesmo, eu juro!

OK, vai, uns gostam de usar muitos termos difíceis para mostrar conhecimento do assunto. Mas isso acontece em qualquer ambiente, profissional e pessoal.

A dica é: ninguém nasce sabendo e, se tiver dúvida, pergunte. Isso vai facilitar bastante o seu entendimento sobre o que está sendo falado no momento.

Espero que estes termos tenham ajudado você a entender mais do que é falado nas reuniões técnicas.

E você, tem dúvida em algum termo? Coloca aqui embaixo que no próximo post a gente responde.

Até mais!