Prefácio

Os especialistas da indústria aqui no Medium e em outros lugares gostam de usar termos sofisticados - quero dizer técnicos - para aumentar a importância de seus artigos e induzi-lo a pensar que o que eles estão dizendo é de alguma forma mais verdadeiro. Se você seguir as definições desses termos nos livros didáticos, provavelmente aceitará uma ideia errada e passará a maior parte de sua carreira trabalhando mais e não de maneira mais inteligente. Este dicionário resumido do programador oferece traduções reais desses termos para que você possa obter uma interpretação mais precisa dos artigos, palestras e vídeos populares.

As definições dadas neste dicionário podem diferir das da Wikipedia, mas tenha certeza de que são representações autorizadas do uso dos termos no mundo real... em sua maior parte.

Definições

solução — Quando eu o executo no meu computador, ele quase não quebra

teste - Quando o computador o executa no meu computador, ele geralmente não quebra

TDD (tear-driven development, também conhecido como test-driven development) — Quando o computador roda no meu computador, ele quebra, então eu sei que ainda não fiz a solução

BDD (behavior-driven development) — Não gostei do que os outros chamavam de TDD, então criei um nome melhor

test-first — não gostei do que os outros chamavam de TDD, então criei um nome melhor para eles

SOLID (desenvolvedor esnobe orientado a objetos e desenvolvedor enfurecido) — Sou muito mais esperto do que você, você nem é um desenvolvedor de verdade

digitação estática - escrevo o que é algo para não ter que lembrar

encapsulamento — colei duas coisas juntas para que sejam como uma coisa só e não possam ser separadas

moderno — A maioria das pessoas ainda usa, mas não meu avô

performant — Quando executo na minha máquina, não parece lento

memória eficiente — Quando eu o executo no meu computador, não recebo erros de falta de memória

uso intensivo de recursos — Lento e/ou fica sem memória

planejamento — Sentamos e marcamos uma data para podermos voltar ao trabalho

estimativa — eu observo a quantidade de trabalho e faço um palpite

padrão de design — Isso funcionou para mim antes

arquitetura — Isso funcionou para mim antes do XXL

algoritmo — fiz com que funcionasse com mais eficiência

estrutura de dados — tornei os dados mais fáceis de usar

convenção de nomenclatura - eu nomeio as coisas de uma certa maneira e todos os outros também deveriam

guia de estilo — acho que isso parece bonito, então todos devem codificar da mesma maneira

padrão de codificação — eu codifico de uma certa maneira e todos os outros deveriam fazê-lo dessa maneira

linter —Esta pequena ferramenta e plug-in IDE que me lembra de cada pequeno erro que cometo, porque é muito mais fácil do que aprender como fazê-lo corretamente

melhores práticas — É assim que eu faço e acho que todos deveriam

idempotente - posso chamá-lo várias vezes e não quebrou... ainda

testável — posso escrever testes para ele

modular — eu divido isso em vários arquivos e adiciono importações e exportações

herança — eu divido essa coisa em pedaços menores para poder juntá-los novamente com um pouco de supercola

composição — eu divido essa coisa em pedaços menores para poder juntá-los novamente com uma fita adesiva

reutilizável — copiei/colei isso em algum lugar e ainda funcionou, então dei um nome

abstração — eu copiei/colei isso em algum lugar e ainda funcionou, então dei um nome chique e adicionei alguns botões para que pareça foda

framework — copiei/colei isso em algum lugar e ainda funcionou, então fiz um pacote para ele, adicionei botões e botões, escrevi a documentação e dei uma palestra em um evento chique

legível - estou familiarizado com a aparência, então todos devem escrever dessa maneira

escalável - acho que isso pode funcionar para tarefas muito maiores, como é

sustentável —Funciona desde que ninguém toque nele, então não toque nele

simples — Cabe em uma linha

fácil - é a maneira de trabalhar que Joe, o desenvolvedor superstar, disse que era fácil, então pergunte a ele

sênior - ainda não estou aposentado

ordem superior - Isso se tornou muito complicado, então eu dividi mais ou menos ao meio

caching — salvei o resultado para não ter que refazer isso várias vezes

aync — É quando minha primeira linha é executada após a segunda

sincronizar — Normal

