Original: artigo “ O que aprendi como desenvolvedor de acidentes no espaço ”, de Andrei Sitnik, do blog Evil Martians “ Martian Chronicles ”

Andrei Sitnik, autor do PostCSS e do AutoPrefixer , fez uma seleção de histórias relacionadas à exploração espacial pela União Soviética. Você aprenderá as lições que Andrei aprendeu com eles para crescer como desenvolvedor e participante do movimento de código aberto. Ancoragem malsucedida, entrada dramática na atmosfera e uma transição única ao longo do trilho entre naves espaciais - o que tudo isso tem a ver com o desenvolvimento da web moderna? Leia sobre tudo isso em um post!

A exploração espacial me interessou tanto quanto me lembro. As pessoas que me conheciam pessoalmente ouviram mais sobre o espaço do que gostariam. Antes de ingressar no Evil Marcianos, administrei a versão em russo da Wikipedia e um dos meus hobbies favoritos era editar artigos relacionados ao espaço. Fui assistir aos lançamentos em Baikonur e Cabo Canaveral e, quanto mais aprendia sobre os esforços de exploração espacial, mais esse conhecimento me afetava como desenvolvedor.

Embora escrever programas não seja tão difícil quanto construir foguetes (na maior parte), nós, engenheiros de software, muitas vezes trabalhamos em grandes equipes, criando sistemas complexos. E, como exploradores espaciais, às vezes perdemos a luta contra a complexidade.

“Um início de emergência nos dá muito mais para conhecer e melhorar o sistema do que dezenas de projetos bem-sucedidos”

- Nikolai Pilyugin, acadêmico, designer, especialista na área de sistemas de controle autônomo para complexos de foguetes e foguetes espaciais.

Em todo programa espacial, erros acontecem, nem todos são trágicos. Neste artigo, falarei sobre exemplos da história soviética e russa da exploração espacial, que são pouco conhecidos fora da comunidade de entusiastas (estamos falando da comunidade ocidental - aprox. Transl.). Essas histórias terminaram bem.

Primeira lição: nunca culpe os usuários *

* ... e faça alterações em cada um de seus recursos.

No final da década de 1960, os Estados Unidos e a URSS concluíram o trabalho em uma nova geração de naves espaciais. A Apollo e a União deram um grande passo adiante após o experimental Mercury / Gemini e East / Sunrise. Novas naves foram projetadas para trabalhar não apenas em órbitas próximas à Terra, mas também para voos para a Lua e para trás.

Em outubro de 1968, a URSS se recuperou do desastre da Soyuz-1 e estava pronta para fazer uma nova tentativa: foi planejado pela primeira vez realizar atracação manual de dois navios em órbita. O Soyuz-2 automático deveria entrar no espaço primeiro. Então Georgy Beregovoi em Soyuz-3 deveria entrar na mesma órbita e atracar os navios.


O piloto do Soyuz-4, Soyuz-8 e Soyuz-10 Vladimir Shatalov demonstra a atracação de dois navios.

O lançamento correu bem. Após apenas 1,5 horas, o Soyuz-3 estava a uma distância de atracação. A manobra foi planejada para o período "noturno", na sombra da Terra. No entanto, todas as tentativas de acoplamento manual foram encerradas sem êxito.

E somente quando os dois navios estavam do lado do dia, Beregovoi descobriu um erro: o Soyuz-2 era girado 180 graus ao longo do eixo longitudinal.

Como naquela época todo o suprimento de combustível havia sido usado para as tentativas de atracação, Beregovoi recebeu a ordem de concluir a missão e retornar à Terra quatro dias depois. Os jornais consideraram o vôo bem-sucedido, e Beregovoy recebeu o título de Herói da União Soviética e logo foi promovido. No entanto, as lições corretas foram aprendidas nesta história e novas regras foram introduzidas para todas as associações subseqüentes:

• Dock apenas no lado ensolarado.
  
• Não planeje atracar em um dia com o lançamento, para que os pilotos tenham tempo para se acostumar em órbita.
  

Dock Soyuz-4 no filme "Quatro no espaço" .

Lembre-se desta história ao inserir o plugue USB tipo A novamente no lado errado.

Não há usuários ruins - há uma interface ruim.

É fácil culpar os usuários. No entanto, as pessoas sempre estarão erradas. Os desenvolvedores não são exceção. Como participante do movimento open source, percebi que se você culpar os desenvolvedores por erros, ainda assim não ajudará a evitar erros no futuro.

Fechando a questão sobre um problema no seu repositório de código-fonte aberto com uma resposta rude no estilo RTFM (ou, pior ainda, nenhuma resposta!), Você não se protegerá da aparência do mesmo problema. Você receberá as mesmas mensagens repetidamente.

