Antes de escolher uma ferramenta, precisamos compreender quem enfrenta o problema, qual resultado é esperado e quais limites existem. Esses limites são chamados de restrições: tempo, custo, materiais disponíveis, segurança e impacto ambiental são alguns exemplos.

Uma ideia só se transforma em solução quando pode ser testada. O teste compara o resultado obtido com a necessidade inicial. Se uma garrafa térmica conserva a temperatura, mas é pesada demais para transportar, ela resolve uma parte do problema e cria outra condição a ser melhorada.

1. Observar a situação e reunir informações.
2. Definir a necessidade e os critérios de sucesso.
3. Criar, testar e comparar possíveis soluções.
4. Usar o resultado do teste para aperfeiçoar a escolha.

Soluções diferentes podem atender à mesma necessidade, mas não com os mesmos efeitos. Para escolher entre elas, usamos critérios de sucesso mensuráveis: rapidez, facilidade de uso, segurança, custo, durabilidade ou acessibilidade. Também observamos consequências não planejadas. Uma solução eficiente para uma pessoa pode criar dificuldade para outra; por isso, avaliar tecnologia inclui escutar usuários, comparar resultados e considerar impactos sociais e ambientais.

A entrada não chega ao computador com um significado pronto. Um sensor, teclado ou microfone converte um acontecimento em dados que o sistema consegue representar. Durante o processamento, regras combinam esses dados com informações já armazenadas para decidir qual saída produzir.

Alguns sistemas também possuem retroalimentação: parte da saída volta como uma nova entrada. Um ar-condicionado mede a temperatura, resfria o ambiente e mede novamente. Assim, ele ajusta seu funcionamento em vez de executar uma única ação.

• Dado: registro que pode ser armazenado e processado.
• Regra: instrução usada para transformar ou comparar dados.
• Resposta: efeito observável produzido pelo sistema.

Entrada, processamento e saída não explicam tudo sozinhos. Muitos sistemas também armazenam dados para usos futuros: um editor guarda um texto; um jogo registra a pontuação; uma biblioteca mantém o histórico de empréstimos. É importante distinguir dado de informação. “28” é um dado isolado; “28 °C na sala às 14 horas” tem contexto e pode apoiar uma decisão. A qualidade da saída depende de dados corretos, suficientes e adequados ao objetivo.

Uma instrução precisa usar ações que o executor conhece. Para um robô que só entende avançar, girar e parar, o comando “vá até a porta” ainda precisa ser decomposto. O conjunto de ações disponíveis forma o vocabulário do algoritmo.

Também é necessário declarar as condições iniciais e saber quando o processo termina. Fazer um teste de mesa significa executar mentalmente cada passo, registrar o que mudou e verificar se o resultado atende ao objetivo antes de entregar o algoritmo a uma máquina.

• Cada passo pode ser executado sem adivinhação?
• A sequência funciona para casos diferentes, não apenas para um exemplo?
• Existe uma condição clara para encerrar a execução?

Algoritmos precisam considerar pré-condições: fatos que devem ser verdadeiros antes do primeiro passo. “Abra o arquivo” pressupõe que o arquivo existe e que o executor sabe onde encontrá-lo. Também podem existir pós-condições, que descrevem o resultado esperado ao terminar. Escrever essas condições ajuda a criar casos de teste, incluindo situações comuns e exceções, como faltar um material ou surgir uma entrada diferente da prevista.

O resultado de um comando depende do estado atual do sistema. O comando “apagar” produz efeitos diferentes se a luz estiver acesa ou já estiver apagada. Por isso, acompanhar apenas a lista de comandos não basta: precisamos observar o que muda depois de cada ação.

Uma tabela de rastreamento pode registrar o estado antes do comando, a ação executada e o estado depois dela. Essa técnica revela em qual passo o resultado começou a se afastar do esperado e torna a correção mais precisa.

1. Anote a situação inicial.
2. Execute apenas um comando.
3. Registre a mudança antes de continuar.
4. Compare o estado final com o resultado esperado.

Nem todo resultado inesperado vem de uma instrução errada. A entrada pode estar diferente do previsto, o executor pode não conhecer um comando ou o estado inicial pode ter sido registrado incorretamente. Para localizar a causa, reproduza o erro com o menor número possível de passos. Um caso pequeno reduz distrações e permite comparar com precisão o esperado e o observado.

Uma boa decomposição cria partes com responsabilidades claras. Cada parte precisa receber informações, realizar uma tarefa e entregar um resultado que outra parte consiga utilizar. Esse ponto de contato é chamado de interface.

Nem todas as subtarefas podem acontecer ao mesmo tempo. Em uma apresentação, pesquisar e criar ilustrações podem ocorrer em paralelo, mas a revisão final depende de ambas. Um mapa de dependências ajuda a organizar essa ordem e evita que uma equipe fique esperando informações que ainda não existem.

• Partes independentes podem ser resolvidas em paralelo.
• Partes dependentes precisam respeitar uma sequência.
• A integração verifica se as soluções menores formam uma solução completa.

Uma decomposição pode ser feita de maneiras diferentes. Podemos separar por etapas, por funções, por pessoas responsáveis ou por tipos de informação. A melhor divisão reduz dependências desnecessárias e facilita testes. Se uma parte for grande demais para explicar ou estimar, ela pode ser decomposta novamente. Se for pequena demais, coordenar muitas partes pode dar mais trabalho que resolvê-las.

Ao comparar exemplos, podemos separar o que permanece igual do que varia. A parte fixa define a estrutura do padrão; a parte variável permite adaptar essa estrutura a novos casos. Em “2, 4, 6, 8”, os valores mudam, mas a regra de acrescentar dois permanece.