loop de eventos — sou um desenvolvedor sênior porque conheço o loop de eventos

recursão —É como um loop, mas funcional

aplicativo da web — É uma página da web, mas fiz com JavaScript

aplicativo da web progressivo — É como um marcador sofisticado com o ícone do menu Iniciar

SSR (renderização do lado do servidor) — Fiz o servidor funcionar como um navegador para poder usar o React no servidor, porque não conheço PHP, Python, NodeJS, Java, Go, C#…

CDN (rede de entrega de conteúdo) —escrevi muito código e demorou muito para carregar, então coloquei um servidor próximo ao usuário

ferramentas —Aplicativos reais têm ferramentas, aplicativos de brinquedo não

Scrum - empresas reais têm, empresas de brinquedos não

componente —sei que fazer páginas inteiras é ruim para aplicativos reais, então divido em pedaços menores

integração contínua — posso executar testes no GitLab para que meus colegas de equipe possam aprovar meu MR

entrega contínua — posso implantar meus aplicativos do GitLab para não precisar usar meu computador para isso

solicitação de mesclagem — mostro minhas alterações para meus colegas de equipe para que eu possa fazer uma pausa para o café enquanto espero que eles vejam

otimização — faço com que ele marque 80+ no Lighthouse

minificação — não sei como fazer isso funcionar com menos código, então encurto todas as palavras-chave para letras únicas e reduzo todos os espaços em branco esperando que o navegador não engasgue

vanilla —acho que é alguma tecnologia alienígena que não funciona na Terra

separação de interesses — nunca me preocupo, apenas faço meu trabalho e vou para casa

princípio da responsabilidade única — faço tudo caber em uma tela

regra do menor poder —Não funciona sem poder, então eu adiciono pelo menos muito poder

KISS (mantenha simples, estúpido) - eu sou inteligente, então não preciso disso, é apenas para pessoas estúpidas

DRY (não se repita) - Este é o princípio sagrado, aquele que separa homens de verdade de desenvolvedores medianos, se você tem linhas de código repetidas, você é estúpido e feio!

MVP (produto viável mínimo) — Um produto

deadline - O período de pico de estresse, não deve ser confundido com a data de conclusão do projeto

sprint — paro depois de duas semanas porque Joe, o Desenvolvedor Superstar, disse algo sobre parar idealmente depois de duas semanas

ágil — posso começar a codificar antes de ter um plano, porra!

class — É ruim porque é clichê, mas é bom para aplicativos corporativos

OOP (programação orientada a objetos) — É como você constrói aplicativos sérios

FP (programação funcional) — posso escrever aplicativos inteiros com apenas uma linha

versão principal — fiz mudanças maiores do que na versão secundária

versão secundária — fiz alterações menores do que na versão principal

dependency —Pacote essencial para criar aplicativos reais

Jira — Não posso fazer um trabalho de verdade se não logar no Jira… mas ainda odeio isso

refatoração — não gosto disso, então estou deixando mais bonito

acessibilidade — Existe alguma lei que diz que você precisa de fontes maiores para que pessoas cegas possam ver melhor seu site, e você precisa usar atributos ARIA

responsivo — Funciona no meu iPhone e MacBook Pro

marcação semântica — eu sei que <header>vai na parte superior e <footer>vai na parte inferior

classe utilitária — posso codificar CSS em meu arquivo HTML porque meus usuários não precisam de armazenamento em cache e sou bom com edição de vários cursores, e é o único caso em que posso legitimamente quebrar o DRY, embora seja um princípio sagrado

Apêndice A

Se você realmente deseja aprender o que esses termos significam, tente Wikipedia, MDN e lugares semelhantes.

Apêndice B

Em uma nota mais séria, deixe-me dizer algo que é realmente verdade. Como desenvolvedor autodidata, e especialmente como noob, costumava ter um certo respeito temeroso pelas pessoas que usavam esses termos. Ao longo da minha carreira, aprendi que 9,5 em cada 10 pessoas que os usam não sabem o que esses termos realmente significam, e hoje até os novatos os usam. Portanto, não os leve muito a sério. Leve-os tão a sério quanto este dicionário. Você pode codificar sem saber o verdadeiro significado de mais de cinco dos termos nesta página e fazer o trabalho melhor do que muitas pessoas que os usam casualmente.