Como criador do PostCSS e do Auto Prefixer, recebo muitos relatórios de problemas . Para não perder tempo a longo prazo, sigo a regra: todo problema deve levar a uma alteração no código ou na documentação .

É melhor melhorar a experiência do usuário, UX (do ponto de vista da biblioteca de código aberto, será uma API), para que no futuro seja impossível cometer o mesmo erro. Na pior das hipóteses, você pode adicionar um aviso.

Por exemplo, muitos usuários do PostCSS esquecem a opção do analisador e tentam processar arquivos .less e .scss sem os analisadores correspondentes. Em vez de culpar os usuários, adicionamos um pequeno aviso:

if (error.name === 'CssSyntaxError' && opts.from.endsWith('.scss')) {   error.message += '\nYou tried to parse SCSS with ' +                    'the standard CSS parser; ' +                    'try again with the postcss-scss parser' } 

Segunda lição: por todos os meios, informe o desenvolvedor sobre os problemas

Três meses após o voo da Soyuz-2 e Soyuz-3, a URSS estava pronta para uma nova tentativa de atracação manual, ainda mais ambiciosa.

Planejava-se o lançamento de duas naves tripuladas com diferença de um dia: Soyuz-4 com um astronauta e Soyuz-5 com três. Após o acoplamento, o engenheiro piloto e o engenheiro de pesquisa da Soyuz-5 deveriam passar pelo espaço aberto para a Soyuz-4 e retornar à Terra. Ou seja, eles decolaram em uma nave, passearam no espaço, pousaram em outra nave.


Transição através do espaço sideral de Soyuz-5 para Soyuz-4.

Boris Volynov , um piloto da Soyuz-5, deveria permanecer sozinho e retornar à Terra um dia depois.

Dessa vez, o Soyuz-4 completou sua missão sem problemas. E em 18 de janeiro de 1969, era hora de voltar para casa e para Volynov. A união consiste em três módulos destacáveis, e apenas um, o central, foi projetado para entrar na atmosfera.


Regime da União. Fonte: NASA

Durante o retorno de Volynov, o módulo agregado por instrumento não se separou normalmente. Era tarde demais para interromper o pouso. A sonda entrou na atmosfera com uma orientação incorreta no espaço: nariz para a frente. O fluxo de entrada era oposto apenas por uma fina escotilha de entrada, o escudo térmico ficava atrás, entre os módulos que não estavam divididos.

O selo ao redor da escotilha começou a queimar, a cápsula de pouso começou a se encher de fumaça tóxica. A gravidade e a atmosfera fizeram o seu trabalho: o Volynov indefeso foi preso em uma cadeira.


Imagem artística da entrada para a atmosfera da Union-4.

No entanto, o calor que poderia matar Volynov o salvou inesperadamente: os tanques de combustível do módulo de instrumentos explodiram e, como resultado, se separaram. A cápsula de pouso girou para a posição correta, com o escudo térmico à frente.

Todo esse tempo, Volynov, confiante de que estava vivendo os últimos minutos, gravou em voz alta tudo o que vê e ouve.

Os problemas não terminaram aí. Os estilingues de para-quedas se enredaram e os motores de pouso suave não funcionaram. A cápsula atingiu o chão em alta velocidade, longe da área planejada. O Volynov ferido teve que sobreviver no frio a -38 ° C até que os socorristas o alcançassem.

O astronauta comentou em voz alta todos os sons e vibrações, esperando que o gravador de vôo sobrevivesse ao acidente e que os engenheiros pudessem ouvir as gravações e impedir novos desastres.

O que essa história digna de uma adaptação cinematográfica de Hollywood me ensinou?

Toda vez que encontro um problema associado a uma biblioteca ou ferramenta de desenvolvimento, lembro-me de Boris Volynov. Se ele foi capaz de relatar problemas, mesmo à beira da morte, então posso definitivamente levar alguns minutos para enviar um relatório ao desenvolvedor.

Mesmo um relatório simples pode ser uma grande contribuição para o projeto.

Devido à síndrome do impostor presente em nossa indústria, muitas vezes nos sentimos culpados dos problemas que surgem. Alguma coisa estava faltando na documentação ou simplesmente não era inteligente o suficiente. Mas não se esqueça da lição da primeira história: não há usuários ruins, existe apenas uma interface ruim. E não há desenvolvedores ruins, existem apenas ferramentas de desenvolvimento ruins.

Se você cometeu um erro ao usar a estrutura, provavelmente não é o primeiro nem o último. Além disso, você analisou o produto de uma perspectiva perdida pelos desenvolvedores que veem o código todos os dias. Uma nova aparência facilita a observação de problemas na documentação e na experiência geral de desenvolvimento.

