Felipe Azevedo Bosi — Artigos

Engenharia de Requisitos Básica

contato@felipebosi.com — Wed, 14 Oct 2026 00:00:00 GMT

A engenharia de requisitos sempre foi uma área importante da construção de um software. Construir bem uma aplicação começa por saber o problema que estamos tentando corrigir e se vale realmente a pena construir ele.

Qualquer pessoa com alguma experiência com software já percebeu que o problema da lentidão não é um problema causado unicamente pelos engenheiros. Os principais responsáveis costuman ser especificações mal feitas, foco em falso problemas ou em correção/automação de fluxos que ninguém se interessa. A Engenharia de Requisitos vem dar foco nestas questões e discutir estes problemas antes que qualquer desenvolvedor possa encostar no código. Ela vai te ajudar a responder por que fazer algo, o que deve ser feito e para quem. As fases da engenharia de requisitos são:

1. Estudo de viabilidade

No estudo de viabilidade a gente quer saber se o software ou o recurso que estamos trabalhando vale ou não a pena ser construído. Isto passa por estudar se o que estamos propondo realmente ajuda o usuário e a empresa a atingir seus objetivos.

Para isso precisamos saber qual é o problema real a ser atacado. Ir a fundo em conversas e pesquisas para descobrir se o problema declarado pelo usuário é realmente o problema que ele quer que seja corrigido ou automatizado. Também calculamos os prazos e custos estimados. Por fim, calculamos também se não vale mais a pena pra empresa re-investir aquele dinheiro em outro lugar.

O software, para valer a pena ser construído, deve performar melhor financeiramente que um investimento de baixo ou médio risco, em termos de um software privado, e corrigir um problema real e não imaginário.

2. Elicitação de requisitos

Tendo definido que vale a pena construir o software, o próximo passo é ir mais a fundo e descobrir quais são os requisitos necessários para se fazer aquela aplicação existir. Para isto, precisamos saber quem são os usuários, quais são os fluxos esperados por estes e seus padrões esperados de qualidade.

Para quem já foi um pouco mais a fundo na Engenharia de Requisitos, é aqui que começamos a discutir requisitos funcionais e não-funcionais, termos já conhecidos por não serem bons para explicitar o que realmente queremos, mas que são os usuais de mercado.

Funcionais: são os requisitos que implementam a funcionalidade esperada pelo usuário. Como cadastrar um usuário; fazer uma compra; ver o status de algum item;
Não-funcionais: são requisitos que não implementam funcionalidades esperadas pelo usuário, mas são responsáveis por qualidade, segurança, performance ou por fazer a aplicação estar dentro de alguma lei ou regulação

Com essas definições, começamos a responder mais sobre em que contexto o software será inserido, quem serão esses usuários, o que ele deve fazer para sanar as necessidades tanto funcionais como as não funcionais.

Para ajudar a responder estas coisas, temos ferramentas como: criação de personas representando potenciais usuários; entrevistas; questionários; jornada do usuário; criação de protótipos; brainstorm. A escolha das ferramentas dependerá do time e do produto a ser desenvolvido.

3. Especificação de requisitos

Com os requisitos já elicitados, o próximo passo é especificar eles de modo a descrever os comportamentos e restrições esperadas para o software em si.

Nesta etapa estamos falando da criação de Casos de Uso, História de Usuário, Regra de Negócio, Critério de Aceitação e escrever os Requisitos não-funcionais. Cada um desses documentos ajudam a entender como algo vai ser implementado. Num mundo onde usamos cada vez mais ferramentas de edição de código assistidas por LLM, esses documentos ajudam a ferramenta a calcular melhor o caminho a ser seguido. Sendo que cada um desses documentos respondem a diferentes perguntas.

Caso de uso: como o usuário interage com o sistema passo-a-passo;
História de usuário: quem quer cada funcionalidade, o motivo e o que em detalhes;
Regra de negócio: qual diretriz de negócio deve ser seguida;
Critério de aceitação: define se uma funcionalidade foi implementada corretamente;
Requisitos não-funcionais: quais são as retrições legais, de qualidade, de segurança e de performance o app deve seguir.

Outras etapas e conclusões

As próximas etapas da Engenharia de Requisitos são a validação e priorização dos requisitos e a etapa de gerenciamento dos requisitos. Não entrarei nessas etapas hoje.

Das etapas já faladas acima, todas já eram importantes dentro do sistema pré-LLM de construção de software. As etapas buscavam mitigar erros e evitar que construamos um software que não resolve um problema real dos nossos usuários. Contudo, com ferramentas como Claude Code e Codex, elas se tornam ainda mais relevantes. Escrever código virou um processo automatizado e ter boas definições separam o sucesso da falha.

Como uma ferramenta de edição de código assistida por IA funciona

contato@felipebosi.com — Mon, 05 Oct 2026 00:00:00 GMT

