Ulisses Hen

Seu componente React não deveria saber de onde vêm os dados. Mas é o que a gente mais vê no dia a dia: fetch, regra de negócio e JSX no mesmo arquivo. Funciona — até a API mudar um campo e a tela inteira quebrar junto. Clean Architecture no frontend não é criar 15 pastas nem abstrair tudo. É uma regra só: as dependências apontam para dentro. Seu domínio (as regras de negócio) não conhece React, nem axios, nem o formato da API. Quem lida com esses detalhes é a camada de infraestrutura. Peguei um caso comum — um card de assinatura — e refatorei camada por camada: - Domínio: regras puras, sem framework, testáveis em milissegundos. - Infraestrutura: isola o axios e o DTO; o resto do app nunca vê snake_case. - Aplicação: um hook que orquestra o caso de uso e entrega tudo pronto. - UI: um componente burro, só apresentação. O ganho não é estético: regra de negócio testável sem montar componente, tipagem forte de ponta a ponta e mudança de contrato da API que toca 1 arquivo, não a tela inteira. Não precisa reescrever o projeto amanhã. Comece pequeno: na próxima feature, tire a regra de negócio de dentro do componente. Como você separa suas camadas no front? Comenta aí — sempre tem uma abordagem diferente que vale aprender. Salve o carrossel pra consultar na sua próxima refatoração. #React #TypeScript #CleanArchitecture #Frontend #ReactJS #NextJS #CleanCode #SoftwareArchitecture #DesenvolvimentoWeb #FrontendDevelopment

4

2 Comments

O que realmente define a senioridade de um desenvolvedor? Junior, pleno ou sênior não deveria ser definido apenas pelo tempo de experiência, quantidade de tecnologias no currículo ou número de frameworks que alguém conhece. Cada vez mais, eu vejo senioridade relacionada ao nível de responsabilidade que um profissional consegue assumir. Recentemente coloquei em operação uma aplicação que já organiza dezenas de coordenadores, mais de uma centena de lideranças e uma estrutura com potencial para impactar milhares de pessoas. E quando pessoas reais começam a depender do software, a responsabilidade muda. Não basta mais apenas fazer funcionar. É preciso pensar em segurança, controle de acesso, privacidade e integridade dos dados, regras de negócio, disponibilidade, experiência de usuários não técnicos, manutenção, evolução do sistema e principalmente nas consequências das decisões técnicas tomadas durante o desenvolvimento. Isso me fez refletir sobre senioridade. Senioridade não é saber mais frameworks. É conseguir receber um problema pouco estruturado, entender o negócio, transformar necessidades em requisitos, avaliar riscos, tomar decisões técnicas, construir uma solução e assumir responsabilidade pelo que acontece depois que ela entra em produção. O número de usuários, sozinho, não transforma ninguém em sênior. Mas quando centenas ou milhares de pessoas passam a depender do que você construiu, erros de arquitetura, segurança, usabilidade e negócio deixam de ser apenas problemas técnicos e passam a ter impacto real. Talvez a melhor pergunta não seja: “Quantos anos você programa?” Mas: “Qual é o nível de problema e responsabilidade que você consegue assumir?” #DesenvolvimentoDeSoftware #EngenhariaDeSoftware #Programação #CarreiraTech #SoftwareEngineering #Desenvolvedor

2

Distro Linux nova aparece toda semana. Essa aqui é diferente, e não é pelo tema bonito. O Omarchy é o projeto do DHH (o cara do Ruby on Rails) construído sobre Arch, Hyprland e Quickshell. A proposta é omakase: escolha do chef. Alguém já tomou as decisões difíceis por você, e o que sobra é trabalhar. O que chama atenção tecnicamente → Instalação de 35 segundos nas máquinas mais rápidas e menos de dois minutos na maioria dos computadores. Grava a ISO, responde cinco perguntas, tem um desktop pronto → Tiling window manager e workflow keyboard first por padrão, sem precisar garimpar config por dias → Roda bem até num ThinkPad X220 de 2011 com 2 GB de RAM, e revive Mac Intel antigo → Neovim como padrão, com VSCode, Cursor, Zed e outros prontos pra instalar. Mise gerenciando versões de linguagem por projeto A parte que surpreende: agentes como cidadãos de primeira classe Aqui mora a tese do projeto. No primeiro boot, o sistema convida você a configurar um agente padrão. E não é chatbot decorativo: → Quando uma aplicação quebra, você clica na notificação e o agente investiga o log, diagnostica o problema e ajuda a reportar o bug → O sistema inclui skills que ajudam o agente a criar aplicações, plugins e temas A frase que resume a ideia é do próprio DHH: se dá pra criar qualquer aplicação com vibe coding, deveria dar pra fazer o mesmo com o sistema operacional. Por que isso faz sentido arquiteturalmente Tudo no Omarchy é arquivo de configuração em texto. Terminal, scripts, logs, dotfiles. Isso é exatamente a superfície que um agente consegue ler, editar e testar sem fricção. Tem uma ironia bonita aí: o futuro da computação com IA está se parecendo muito com o jeito antigo de usar computador. Arquivos, terminal, texto, uma máquina que você consegue entender de ponta a ponta. Sistema opaco cheio de painel gráfico é péssimo pra agente e, no fim das contas, sempre foi péssimo pra gente também. O contexto O projeto tem mais de 1,1 milhão de downloads da ISO no primeiro ano e cerca de 40 mil estrelas no GitHub. A fundação por trás já levantou volume expressivo com patrocinadores corporativos e individuais, o que garante fôlego de manutenção. Não é pra todo mundo. É opinativo por design, e quem odeia tiling window manager vai sofrer nos primeiros dias. Mas se você trabalha com agentes o dia inteiro e já se pegou querendo que o sistema operacional fosse tão maleável quanto seu código, vale instalar numa VM e passar uma tarde. Você mudaria de sistema operacional por causa de integração com agentes? Ou ainda acha cedo demais? Comenta aí 👇 #CaduFala #Linux #Omarchy

1