Você cometeu um erro de digitação, recebeu uma mensagem de erro incompreensível e, como resultado, passou uma hora depurando? Esta é uma ótima oportunidade para melhorar a mensagem de erro com o novo problema ou PR. Procurando uma maneira de contornar a biblioteca por muito tempo? Pense em quais informações na documentação o ajudariam.

Terceira lição: automação de confiança

Esta história aconteceu em 1997 com a agora extinta Estação Espacial Mir .

Havia uma diferença importante entre os programas espaciais soviéticos e americanos. Na URSS, os navios foram criados pelas mesmas pessoas que criaram os foguetes: eles fizeram uso extensivo da automação e consideraram os pilotos praticamente um fardo. E nos EUA, as naves (em particular, o ônibus espacial) foram criadas por pessoas que projetavam aviões e consideravam os computadores apenas como ferramentas auxiliares para os pilotos.

Desde 1967, a URSS utiliza sistemas de acoplamento totalmente automáticos: primeiro Igloo e depois Course. Esses desenvolvimentos tornaram possível construir a estação Mir a partir de módulos automáticos que atuam como espaçonaves independentes com seus próprios computadores, sistemas de energia e motores.


Módulos da estação Mir.

No entanto, os sistemas de ancoragem soviéticos foram fabricados na Ucrânia e, após o colapso da URSS, Moscou e Kiev não concordaram com os preços. O Roscosmos, tentando reduzir sua dependência de componentes externos, desenvolveu uma alternativa - TORU , que permitia ao operador da estação espacial controlar remotamente a nave usando dois joysticks.

TORU testado com sucesso no espaço. Em 1997, o navio Progress M-34 com carga para a estação atracou com sucesso automaticamente no mundo. E então, inesperadamente, houve uma instrução para desencaixá-lo e, em vez de retornar à Terra, encaixe-o novamente na estação manualmente para verificar novamente o sistema de encaixe.


Vasily Tsibliev controla o navio da estação Mir.

A tripulação tentou manter o controle do Progress sobrecarregado (carregava o próximo lote de resíduos da estação, que precisava ser devolvida à Terra), e era difícil detectar Mir no vídeo transmitido do navio. Quando os astronautas finalmente viram o navio que se aproximava através das janelas, era tarde demais para desacelerar. A nave danificou o painel solar do módulo Spectrum, que fornecia 40% da eletricidade da estação, e fez um buraco no casco.

Os astronautas ouviram um apito e seus ouvidos foram bloqueados. A estação estava perdendo ar.

A equipe teve que desconectar os cabos provenientes do Spectrum, fechar o módulo e deixá-lo sem lacre. E três anos depois, a estação foi inundada no oceano.

Como resultado, o Curso não foi abandonado do sistema de ancoragem, hoje está sendo fabricado na Rússia. O curso e o TORU são usados ​​em navios russos, o TORU é um sistema de backup.

Até hoje, as razões da primeira e até agora a única colisão no espaço não são totalmente claras . O centro de massa do navio foi deslocado devido à sobrecarga, os astronautas estavam cansados ​​e com o TOPU de má propriedade. O teste em si foi organizado às pressas: naquele momento, um astronauta americano estava a bordo do mundo, e nem ele nem a NASA sabiam sobre o teste até que a estação estivesse despressurizada.


Danos ao mundo após uma colisão com o Progress M-34 em 1997.

Essa história me lembrou o famoso script para instalar drivers para uma placa de vídeo que destruiu os sistemas Linux . O desenvolvedor exausto da biblioteca, que trabalhava à noite, perdeu apenas uma lacuna:

  # GIANT BUG... causing /usr to be deleted... so sorry.... - rm -rf /usr /lib/nvidia-current/xorg/xorg + rm -rf /usr/lib/nvidia-current/xorg/xorg 

As pessoas estão erradas. Prefere automação. Os carros devem sofrer!

Sigo a regra: se você vir o mesmo erro duas vezes no seu código-fonte, é melhor criar uma ferramenta automatizada que possa evitar esse erro no futuro.

Linters de código-fonte (como ESLint para JavaScript e Stylelint para CSS) muito bem encontram bugs que podem custar muito tempo e dinheiro. Você passará várias horas escrevendo seu próprio plug-in de linter, mas a longo prazo será recompensado.

Deseja evitar erros de digitação na documentação? Tente yaspeller . Deseja organizar propriedades em CSS em alguma ordem? Adicione ordem de stylelint às suas ferramentas de desenvolvimento.

* * *

Espero que tenham gostado das minhas histórias espaciais. Mesmo que parecessem absurdos para você, as lições aprendidas permanecem úteis para todos os desenvolvedores de software.

A história da exploração espacial não é apenas a inspiração para minhas histórias em conferências e pós-festas, mas também serve como fonte das técnicas corretas. O que melhor lembra você da necessidade de enviar um relatório sobre o problema do que uma espaçonave em chamas?