Em uma das minhas últimas postagens no LinkedId, eu falei em como o caminho para criar seu próprio Claude Code no CodeCrafters é uma boa forma para se aprender e entender como essas ferramentas de edição de código assistida por IA funcionam. Aqui vou entrar mais a fundo e te explicar isto em mais detalhes.

Primeiro ponto é que toda LLM é uma ferramenta que recebe texto e retorna texto. Ela calcula qual é o retorno em texto mais provável, baseado nos dados com que ela foi treinada. Ou seja, LLMs não podem pensar ou ser proativas. Uma LLM é um modelo de linguagem que pega seu texto, joga em uma série de matrizes e calcula a resposta média. Não a melhor, nem a pior, a média.

Com isso, é provável que você esteja se perguntando como as LLMs conseguem procurar, ler e escrever no seu código. Ou como ela vai até o Linear ou Figma pegar informações. A resposta é que nenhuma delas faz isso. Quem faz isso é a ferramenta CLI ou a IDE que você usa.

CLIs como Claude Code e Codex, ou até mesmo IDEs como Cursor, oferecem à LLM o que eles chamam de tools (ou ferramentas em português). Tools são uma série de funcionalidades e descrições que falam para a LLM o que ela pode pedir para rodar dentro do seu ambiente. Se a LLM precisar ler um arquivo, ela pede pro CLI rodar a tool de READ (leitura). O CLI lê o arquivo pedido usando a ferramenta de leitura da própria linguagem de programação que a CLI foi criada ou usando Bash e manda o resultado para a LLM como uma mensagem comum, mas avisando que é uma mensagem de sistema e não de usuário.

É por esse motivo que modelos mais antigos não sabem como usar essas ferramentas. Usar tools é algo que elas tiveram que ser treinadas para entender. Sendo que cada tool nova é um código novo adicionado ao sistema de edição de código assistido por LLM, assim como qualquer código comum.

Tools como READ, WRITE e outras são só código normal. É por isso que ferramentas como RTK-ai funcionam tão bem. No caso do Claude Code, ele troca o uso da classe de leitura de arquivos do Node por grep, le, git e outras ferramentas que já existem no bash e que tem melhor performance.

Saber que tudo que as LLMs fazem é calcular texto baseado no que foram treinados é o que separa um dev que está começando a aprender a usar LLM pra quem já tem experiencia, sabe usar bem e conhece os limites da ferramenta

Dos artigos científicos até um app

contato@felipebosi.com — Wed, 09 Sep 2026 00:00:00 GMT

No meu tempo livre, tenho focado em um problema muito específico: como saber quanta cafeína eu consumi? Eu construí uma calculadora de cafeína para chás, uma para mate e agora estou construindo uma mistura de CLI / REST endpoint / pacote para ajudar outras pessoas a calcular o teor de cafeína de vários tipos de bebidas. No entanto, o que eu quero falar aqui não é sobre o app em si, mas de onde e como consegui os dados para ele.

Embora seja fácil encontrar dados informando quanta cafeína as bebidas comuns têm, na realidade isso pode variar bastante. O café muda de acordo com o tipo de grão que você está usando, sua origem e como você o prepara. O mate muda muito dependendo da espessura da moagem da erva. O chá muda com base no tipo de chá e se você o prepara no estilo ocidental, gongfu ou grandpa style.

O primeiro problema é que a única maneira de saber quanta cafeína estamos consumindo seria medir a cafeína na própria xícara ou cuia. Mas ainda podemos obter uma média melhor do que a que a maioria dos sites nos fornece. Como exemplo, você pode pesquisar no Google agora mesmo. Ele dirá que 50g de erva-mate tem de 150 a 260 mg de cafeína. No entanto, se você souber os detalhes exatos do seu mate, como se é uma erva nativa brasileira, os dados científicos nos mostram que, na realidade, o valor fica perto de 55 mg, enquanto um argentino chega perto de 290 mg. Com o limite máximo diário recomendado de 400 mg, podemos ver o quanto a média comum da internet pode causar erros, fazendo com que os usuários bebam mais ou menos da sua bebida do que gostariam.

O segundo problema é que, se você for checar os dados científicos, verá que a maioria das pesquisas é conduzida usando parâmetros muito específicos. Eles usam temperatura e gramaturas controladas, e o chá, mate ou café vem de uma área muito específica, ou até mesmo de uma marca ou fazenda em particular. Em resumo, os dados são tão detalhados e complexos que, para obter o valor real de cafeína, precisaríamos ir até o usuário e coletar uma amostra do que ele realmente está bebendo. Portanto, existe a necessidade de simplificar esses dados para que sejam úteis ao usuário, mas não a ponto de darmos a volta e nos tornarmos tão inúteis quanto as informações comuns da web. O que eu fiz foi selecionar as informações principais que podemos obter do usuário, como tipo de chá, gramas utilizadas e volume, e criar um algoritmo que calcula um valor médio de cafeína muito mais preciso com base nisso.

