🕯️O que o apagão global de 19/07/24 pode ensinar a devs
Erre onde "erro é aprendizado" e evite onde pode gerar catástrofe. Mais: do React ao React Native; depoimento de um dev com 35 anos de carreira; IA que usa TDD para gerar código; e dicas para liderar.
Testar e "quebrar rápido" é um mantra da inovação. Você vai encontrar muito disso na "filosofia" Lean Startup e até em frases de figurões da área, como "Move fast and break things", de Mark Zuckerberg.
Para muitos, pode soar até "cafona" e "fora de moda" ir contra esse princípio em tecnologia. Até chegarmos ao core de sistemas realmente críticos, dos quais dependem aeroportos, hospitais, governos, bancos e boa parte da infraestrutura mundial…
Você provavelmente viu as notícias sobre o apagão global provocado por um software nesta sexta-feira (19/07/2024), que provocou a tal da "tela azul da morte" (BSoD, na sigla em inglês) em terminais de servidores Windows de grandes empresas mundo afora.
Resumo da ópera: um software empresarial chamado Falcon, usado na proteção de servidores e fornecido pela CrowdStrike (que desvalorizou US$ 11 bi), teve um update para hosts Windows lançado com bug — sim, responsabilidade de devs. O defeito impediu milhares de terminais conectados a esses hosts de inicializarem e, para piorar, esses servidores fazem funcionar desde grandes companhias aéreas até telões da Times Square. Ou seja, bugou a realidade, para transtorno de muita gente e terror dos devops. Hosts Linux e Mac não foram afetados, o CEO da CrowdStrike esclareceu que foi falha e não ataque, teve de linkar uma declaração no site da empresa, e ainda durante o dia boa parte dos serviços foi restabelecida.
Mas fatos à parte (até porque você os encontra aos milhares), o que nos interessa são reflexões que apagão traz ao desenvolvimento de software:
Errar onde erro é aprendizado e não onde pode gerar catástrofe: "Move fast and break things" pode ser "cool" e "legalzinho" em domínios praticamente inofensivos à realidade física (pense em conteúdo, marketing, entretenimento e afins) — e é realmente útil onde a incerteza é alta, a complexidade impera e erro é aprendizado. Mas onde há regulamentação, anos de consolidação e os danos são críticos, como serviços que mantêm o mundo rodando, erro pode gerar catástrofe. É uma distinção que temos de saber fazer ao criar software que impacta o mundo real e as pessoas.
Um errinho pode virar erro em cascata: mesmo que o assunto pareça distante a quem trabalha com aplicações pequenas ou aparentemente sem criticidade, vale lembrar: um bugzinho que passou batido por desleixo ou falta de atenção, um code review apressado ou descuidado, uma má decisão de design, uma má priorização e a falta de QA podem fazer um "errinho" se tornar erros em cadeira e em escala, à medida que uma aplicação cresce, conecta-se e passa a ser fundamental a outras. Atenção porque, como diz o ditado, "o diabo mora nos detalhes".
Testes não são só para constar: é normal, pela nossa ânsia (muito humana) em construir, querermos pôr uma aplicação de pé rapidamente. Até a confiança pode nos cegar a erros. Contudo, uma dose de ceticismo, humildade e senso "científico" (questionar certezas) é sempre amiga da cautela e do bom senso. Nesse sentido, sempre vale considerar testes com seriedade, se possível desde o início (TDD?).
Buscar arquitetura anti-complexidade: "Mas é isso que queremos o tempo todo, o problema é que não é trivial!", você pode argumentar. Sim, evitar a complexidade é difícil. Naturalmente, as coisas irão se emaranhar em algum momento e depender umas das outras. Mesmo assim, vale uma certa obsessão em buscar sempre independência e desacoplamento entre partes, responsabilidades únicas de componentes e clareza no design e na implementação de sistemas. O futuro agradecerá.
Comunicação clara, rápida e honesta: se mesmo com precauções as falhas ocorrerem, nunca é demais saber comunicar clara e honestamente o que está acontecendo (ou as hipóteses mais prováveis), de modo a evitar confusões ou desespero, motivar ações rápidas e resolutivas, e evitar que problemas se alastrem. Isso tem de integrar o ponto principal, que vem a seguir.
Ter estratégia (com contenções de segurança): mais do que pontos ou pŕaticas isoladas, o melhor é empacotar tudo em uma estratégia para agir. Cabem aqui desde um processo de review e QA cuidadosos, testes para tudo, evitar a complexidade, mas também ter "boias" e "coletes-salva" vidas por perto — uma maneira de fazer rollback em updates sem provocar ainda mais danos, formas de isolar elementos críticos e até documentá-los para que todos saibam como agir caso necessário.
À medida que a vida humana fica mais dependente de software, problemas como o apagão global deste 19/07/2024 poderão ser apenas o primeiro de muitos. Isso naturalmente levará a mais fiscalização do setor, mais cobrança por regulamentação e mais cuidado das próprias empresas ao contratar serviços.
Vale ficarmos ligados como desenvolvedores, porque é o trabalho com código que está em jogo. Quem souber, como profissional, como time e como empresa, adotar uma mentalidade de redução de danos e transmitir confiança, ganhará pontos nesse cenário. Além disso, poderá dormir tranquilo sabendo que não é só codar por codar, mas que seu trabalho tem um impacto ético na vida dos demais.
❓Por falar em TDD, você sabe o que é isso?
Tópico interessante não só para saber conceitualmente, mas sobretudo para pôr em prática. Responderemos no fim desta edição.
📱 Quer transitar do React para o React Native?
Saiba que há diferenças do segundo para o primeiro, como primitivas de UI, estilização, gestos e animações específicas para dispositivos móveis. E também erros a serem evitados, como o uso inadequado de mapeamento de arrays para listas e a exposição de segredos no código do aplicativo. Também será útil aprender sobre conceitos específicos de desenvolvimento nativo, como assinatura de compilação, deep linking e densidade de pixels, bem como o processo de implantação nas lojas de aplicativos. Mais nesse artigo no blog do Expo.
👥 "É mais sobre habilidades sociais do que técnicas"
Quantos anos você está no desenvolvimento? Dois, três, dez? Está começando agora? Veja o que aconselha Jim Grey, após 35 anos de carreira: habilidades sociais são mais importante do que as técnicas (construa relacionamentos, seja visível e útil na empresa); busque soluções diretas e simples, lance rapidamente e itere a partir daí; faça networking, assuma novos desafios e busque interesses em vez de salários e títulos; entenda as dinâmicas sociais e aceite que software muda; e aprenda que normalmente o ótimo é inimigo do bom o suficiente. Relato completo aqui.
💡IA para código que escreve testes primeiro
Já que falamos em TDD — e mesmo que seja só mais um anúncio de IA —, a sacada é interessante: Micro Agent é uma ferramenta open source, disponível para instalação via npm, que funciona restringindo a IA a tarefas específicas de programação e usando testes unitários como guia. O que o assistente faz é descrever a função desejada, gerar testes unitários automaticamente, escrever código que passe nos testes e iterar até que todos os testes sejam bem-sucedidos. Vamos concordar que mesmo que não funcione, pode ser uma boa abordagem para guiar a IA em tarefas mais exigentes, com menos propensão à geração de lero-lero. Mais no blog da empresa que desenvolve a parada.
🐧Linux é o principal sistema operacional na nuvem da Microsoft hoje
Parece ironia (e talvez seja, mas do destino). Linux, outrora considerado um "câncer" pelo ex-CEO da Microsoft Steve Ballmer, tornou-se o sistema operacional dominante na plataforma de nuvem Azure, da Microsoft. Inicialmente lançada em 2008 como "Red Dog" para oferecer uma plataforma .NET, a Azure passou a ver pedidos crescentes de uma LAMP Stack hospedada em seus domínios. Foi sob a gestão de atual CEO Satya Nadella, que aproximou a Microsoft do código aberto, adquirindo o GitHub e levantando o lema “Microsoft ❤️ Linux”, que o SO do Pinguim cresceu na Azure, hoje representando mais de 60% das ofertas do Azure Marketplace. Mais sobre a história aqui.
💨 Não sabe como liderar? Treine a coragem
A recomendação é da newsletter Techlead Mentor. O autor dá três conselhos para quem quer se tornar um líder mais decisivo, claro e confiante: não apressar decisões, dar feedbacks claros e não temer conflitos. Pontos adicionais importantes são reconhecer quando não se tem todas as informações e saber comunicar expectativas à equipe ou superiores, além de equilibrar apoio e transmissão de confiança à equipe com a gestão de conflitos e as decisões difíceis. Mais aqui.
✅ Resposta: "Por falar em TDD, você sabe o que é isso?"
TDD ou Test-Driven Development é uma abordagem que inverte o fluxo tradicional de criação de código. Em vez de escrever o código de produção primeiro e depois os testes, o desenvolvedor: a) começa escrevendo um teste automatizado, que define uma função desejada; b) executa o teste (que inicialmente falha); c) implementa o código mínimo necessário para passar no teste; e d), em seguida, refatora o código para melhorar sua estrutura sem alterar seu comportamento. Este ciclo, frequentemente resumido como "Red-Green-Refactor", é repetido para cada nova funcionalidade. TDD promove um design mais modular, reduz a probabilidade de bugs, fornece documentação viva por meio dos testes e encoraja devs a pensarem sobre os requisitos e casos de uso antes de codar. Embora possa ser mais lento, tende a levar a um código mais confiável e fácil de manter a longo prazo. Mais aqui ou no livro do Kent Beck que popularizou a sigla.
Obrigado por ler!
Voltaremos com mais fatos, tendências e dicas na próxima semana. Curta, compartilhe, comente e vote na enquete. Obrigado por ler e por estar com a BeTalent!