Toda abstração tem um propósito. Um mapa rodoviário destaca estradas; um mapa climático destaca temperaturas. Nenhum deles mostra tudo. Portanto, simplificar não é apagar detalhes ao acaso, mas escolher quais informações ajudam a responder à pergunta atual.

• Padrão: relação que aparece em mais de um caso.
• Modelo: representação simplificada construída para um objetivo.
• Generalização: regra que explica exemplos conhecidos e pode prever novos casos.

Ao construir um modelo, nomeamos as partes variáveis. Em “saudação + nome”, a estrutura permanece e o nome pode mudar. Isso permite reutilizar a mesma solução sem copiar todos os passos. Porém, uma generalização precisa ser testada com exemplos variados e também com contraexemplos: casos parecidos que não obedecem à regra. Um único contraexemplo pode mostrar que a regra precisa ser refinada.

Uma pasta forma uma hierarquia: cada item possui um lugar e um caminho. Nomes como “trabalho-final-agora-vai” dependem da memória de quem os criou. Um padrão como “2026-07-pesquisa-v03” registra data, assunto e versão de maneira que outras pessoas também conseguem interpretar.

Sincronização não é a mesma coisa que cópia de segurança. Se um arquivo apagado for sincronizado, ele pode desaparecer de todos os dispositivos. Um backup mantém uma cópia separada que permite recuperar versões anteriores.

• Use poucas categorias, mas com significados claros.
• Mantenha o mesmo padrão de nomes em arquivos relacionados.
• Registre versões importantes e faça cópias de segurança.

Uma boa busca começa pela pergunta. Termos muito amplos produzem muitos resultados; termos específicos reduzem o conjunto. Aspas podem localizar uma expressão exata em vários mecanismos de busca, e palavras adicionais ajudam a indicar assunto, lugar ou período. Encontrar um arquivo ou uma página, porém, não garante que seja a versão correta ou uma fonte confiável. Organização e avaliação precisam trabalhar juntas.

Risco combina duas perguntas: qual é a chance de algo dar errado e qual seria o impacto? Publicar o horário em que uma casa fica vazia, por exemplo, parece apenas compartilhar uma rotina, mas pode revelar uma informação útil para alguém mal-intencionado.

Autenticação confirma quem está tentando entrar; autorização define o que essa pessoa pode fazer depois de entrar. Uma senha forte ajuda na autenticação, enquanto permissões de arquivos e aplicativos limitam o acesso. A verificação em duas etapas acrescenta uma camada caso a senha seja descoberta.

1. Pare antes de clicar ou responder com urgência.
2. Verifique remetente, endereço e contexto da mensagem.
3. Proteja dados pessoais e confirme pedidos por outro canal.
4. Peça ajuda a um adulto responsável quando houver dúvida.

A pegada digital é formada pelos registros deixados ao usar serviços, publicar conteúdos ou interagir com outras pessoas. Parte dela é intencional, como uma foto publicada; outra parte é produzida pelo funcionamento dos sistemas. Privacidade também envolve consentimento: ter acesso a uma imagem ou conversa não significa ter permissão para compartilhá-la. Se ocorrer um incidente, não esconda o problema: pare a ação, preserve informações úteis e procure um adulto responsável.

Uma animação interativa não segue apenas uma sequência do começo ao fim. Ela pode esperar um clique, uma tecla, uma mensagem ou o encontro entre personagens. Esse modelo é chamado de programação orientada a eventos: o evento escolhe qual roteiro será iniciado.

Dois roteiros podem estar ativos ao mesmo tempo. Enquanto um personagem se move, outro pode tocar um som ou verificar uma condição. Para coordená-los, mensagens funcionam como sinais: um roteiro transmite “fase concluída” e os demais que aguardam esse aviso começam suas ações.

• Evento: acontecimento que inicia uma ação.
• Roteiro: conjunto de blocos executado por um ator ou cenário.
• Mensagem: sinal usado para sincronizar partes do projeto.

No palco do Scratch, posições podem ser representadas por coordenadas: o eixo x indica deslocamento horizontal e o eixo y indica deslocamento vertical. Eventos podem iniciar roteiros ao mesmo tempo, o que chamamos de concorrência. Isso cria cenas ricas, mas também exige coordenação. Se dois roteiros tentarem controlar a mesma propriedade sem planejamento, o resultado pode variar. Mensagens e esperas bem escolhidas organizam a passagem entre cenas.

Um teste é mais útil quando possui uma entrada conhecida e um resultado esperado. A diferença entre o esperado e o observado oferece uma pista sobre o bug. Se várias coisas forem alteradas ao mesmo tempo, fica difícil descobrir qual mudança resolveu — ou criou — o problema.

Na depuração, formulamos uma hipótese, fazemos a menor alteração possível e testamos novamente. Depois da correção, repetimos testes que já funcionavam. Esse processo, chamado de teste de regressão, verifica se a solução de um erro não danificou outra parte do projeto.

1. Descreva o resultado esperado e o resultado observado.
2. Encontre o menor caso que ainda apresenta o erro.
3. Altere uma causa provável por vez.
4. Teste a correção e confirme que o restante continua funcionando.

Além do caminho esperado, teste situações próximas dos extremos permitidos, chamadas de casos-limite: valores muito pequenos ou grandes, teclas pressionadas rapidamente, personagem na borda e ações fora de ordem. Também teste entradas inválidas. O projeto deve ignorá-las, apresentar orientação ou responder de modo seguro. Antes de acrescentar efeitos, estabeleça critérios de conclusão, como iniciar corretamente, responder às entradas, terminar a rodada e permitir nova tentativa sem reiniciar tudo.