Para resolver todos esses problemas, tive que ler e coletar dados de diferentes artigos, selecionar os que faziam sentido e simplificá-los. Como você pode imaginar, nenhum algoritmo consegue calcular o valor exato para produtos naturais. Na arquitetura e urbanismo, nós inclusive usamos margens de segurança em materiais estruturais naturais para garantir a segurança. O mesmo vale para qualquer alimento ou bebida natural. Saber melhor o que você está consumindo pode ajudá-lo a tomar decisões melhores para sua saúde e a aproveitar sua cafeína de forma mais consciente.

Para quem quiser conferir, o repositório em que estou trabalhando é Caffeine Mega App

Rotina para devs: se preparando para um dia de trabalho

contato@felipebosi.com — Mon, 13 Jul 2026 00:00:00 GMT

Programar não é apenas o que você faz enquanto está na frente de um computador. É claro que um bom teclado, monitor e mouse tornarão seu trabalho mais confortável. Isto não tornará seu código melhor, mas certamente fará com que você se sinta melhor ao sentar-se diante do computador para programar. No entanto, estes são apenas objetos que você usa. Parte do que torna a programação mais agradável é o que você faz antes, durante e depois para aprimorar esta prática. Hoje, vou compartilhar como começo meu dia de uma forma que não apenas melhore meu desempenho, mas também me deixe mais feliz e confortável ao programar.

O dia anterior

Tudo começa com o fim do dia anterior. Reservo parte do final do meu expediente para organizar qualquer bagunça que tenha feito na minha mesa de trabalho e planejar o dia seguinte.

Como você pode ver na foto acima da minha mesa, há um bule de chá, uma pequena xícara, algumas canetas, alguns lápis mecânicos e um caderno. Esses são os itens que estou usando enquanto escrevo o primeiro rascunho deste post. Preciso organizá-los antes de encerrar o expediente, para que eu possa começar o dia seguinte com uma mesa limpa—uma ideia que compartilhei no meu post anterior, que você pode ler abaixo:

O próximo passo é definir no que vou trabalhar no dia seguinte. Qualquer tipo de lista de tarefas funciona aqui. Simplesmente anoto num caderno uma lista com as reuniões que preciso participar e com tarefas nas quais quero trabalhar no dia seguinte. Esta lista inclui tudo o que quero lembrar, desde tarefas de programação e trabalho até ideias em que desejo fazer, como projetos pessoais ou exercícios, Katas de programação ou yoga nidra.

Com isso, encerro o dia em um ambiente organizado e já sabendo o que farei no dia seguinte. Nenhum tempo é desperdiçado pensando no que eu poderia fazer ou lidando com a bagunça criada no dia anterior ao resolver um problema ou simplesmente ao comer em frente ao computador (por favor, evite isso se puder).

Antes de trabalhar

Como tudo relacionado ao planejamento foi feito no dia anterior, começo o dia sem preocupações. Já sei o que preciso fazer e quando. Assim, acordo, preparo um chá ou café e tomo meu café da manhã enquanto leio um livro, mangá ou quadrinho. Para mim, a leitura é uma forma de começar o dia devagar. Eu adoraria dizer que sou alguém totalmente focado no chá, no café e na comida, mas ainda não cheguei a esse nível.

Depois disso, saio para caminhar ou correr por meia hora. Prefiro fazer isso sem fones de ouvido ou celular. Essa é uma maneira de garantir que, pelo menos por mais meia hora, eu não usarei nenhuma tecnologia. Já passo o dia todo em frente a um computador e o utilizarei por mais de oito horas. Pelo menos durante as manhãs, fico livre dela.

Não que eu odeie tecnologia, videogames ou algo do tipo. Pelo contrário. Ter um tempo desconectado me faz valorizar ainda mais a tecnologia, melhora meu bem-estar e me reserva um momento para refletir sobre tudo o que fiz e tudo o que quero fazer ao longo do dia. É uma forma de meu cérebro reconhecer e decidir o que fará com cada informação que acumulei, seja lendo livros e artigos, lidando com o trabalho ou navegando em redes sociais.

Durante o trabalho

Durante o expediente, meu principal desafio é lidar com os níveis de energia. Tudo parece fácil quando estou trabalhando em alguma tarefa estimulante, mas sabemos que esta não é sempre a realidade. Também precisamos lidar com tarefas que são mais fáceis ou mais difíceis do que gostaríamos. Como programadores, temos que estudar, buscar soluções, reproduzir bugs aleatórios que só acontecem quando o usuário está em um navegador antigo e em uma conexão 3G ruim.

