Software Development

O Que É uma Closure em JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter executa uma vez, retorna uma função, e aí termina: seu stack frame não existe mais. Ainda assim, cada chamada a counter() continua lendo e atualizando count, uma variável declarada dentro de uma função que já terminou. count não volta para 0, e não é copiada. É a mesma variável, ainda viva, três chamadas depois. ...

Um teste escrito depois do código tende a verificar o que o código faz, não o que ele deveria fazer. O desenvolvimento guiado por testes (TDD) resolve isso invertendo a ordem: você escreve o teste, vê ele falhar, e então escreve o menor código possível que o faz passar. Como o teste existe antes do código que ele verifica, ele não pode confirmar silenciosamente o que quer que o código retorne. Kent Beck formalizou esse ciclo como red, green, refactor em seu livro de 2002 Test-Driven Development: By Example. O nome pegou. ...

Desconecte um usuário de uma aplicação baseada em sessão e o servidor o esquece na próxima requisição. Desconecte-o de uma aplicação baseada em JWT e, a menos que você tenha construído um mecanismo extra para isso, o token que ele está carregando continua válido até expirar. Essa diferença é a verdadeira decisão por trás de “JWT vs sessão”. O resto decorre dela. O que uma sessão realmente guarda Uma sessão mantém o estado do usuário no servidor e passa ao navegador apenas uma chave de consulta. ...

Envolva uma chamada fetch() em um try/catch, acerte um endpoint que responde com 404, e o bloco catch nunca executa. A promise se resolve. res.json() analisa qualquer corpo que o servidor tenha devolvido, muitas vezes um payload de erro como {"error": "user not found"}, e o resto da função trata isso como o registro que pediu. Nenhuma exceção, nenhum aviso no console. O dado errado segue adiante até algo mais quebrar por causa dele. ...

Uma função que chama a si mesma tem uma profundidade máxima, e ela é menor do que a maioria imagina: 1.000 chamadas no CPython por padrão, algo entre 10.000 e 15.000 no Node e nos motores de navegador, dependendo de quanto cada frame ocupa. Passar desse limite não deixa o programa mais lento. Ele trava. O Python lança RecursionError: maximum recursion depth exceeded; o JavaScript lança RangeError: Maximum call stack size exceeded. ...

Você está montando um dashboard: cabeçalho, barra lateral, área de conteúdo principal, rodapé. Você recorre ao Flexbox porque é a ferramenta de layout que conhece, e vinte minutos depois tem três containers display: flex aninhados, uma barra lateral que não mantém a largura sem um número mágico, e um rodapé que flutua na metade da página quando o conteúdo é curto. Nada disso é um bug do Flexbox. Você está usando uma ferramenta unidimensional para um problema bidimensional. ...

Coloque go antes de uma chamada de função e essa função passa a rodar em concorrência com o resto do programa, gerenciada pelo runtime do Go em vez do sistema operacional. Iniciar uma é a parte fácil. A parte difícil é fazer duas goroutines se passarem um resultado sem pisar no estado uma da outra, e é esse o trabalho dos channels. O que é uma goroutine? Uma goroutine é uma função que roda de forma independente da que a iniciou, gerenciada pelo runtime do Go e não pelo sistema operacional. Uma thread do sistema operacional reserva um megabyte ou mais de stack e custa ao kernel tempo real para ser escalonada. Uma goroutine começa com uma stack de cerca de 2KB que cresce conforme necessário, e o runtime multiplexa muitas goroutines em um punhado de threads do sistema operacional. Iniciar milhares delas é normal. ...

Uma classe que salva um usuário no banco de dados, manda um e-mail de boas-vindas e formata um recibo precisa de uma única mudança para quebrar duas funcionalidades com as quais não tem nada a ver. Você toca no template do e-mail e arrisca a escrita no banco. Você toca no layout do recibo e arrisca o e-mail. SOLID são cinco regras que atacam esse tipo de emaranhado a partir de ângulos diferentes, e compartilham uma ideia: uma classe deve mudar por um único motivo, e o resto do código deve depender do que algo promete fazer, não de como faz isso. ...

Duas requisições chegam no mesmo endpoint “sacar 100€” com meio milissegundo de diferença. A conta tem 150€. As duas requisições leem esse saldo, as duas veem fundos suficientes, as duas aprovam, as duas subtraem 100€. A conta termina em -50€, e nenhum trecho do código deveria ter permitido isso. Isso é uma race condition: o resultado depende de qual operação termina primeiro, e “primeiro” nunca foi algo que o código decidiu. ...

Um campo de busca que dispara uma requisição a cada tecla envia cinco requisições para “redis”, e quatro chegam desatualizadas antes de a resposta voltar. Um handler de scroll que recalcula o layout roda centenas de vezes por segundo e deixa a página travando. O mesmo problema nos dois casos: o evento do DOM dispara muito mais vezes do que o handler precisa rodar. Debounce e throttle resolvem isso de duas formas diferentes. ...