Normalmente, começo o dia de trabalho verificando mensagens, revisando PRs e revisando meu plano para o dia. Depois disso, começo a trabalhar em um ticket ou continuo o que deixei em aberto no dia anterior. Ao meio-dia, faço uma pausa para o almoço, que dura entre uma hora e uma hora e meia. Uso esse tempo para relaxar e recarregar as energias. Se tenho tempo, também aproveito meia hora para estudar algo novo ou programar algo não relacionado ao trabalho.

No período da tarde, tenho algumas reuniões. Às vezes, é apenas uma daily de 15 minutos, mas em outros dias há mais reuniões. Por volta das 18h ou 18h30, volto para a etapa de “O Dia Anterior” e planejo o próximo dia.

Níveis de energia

Precisamos de uma rotina para lidar com diferentes níveis de energia e com tarefas que exigem mais de nós. Isto varia de pessoa para pessoa, pois cada um tem oscilações de energia diferentes ao longo do dia. No meu caso, começo o dia devagar, mas rapidamente ganho ritmo com a ajuda da cafeína. Depois, desacelero por volta das 9h-9h30. Tomo mais café e me sinto energizado novamente pelo resto da manhã. Após o almoço posso ficar um pouco mais lento, mas por volta das 14h volto ao ritmo e me sinto produtivo até as 17h. Entre 17h e 20h, entro em uma fase mais lenta novamente, mas depois disso me sinto bem até às 22h-23h.

O modelo acima reflete o que acontece no meu dia típico. No entanto, é importante lembrar que tudo depende do que estamos fazendo. Se eu estou trabalhando em uma tarefa que realmente me interessa, posso perder a noção do tempo, porque me sinto motivado. O contrário também é verdadeiro: se sou forçado a trabalhar por muito tempo em algo tedioso, posso me sentir cansado em horários que normalmente não sentiria.

É essencial prestar atenção em si mesmo para entender seu nível de energia e identificar o que realmente te revigora. Para mim, ler um romance ou mangá, meditar, caminhar sem tecnologia por perto e assistir a animes são atividades que me energizam, enquanto navegar nas redes sociais e ler artigos na internet me deixam cansado. Também é importante ser honesto consigo mesmo. Da lista que mencionei, adoro navegar nas redes sociais vendo memes e rindo, e acho a meditação entediante, mas o impacto que essas atividades têm depois de realizadas é diferente da minha opinião sobre elas. Portanto, preste atenção não apenas em como você se sente durante a atividade, mas também em como se sente depois.

Tudo isto é um trabalho em progresso. Ainda tenho muito a aprender e testar. Portanto, se você tem uma rotina diferente, alguma dica para compartilhar ou algo que gostaria que eu explorasse mais a fundo, sinta-se à vontade para comentar abaixo.

Controle de qualidade e programação

contato@felipebosi.com — Thu, 09 Jul 2026 00:00:00 GMT

5S é um sistema de controle de qualidade bem conhecido. Ele foi desenvolvido no Japão após a Segunda Guerra Mundial para garantir que as empresas que o utilizassem entregassem os melhores produtos possíveis ao mesmo tempo em que cria um bom ambiente de trabalho.

Uma das empresas mais famosas que utilizam o sistema 5S é a Toyota. Pode-se dizer que o sistema é voltado para empresas de produto. No entanto, ele também aparece, de forma indireta, em livros sobre qualidade de código, como o famoso “Código Limpo”, e pode ajudar empresas de tecnologia a alcançar uma melhor entrega de código ao criar um sistema de trabalho baseado nos princípios do 5S.

Os cinco princípios

1. Seiri ou “Remover o que for desnecessário”

Seiri consiste em organizar todos os itens e remover qualquer coisa desnecessária, descartando-a. A ideia é criar um ambiente onde seja fácil encontrar o que for necessário, evitando distrações causadas por itens não utilizados e/ou lixo. Tudo o que não for necessário deve ser removido do ambiente de trabalho.

Com base nesse princípio, devemos remover qualquer código não utilizado da base. Isto inclui qualquer código comentado, comentários que não explicam nada e, claro, qualquer código que não faça nada ou que sequer seja chamado no restante do código. Se o código comentado for algo que você sabe que precisará no futuro, você pode criar uma nova branch e fazer um commit; usar boas mensagens de commit para saber onde encontrar a remoção; ou simplesmente anotar a hash do commit em um local acessível.

Do lado do seu computador, limpe seu editor. Você tem mais plugins do que precisa? Existem abas do navegador que podem ser fechadas, e-mails que podem ser apagados? Se você usa terminal, verifique seus dotfiles, aliases e pastas também. Sempre há algo que pode ser removido para manter seu computador mais organizado.

Este princípio também pode ser aplicado à sua mesa de trabalho. Remova qualquer item desnecessário que possa estar criando bagunça. Jogue fora ou guarde em um local acessível caso não seja algo que você use diariamente, mas que sabe que precisará no futuro. Mantenha sua mesa limpa, com apenas os itens necessários. Mas lembre-se de que apenas você pode decidir o que é necessário ou importante para você.

2. Seiton ou Ordenar

Este princípio tem como objetivo organizar tudo o que foi definido como necessário, mas que está fora de lugar. Isto cria um fluxo de trabalho mais eficiente, onde todos sabem onde encontrar qualquer item com base em um sistema categorizado.

No ambiente de código, a estrutura de pastas deve usar nomes fáceis de entender e cada trecho de código deve estar em uma pasta relacionada à sua categoria. O mesmo vale para nomes de arquivos, funções e classes. Isso significa evitar nomes com pouco significado, como utils e helpers, pois isso é equivalente a colocar código em um depósito genérico, onde qualquer coisa pode estar dentro.

Também é importante criar um sistema que ajude os desenvolvedores a categorizar seu código, seja ele MVC, MVVM, arquitetura hexagonal ou qualquer outro sistema. O ponto central é que ele facilite a organização e a localização do código. A ideia é reduzir as escolhas subjetivas, como “acho que seria bom colocar isso aqui”, e substituí-las por uma abordagem mais estruturada, como “estamos usando um sistema MVC e este é um controlador, então ele deve estar na pasta controllers”.

Nos meus projetos pessoais, prefiro arquiteturas recursivas, onde é possível separar melhor o que pertence a um subsistema, em vez de sempre usar pastas globais. Você pode imaginar isso como um projeto onde, ao entrar na pasta de uma funcionalidade específica, há um mini MVC dentro dela, e essa funcionalidade está dividida em módulos, cada um contendo mais mini MVCs.

No espaço digital, podemos aplicar esse princípio à organização de arquivos no computador ou até mesmo nas redes sociais. Você está misturando coisas diversas? Há fotos na sua pasta de vídeos? Você publicou algo na rede social errada? Este é o momento de recategorizar e colocar cada item no local adequado, garantindo que você possa encontrá-los facilmente no futuro.

No espaço físico, esse princípio pode ser usado para organizar os objetos que você decidiu manter no seu quarto ou escritório, mas que não precisam estar na sua mesa. O ideal é encontrar um local fixo para armazená-los, garantindo que você sempre saiba onde procurar determinado tipo de item. Isto evita que sua mesa volte a ficar bagunçada por conta de você querer manter as coisas por perto por medo de não encontrá-las depois.

Um bom princípio é manter os itens que você usa com mais frequência perto de você e visíveis, enquanto os itens menos usados podem ser armazenados em locais mais distantes e discretos. Por exemplo, se você gosta de escrever à mão, pode manter um único caderno e uma caneta próximos, enquanto os cadernos e canetas extras podem ficar guardados em uma caixa ou outro local de fácil acesso para quando precisar deles. Minhas categorias principais de organização são:

Visível na mesa: itens que uso todos os dias e que quero manter à vista, desde coisas básicas do computador até utensílios para chá, já que gosto de chá. Aqui também coloco alguns brinquedos que me lembram do que gosto e me ajudam a não levar tudo tão a sério.
Perto da mesa, mas não visível: coisas que uso com frequência, mas que não precisam estar à mostra, como brinquedos anti-estresse, remédios, papel e canetas.
Visível, mas não perto da mesa: itens que uso fora do trabalho ou que trago para a mesa temporariamente e depois guardo de volta. Aqui ficam livros, cadernos antigos, mais utensílios para chá, jogos e diferentes teclados.
Quase escondido: caixas organizadas, onde sei exatamente o que há dentro, mas que não ficam visíveis nem ao meu alcance imediato. Nelas guardo cadernos extras, documentos, mousepads reservas, peças de mouse e teclado para personalização ou reparo.

3. Seiso ou “Limpar”

Seiso trata da limpeza e manutenção do local de trabalho, equipamentos e máquinas. Isso ajuda a evitar acidentes, garantindo que tudo esteja no lugar e funcionando corretamente. Além disso, quem mantém suas ferramentas limpas consegue perceber mais facilmente quando algo não está funcionando como deveria.

No contexto de desenvolvimento, nossa responsabilidade é manter o código enxuto, limpo e organizado. Esse princípio significa que devemos sempre fazer o possível para limpar qualquer bagunça criada durante a busca por uma solução, a correção de um bug ou a implementação de uma nova funcionalidade. Certifique-se de que seu código está na melhor forma possível antes de abrir um pull request.

No entanto, conforme trabalhamos, nosso código tende a se tornar cada vez mais desorganizado. Pequenas mudanças que não deveriam ser feitas, escolhas ruins para resolver problemas urgentes – tudo isto são ações tomadas por um motivo específico, mas que exigem uma solução mais cuidadosa no futuro. Se não voltarmos para limpar estes problemas, o código pode se tornar difícil de ler e perder desempenho. O estado natural de qualquer código é se tornar “sujo” à medida que trabalhamos nele, e limpá-lo deve ser uma resposta natural para mantê-lo em boas condições. Esse processo já tem um nome bem conhecido entre os desenvolvedores: débito técnico.

Lidar com débito técnico é um desafio para todas as empresas. Devemos abrir um ticket para resolvê-lo no futuro? Apenas ir limpando conforme encontramos os problemas? A empresa deve reservar um tempo a cada sprint ou semana para ir resolvendo isto? Não há uma única resposta, pois isto depende de muitas variáveis. O princípio apenas reforça os benefícios de manter as coisas limpas, o que, no ambiente de software, significa menos bugs, menos problemas de segurança e menos comportamentos inesperados. Assim como as empresas precisam de equipes de limpeza para lidar com tarefas maiores enquanto os funcionários mantêm suas mesas organizadas, a limpeza do código deve ser um esforço conjunto da equipe ou da empresa.

Este princípio também se aplica às nossas mesas de trabalho. Agora que as organizamos, precisamos mantê-las limpas. Durante a limpeza, observe se algo precisa de reparo. Se você usa um teclado mecânico, verifique se todas as teclas estão funcionando corretamente, remova e limpe as keycaps. Confira seu mouse. Veja se precisa substituir ou recarregar suas canetas.

Voltando ao ambiente digital, analise também suas ferramentas digitais de trabalho. Existe algo que pode ser simplificado? Algum script que pode ser refatorado? Um plugin que pode ser substituído por outro mais eficiente? Manter as ferramentas organizadas e funcionais também faz parte desse processo de limpeza contínua.

4. Seiketsu ou “Padronizar”

Padronize qualquer processo, incluindo aqueles necessários para manter os três princípios anteriores. Aqui, também podemos incluir padrões para testes e definir qual paradigma de programação a empresa seguirá. Criar ou adotar padrões ajuda os programadores a escrever código mais rápido e manter a base de código de forma mais eficiente.

Gosto de pensar que padronizar é o equivalente, no mundo físico, à programar e automatizar nós mesmos. Padronizando, já sabemos o que fazer e não precisamos mais perder tempo pensando "onde devo colocar isso?". Em vez de se perguntar “onde essa foto deveria estar?”, você passa a pensar “é claro que a foto deve estar na pasta de fotos, categorizada por ano e local”.

No mundo do código, já temos ferramentas de lint que automatizam esta padronização para nós. Nesse caso, nem sequer precisamos conhecer os padrões com detalhes: o computador nos avisa ou até corrige automaticamente. Também podemos criar scripts que auxiliam na organização, como renomear arquivos e movê-los para as pastas corretas.

O mais importante aqui é transformar os processos anteriores em uma rotina. Você pode automatizar parte deles e agendar os demais para serem feitos diariamente, semanalmente ou mensalmente, de acordo com sua necessidade. A escolha do intervalo ideal fica a seu critério.

5. Shitsuke ou “Manter a disciplina”

O último princípio, mas não menos importante, está relacionado à autodisciplina e à sustentação dos outros quatro princípios. Algumas pessoas também traduzem esse princípio como “fazer sem precisar ser mandado”.

A primeira parte dele é ter a disciplina necessária para manter os outros quatro princípios. No entanto, ele também envolve estudo e treinamento contínuos, garantindo que estejamos sempre nos aprimorando. Outra parte essencial desse princípio é a troca de feedback, especialmente daqueles que estão na linha de frente do trabalho — no nosso caso, os desenvolvedores e designers.

Por isso, esse é o último princípio: ele fecha o ciclo. Ele nos lembra que precisamos voltar ao primeiro princípio e aplicá-lo de forma ainda melhor. Não se trata apenas de repetir os processos, mas de repeti-los de maneira consciente, prestando atenção a como podemos melhorá-los. O mais importante é continuar tentando e valorizar o fato de que, a cada volta, estaremos mais preparados para sermos melhores.

O que um código pode falar

contato@felipebosi.com — Wed, 08 Jul 2026 00:00:00 GMT

No meu último artigo, falei sobre alfabetização estendida e como entender código faz você enxergar o mundo de outra maneira. Lá, exploramos como a capacidade de ler e escrever código pode fazer com que você veja a tecnologia por uma perspectiva diferente. Assim como quando você aprende a ler e escrever, um novo mundo se abre para você. Código é uma linguagem e, como acontece com todas as linguagens, existem pessoas tentando levá-la ao limite. Esse limite pode ser técnico/lógico ou poético.

Dando continuidade às minhas leituras do livro Aesthetic Programming, de Soon e Cox, me deparei com a obra de arte em software Vocable Code, criada por Winnie Soon, uma das autoras do livro. Nessa obra, tanto o resultado do código quanto o próprio código são a arte final, onde o código funciona como uma espécie de contraponto ao que obtemos ao executá-lo. Abaixo, você pode ver o código completo, e iremos analisá-lo parte por parte, explorando o significado por trás de cada nome (o código também está disponível no Gitlab):

O código acima é um código JavaScript feito para rodar usando p5js, uma biblioteca cujo foco é ajudar artistas e desenvolvedores que querem criar arte digital. No código, podemos ver algumas funções que a biblioteca disponibiliza globalmente e que são usadas para desenhar e carregar dados no navegador. As funções que fazem isso são preload, setup e draw. Não falaremos sobre elas aqui, mas você pode ler mais nos links acima.

A partir do que Soon criou, temos algumas variáveis globais definidas no início do código: withPride (comOrgulho), whatisQueer (oqueéQueer), queerRights (direitosQueer), makingStatements (fazendoDeclarações), speak (falar ou fale), voices (vozes) e queers. A partir dessas variáveis, já sabemos que ela quer falar sobre orgulho queer, direitos queer e vozes queer. Outros elementos disponíveis globalmente são as funções makeVisible (fazendoSerVisível), SpeakingCode (códigoQueFala), speakingNow (falandoAgora) e notNew (nãoNovo). Disto, algo que chama atenção é que, embora seja uma função, SpeakingCode está escrita em PascalCase, em vez de camelCase. Outra observação é que a função notNew atua como uma espécie de construtor que possui alguns atributos associados a ela.

Porém, mesmo que essa desconstrução ajude a compreender melhor o código, o que temos aqui também é um poema, e faremos uma leitura mais aprofundada analisando linha por linha (poemas podem ser lidos de diferentes formas, então não há problema em dividi-los, separá-los e interpretá-los do seu próprio jeito). Agora, indo por partes:

Na parte makeVisible (limpei dos comentários para facilitar a leitura como poesia), vemos que tornar algo visível significa atribuir as pessoas queers e fazer declarações até que os direitos destas pessoas sejam visíveis e seja aceito que existem pelo menos tantos gêneros quanto há novos queers. Nessa parte, também podemos notar que a autora evitou usar números inteiros quase sempre que um número aparece, optando por usar float em vez disso. A única exceção é no trecho if (gender == abs(2)).

abs é uma função do p5.js que retorna o valor absoluto de um número. Nesse caso, a função não é necessária, já que 2 já é seu próprio valor absoluto, mas, como os autores de Aesthetic Programming dizem no livro, "Lido em voz alta, esse bloco de código pode ser traduzido como: 'Se gênero é igual a dois absoluto, fale código, queers, quem é queer, eu sou, fazendo declarações.'" (tradução livre de "Read aloud, the block of code might translate as: 'If gender equals absolute two, speaking code, queers, who is queer, I am, making statements.'"). Portanto, o que temos é que a função abs adiciona uma nova camada de significado a essa parte do código, sugerindo que, enquanto o gênero for considerado dois em absoluto (ou seja, se aceitarmos apenas dois gêneros como as únicas possibilidades), os queers precisarão falar e fazer declarações.

A próxima parte que quero destacar é a função draw. É aqui que a parte visual começa. A função draw é chamada 60 vezes por segundo pelo p5.js, fazendo com que a obra de arte funcione a 60 fps. Ela contém um for loop que percorre todos os elementos de queerRights e uma instrução if que chama a função makeVisible (que analisamos anteriormente) caso queerRights tenha menos de dois membros.

Antes de analisar isso linha por linha, quero chamar atenção para o uso de notFalse (nãoFalso) e para o número 2.0. Ambos são usados para evitar valores binários, como true, false, 0, 1 e 2. Como a autora está falando sobre queer e direitos queer, aqui ela faz mais uma declaração sobre a existência de uma realidade além do binário, evocando lógicas não binária ou lógicas de múltiplos valores, como a lógica paraconsistente. No entanto, o principal significado aqui é que existem mais de duas possibilidades e que precisamos torná-las visíveis.

Através do if, também percebemos que nunca teremos mais de três queerRights. Mais uma vez, a autora poderia ter escolhido dois mas decidiu usar um número que vai contra o binário.

Analisando o for loop, encontramos as expressões:

“Direitos queer não binários no mundo todo” - tradução livre de "queer rights non binary world wide");
“Direitos queer atos não binários” - tradução livre de "queer rights non binary acts";
“Vamos demonstrar suporte por direitos queer iguais não binários - tradução livre de "let support equals queer rights non binary shows".

Pelo próprio texto, entendemos que os direitos queer precisam ser considerados em uma perspectiva global e, para que isso aconteça, é necessário agir e demonstrar apoio.

Outra observação importante é que worldWide, act e shows são todas funções dentro dessa espécie de classe notNew. Se voltarmos à função makeVisible, veremos que ela instancia novos queers usando a função notNew. A ideia aqui é enfatizar que, embora a identidade queer possa parecer algo novo para pessoas de fora do movimento, essas pessoas não são novas — elas estão apenas, finalmente, se manifestando e lutando para serem vistas.

Há muito mais que pode ser dito sobre esse código. No entanto, meu objetivo aqui foi apenas mostrar como o código pode ser mais do que simples regras que um computador deve seguir. Eu diria, inclusive, que o código sempre é mais do que apenas uma sequência de passos ou um algoritmo. É por isso que programadores gostam de falar sobre legibilidade do código, código limpo e linguagens de programação que são mais fáceis de ler ou mais verbosas. Um poema em código apenas torna mais visível o fato de que existe mais de uma camada nas linguagens que usamos para criar o cenário digital.

Alfabetização expandida e o estado atual dos softwares

contato@felipebosi.com — Mon, 06 Jul 2026 00:00:00 GMT

Enquanto lia o livro Aesthetic Programming de Soon e Cox, me deparei com o conceito de “alfabetização expandida” que me fez refletir sobre como diferentes pessoas enxergam o software.

Alfabetização expandida é a capacidade de escrever e ler ampliada com a habilidade de compreender código. Este letramento adicional está ligado a uma melhor compreensão da mídia digital e de como nossa comunicação está sendo aprimorada por novas formas de linguagens de escrita. Novas linguagens que se comunicam tanto com programadores quanto iniciam ações em uma máquina ou sistema online.

Compreender como computadores e códigos funcionam é um dos fatores que diferenciam as pessoas que veem software, IA e tecnologias semelhantes como uma "caixa preta mágica" capaz de fazer qualquer coisa sem custos, daquelas que entendem os limites e os custos da tecnologia. Entendem que qualquer software funciona a partir de um conjunto de comandos que os programadores fornecem ao computador, e que os executa exatamente como foram escritos. Se quiser visualizar isso de maneira mais clara e cômica, veja o vídeo de Josh Darnit (em inglês):

Isso também é verdade para Modelos de Linguagem de Grande Escala (LLMs) e IA generativa. Nestes casos, podemos imaginar que temos um programa que gera outro programa/código com base nos dados de treinamento que recebeu. Este processo tem um custo elevado em termos de energia e trabalho manual para indicar ao modelo o que é correto e o que é errado. Caso contrário, ele pode acabar dizendo aos usuários que “Médicos recomendam fumar 2-3 cigarros por dia durante a gravidez.”

Voltando à ideia de alfabetização expandida, programadores sabem que um código escrito por um programador, especialmente um experiente, tem melhor desempenho e legibilidade do que um código gerado por máquina. Em termos leigos, isso significa que um código escrito por uma pessoa consome menos energia e pode ser melhor compreendido e corrigido — não apenas em relação a bugs que quebram apps, mas também em termos de consequências éticas, como IAs enviesadas, pessoas usando IA para aprender a fabricar armas ou cometer crimes sem serem detectadas (para mais informações, leia: "AI has a racism problem, but fixing it is complicated, say experts" e "Could a Chatbot Teach You How to Build a Dirty Bomb?" ), além de alucinações e mentiras descaradas.

IA é um tema muito discutido atualmente, mas a ideia aqui é focar em alfabetização expandida e nas diferenças entre programadores e não programadores que afetam a todos nós.

Algo comum entre desenvolvedores é a ideia de que “o usuário não se importa com a linguagem usada para construir algo” ou que “a melhor linguagem é a que paga minhas contas”, e eu diria que ambas são verdadeiras. Mas isso só acontece porque o usuário não é alfabetizado em código. No entanto, o usuário final ainda é diretamente impactado pelo código, pela linguagem e pelas escolhas tecnológicas que fazemos. Até financeiramente. Os usuários começam a sentir que seus computadores ou celulares estão “ficando mais lentos” e decidem comprar novos. Parte disso pode ser atribuída ao envelhecimento do hardware, mas uma grande parte está relacionada às escolhas de linguagem, framework, paradigma e tecnologia.

Embora o usuário não se importe com a forma como construímos o software que ele usa, isso afeta a durabilidade do hardware, o consumo de energia da bateria e até a velocidade com que uma ação é executada (para um estudo detalhado, consulte "Ranking programming languages by energy efficiency"). Enquanto os usuários não se preocupam com a construção do software, a maioria das empresas tentará economizar ao máximo e vender software lento como se fosse “extremamente rápido” (tradução livre de “blazing fast” - Um termo familiar para programadores, mas que na prática pode significar qualquer coisa, desde muito lento a realmente rápido), enquanto apenas programadores que podem verificar o que está por trás do sistema conseguem distinguir.

Enquanto os usuários continuarem evitando aprender como computadores e software funcionam, as empresas farão o possível para aumentar seus lucros às custas do dinheiro dos usuários e do meio ambiente. Vendendo promessas falsas de um futuro onde qualquer coisa pode ser gerada usando linguagem natural a baixo custo, quando na realidade somos forçados a comprar novos computadores e celulares para acompanhar tendências que nunca pedimos e das quais não obtemos nenhum benefício.