É verdade, todo esse tempo, algo permaneceu o mesmo. Ou seja, o código é enviado para uma lista de discussão (ou várias listas), e lá é revisado e discutido até que seja considerado pronto para inclusão no kernel do Linux. Mas apesar do fato de que esse processo de trabalhar com código tem sido usado com sucesso por muitos anos, ele é constantemente criticado. Por exemplo, este
Um artigo recente de Sara Novotny, da Microsoft, fez muito barulho na Internet. Esse artigo disse que as técnicas de colaboração de código usadas no desenvolvimento do kernel do Linux estão desatualizadas. Ele diz que se a comunidade de desenvolvedores Linux deseja atrair jovens profissionais para suas fileiras, esses métodos seriam bons para substituir por algo mais moderno. No debate em torno dessas ideias, seus defensores e oponentes entraram em confronto.
Acredito que minha posição me permite fornecer algumas idéias sobre o desenvolvimento do kernel Linux. Por quase dez anos, tenho escrito código para Linux e outros projetos que são organizados de forma semelhante. Quando eu estava na Red Hat, contribuí com o código de infraestrutura do kernel x86, o código do hipervisor KVM e do emulador QEMU e o código do hipervisor Xen. Participei do desenvolvimento de outros projetos também. Não fiz muito Linux por cerca de 7 anos, mas apenas porque dediquei meu tempo a trabalhar no framework C ++ Seastar e no banco de dados ScyllaDB... Ambos os projetos foram desenvolvidos usando uma metodologia muito semelhante à usada no desenvolvimento do Linux. Agora trabalho como engenheiro-chefe na Datadog, uma empresa onde os processos de desenvolvimento de software são quase exatamente opostos aos usados no Linux. Isso está muito mais próximo de como o desenvolvimento é organizado em outras empresas da web.
Então, de que lado estou? Deixe-me deixar bem claro que não gosto do processo de desenvolvimento do Linux. Tenho certeza de que isso não é apenas uma barreira para novos desenvolvedores, mas também uma barreira para a alta produtividade no código (e não se trata de usar email). Esta é a fonte de sentimentos negativos experimentados pelos desenvolvedores. E não vou seguir esse modelo para nenhum projeto em que tenha o direito exclusivo de tomar decisões sobre como o trabalho será organizado.
Mas, ao mesmo tempo, parece que muitos críticos do processo de desenvolvimento do Linux acreditam que o fato de seus defensores estarem lutando por ele tão ferozmente é apenas uma consequência do fato de que a comunidade Linux está cheia de pessoas idosas que têm um domínio da tradição e não está disposto a mudar sob qualquer pretexto. Este não é o caso (embora eu tenha certeza de que existem essas pessoas na comunidade Linux). O processo de desenvolvimento do kernel Linux traz alguns benefícios exclusivos e importantes para seus usuários. Se você aplicar os mesmos princípios a qualquer outro projeto, esse projeto só se beneficiará dele.
Qualquer outra ferramenta, além do e-mail, dita a quem a usa esquemas de trabalho bastante rígidos, privando o Linux de tal vantagem. E as listas de discussão são apenas um mecanismo perceptível que atrai a atenção dos debatedores. Precisamos de ferramentas que possam diminuir as barreiras de entrada para desenvolvedores Linux. Ferramentas que podem corrigir falhas no processo de desenvolvimento. Um que permite que diferentes organizações reconheçam os pontos fortes da organização de desenvolvimento Linux. Ferramentas como essas podem realmente fazer a diferença para toda a indústria de desenvolvimento de software.
Muitos desses mecanismos são de grande benefício. Para não prolongar a nossa conversa, vou centrar-me num deles, que considero o mais importante. Farei o possível para revelar sua essência e falar sobre por que, apesar de seus pontos fortes, causa tantas emoções negativas nos desenvolvedores. Também direi por que ele, por um lado, é capaz de beneficiar outros projetos, e por outro - por que é tão importante para o Linux.
Enviar mensagens e patches
No mundo do desenvolvimento do kernel Linux, existe uma regra: o código que se destina a ser incluído no kernel deve ser dividido em patches separados. Cada um deles deve resolver um e apenas um problema. Uma mensagem de confirmação significativa deve ser preparada para cada patch. Freqüentemente, essas mensagens são mais longas do que o código que descrevem.
Este é um excelente exemplo do que geralmente falta em outros projetos. A maioria das mensagens de commit que vi em projetos modernos no GitHub se parece com algo como "mudanças a partir de 25 de agosto", ou ligeiramente (mas apenas ligeiramente) melhor, como "implementação da função X". Se alguém precisar examinar um código como este no futuro, não será fácil descobrir por que essas alterações foram feitas no código. Alguns dos bugs corrigidos por esses commits podem ser sutis. Se você não sabe exatamente como esses erros foram corrigidos, eles podem facilmente retornar ao projeto. Ao ler a mensagem de confirmação curta e sem sentido, posso não estar ciente das circunstâncias em que o bug foi descoberto.
Aqui está um pequeno exemplo. Dê uma olhada no commit do kernel Linuxpor meu bom amigo Johann Weiner. É fácil para mim imaginar como, em outro projeto, uma mensagem para um commit semelhante seria semelhante a "remoção de avisos". E quando leio a mensagem do commit discutido aqui, fico sabendo por que é possível, sem prejuízo para o projeto, se livrar desses avisos, sobre as circunstâncias em que isso, de fato, não levará a nada de ruim, e sobre o que as regras devem ser seguidas se um dia for decidido alterar este código.
Tenho certeza de que há pessoas em muitas organizações que fazem isso. Mas ao trabalhar no kernel Linux, todos os envolvidos neste negócio devem fazer isso. Portanto, estou bastante confiante de que, lendo a mensagem de confirmação, entenderei tudo o que há para entender sobre as alterações de código correspondentes. Se estamos falando de um erro, irei aprender em quais sistemas ele se manifestou, em que condições ocorreu, por que não afetou outros sistemas de forma alguma, e o que deve ser prestado atenção para que esse erro não volte ao projeto.
Esse tipo de trabalho é altamente desejável em qualquer organização. Isso torna mais fácil para outras pessoas (e para o próprio desenvolvedor, quando ele volta para seu código depois de um tempo) entender os motivos para fazer alterações no código, entender por que o código funciona da maneira que funciona. Isso torna mais fácil para novos programadores conhecer o projeto. Isso resolve o problema de retornar erros antigos, reduz o perigo de que algum código, aparentemente não relacionado ao em questão, possa quebrar algo nele.
Em outros projetos, isso é “altamente desejável”. Mas no Linux é absolutamente necessário por dois motivos:
- Linux . , . Linux, , - . , , , . ( ) , Linux. , Linux.
- (). Linux, . , 2020 , Linux , LTS-. , , - , Linux LTS-, Linux. , 2000- , . , , Red Hat .
Os backports geralmente não são um problema para as empresas online modernas que não precisam manter várias linhas de produtos paralelas. Eles criam algo, passam para os usuários e é aí que tudo termina. Mas quando os backports entram em jogo, as coisas ficam mais complicadas. O desenvolvedor (provavelmente não o autor do programa) pode precisar decidir como adaptar um pouco o código a uma base de código mais antiga que é ligeiramente diferente da moderna. E a solução que minimiza o risco muitas vezes pode ser (e geralmente é) aquela que consiste em criar um patch apenas para implementar uma determinada parte de um grande conjunto de alterações. Imagine um commit de 2.000 linhas que contém 5 linhas de código para corrigir um bug. Além disso, imagine que esse erro ocorreu após a refatoração da API. O que você escolheria:preparando um backport com base em um grande conjunto de mudanças, ou com base em patches bem documentados, bem documentados e quebrados? Eu, como pessoa que fez inúmeros backports, já sei como responderia a essa pergunta.
Bem, com ou sem backports, os projetos têm que pagar um preço alto pelos benefícios de serem organizados dessa forma, quando há grande ênfase em documentar cuidadosamente as mudanças. Agora, o programador precisa cuidar não apenas do código, mas também de como reorganizá-lo e alinhá-lo com as regras de trabalho no projeto.
Algumas dessas refatorações de código são simples. Digamos que estejamos falando sobre como usar o comando git add -p e escolher o que entrará em um lote de alterações. As coisas ficam um pouco mais complicadas quando um programador se depara com dependências circulares entre fragmentos de código individuais. Imagine uma função que retorna um objeto de um tipo que será adicionado ao projeto após adicionar esta função a ele. Para fazer frente a esta situação, você terá que usar código, que, como resultado, não entrará no projeto concluído, mas apenas desempenhará o papel de uma solução temporária.
Tudo isso adiciona dor de cabeça aos programadores, mas não se pode dizer que tais tarefas sejam completamente insolúveis. Suponha que você, com precisão cirúrgica, tenha dividido tudo o que faz em fragmentos que são fáceis e convenientes de usar. Os problemas reais começam depois que outros programadores começam a examinar seu código. A revisão do código em qualquer organização é muito importante. Os especialistas lêem o código de outra pessoa e sugerem (ou exigem) alterações nele.
Suponha que um programador foi solicitado a adicionar um novo parâmetro a um determinado método presente no primeiro patch de um conjunto de correções. E também vamos supor que esse método seja usado em todos os patches subsequentes.
Isso significa que o programador terá que voltar ao primeiro patch e adicionar um novo parâmetro ao método. Depois disso, os próximos patches não podem mais ser aplicados. Portanto, o programador não terá apenas que se perguntar por que isso acontece, mas também corrigir manualmente todos os erros. Se todos os patches individuais foram testados anteriormente, agora os resultados desses testes estão desatualizados e os patches terão que ser testados novamente.
Reorganizar o trabalho é um pequeno problema. Mas refazer o que já foi feito é um problema muito mais sério.
Aqui está o que eu gostaria de transmitir à comunidade de desenvolvedores Linux e àqueles que estão relacionados a esta comunidade: tudo isso, é claro, é bastante factível. Mas se isso não é uma barreira de entrada para jovens profissionais, então eu nem sei o que pode ser chamado de "barreira de entrada". A necessidade de gastar seu tempo, esforço, nervos e recursos de computador reorganizando, reescrevendo, retrabalhando o que já foi feito não é claramente o que os programadores estão buscando. A este respeito, me deparei com uma ideia que aparece periodicamente desta forma: "... mas um bom programador não terá problemas com isso." Também é expresso assim: "mas ensina aos programadores um certo estilo de pensamento, exatamente o tipo que um bom programador deveria ter." Esse tipo de raciocínio me parece insincero e não traz nenhum benefício. De fato:Acabei de listar todos os pontos fortes desse método, mas também acho que todas essas refatorações de código são tarefas enfadonhas e tediosas. Pode ser comparado a limpar um apartamento. Digamos que alguém diga que é muito bom manter a casa limpa (concordo com isso). A mesma pessoa é perfeitamente capaz de aspirar o chão (eu consigo), mas muitas vezes não o faz. A razão para isso é simples: ele tem outras coisas mais importantes para fazer. Por exemplo, é por isso que estou incrivelmente feliz por ter um aspirador de pó robô Roomba. Isso me permitiu desfrutar da limpeza e ao mesmo tempo não ter que me arrumar. O que me leva ao meu próximo pensamento, dirigido a pessoas fora do mundo Linux.que todas essas refatorações de código são tarefas enfadonhas e enfadonhas. Pode ser comparado a limpar um apartamento. Digamos que alguém diga que é muito bom manter a casa limpa (concordo com isso). A mesma pessoa é perfeitamente capaz de aspirar o chão (posso), mas muitas vezes não o faz. A razão para isso é simples: ele tem outras coisas mais importantes para fazer. Por exemplo, é por isso que estou incrivelmente feliz por ter um aspirador de pó robô Roomba. Isso me permitiu desfrutar da limpeza e ao mesmo tempo não ter que me arrumar. O que me leva ao meu próximo pensamento, dirigido a pessoas fora do mundo Linux.que todas essas refatorações de código são tarefas enfadonhas e enfadonhas. Pode ser comparado a limpar um apartamento. Digamos que alguém diga que é muito bom manter a casa limpa (concordo com isso). A mesma pessoa é perfeitamente capaz de aspirar o chão (posso), mas muitas vezes não o faz. A razão para isso é simples: ele tem outras coisas mais importantes para fazer. Por exemplo, é por isso que estou incrivelmente feliz por ter um aspirador de pó robô Roomba. Isso me permitiu desfrutar da limpeza e ao mesmo tempo não me envolver em colocar as coisas em ordem. O que me leva ao meu próximo pensamento, dirigido a pessoas fora do mundo Linux.A mesma pessoa é perfeitamente capaz de aspirar o chão (posso), mas muitas vezes não o faz. A razão para isso é simples: ele tem outras coisas mais importantes para fazer. Por exemplo, é por isso que estou incrivelmente feliz por ter um aspirador de pó robô Roomba. Isso me permitiu desfrutar da limpeza e ao mesmo tempo não ter que me arrumar. O que me leva ao meu próximo pensamento, dirigido a pessoas fora do mundo Linux.A mesma pessoa é perfeitamente capaz de aspirar o chão (posso), mas muitas vezes não o faz. A razão para isso é simples: ele tem outras coisas mais importantes para fazer. Por exemplo, é por isso que estou incrivelmente feliz por ter um aspirador de pó robô Roomba. Isso me permitiu desfrutar da limpeza e ao mesmo tempo não me envolver em colocar as coisas em ordem. O que me leva ao meu próximo pensamento, dirigido a pessoas fora do mundo Linux.destinado a pessoas fora do mundo Linux.dirigido a pessoas fora do mundo Linux.
Aqui está o que eu gostaria de dizer para aqueles de fora da comunidade Linux: Existem pontos fortes muito reais no processo de desenvolvimento usado para trabalhar no Linux. Alguma ferramenta não é capaz de lidar totalmente com a tarefa que está funcionando no Linux. O GitHub, por exemplo, faz um ótimo trabalho em projetos onde o novo código é sempre adicionado após o código existente. Você pode, é claro, usar o comando git push --force, forçosamente incluindo um certo branch no repositório, mas então os comentários anexados ao commit estarão, de fato, "suspensos no ar", e a discussão deste commit não terá sentido.
As ferramentas de desenvolvimento modernas simplificam muito. Eles permitem que você acione a execução de algumas ações quando certas condições ocorrem, eles suportam integração contínua e processos de implantação de projeto, notificam os programadores sobre mudanças no código e resolvem muitas outras tarefas. Mas eles certamente complicam o processo de decompor os resultados do trabalho de alguém em pequenas partes que são fáceis e convenientes de trabalhar. O uso de e-mails em texto simples complica muito, mas essa organização do trabalho, deve-se ressaltar, não interfere na aplicação de processos de desenvolvimento que levem a um objetivo específico.
Mesmo se fosse possível avaliar de forma objetiva e precisa quanto o ecossistema Linux teria ganhado e perdido (nada que teria perdido) abandonando o processo de desenvolvimento existente, isso dificilmente mudaria alguma coisa. O fato é que a situação atual ilustra perfeitamente a natureza humana, quando as pessoas se esforçam para preservar o que antes se mostrava muito bem na prática.
Existe uma maneira de sair dessa situação?
Acredito sinceramente que se tivéssemos à nossa disposição ferramentas que pudessem fornecer a diferentes organizações os mesmos benefícios que a comunidade Linux obtém de sua metodologia de desenvolvimento, isso seria muito benéfico para todos. E se tais ferramentas existissem, talvez até a comunidade Linux pudesse substituir e-mails de texto regulares por eles.
Não tenho resposta para a questão de como essas ferramentas podem ser. Mas vou me permitir dar uma chance e refletir um pouco sobre eles:
- Git — . , , , , . GitHub, - git-, «-» Linux, git, . , -, , , , . Git . CSS HTML, — , CSS HTML- . , HTML CSS? , , , .
- , , , , , . , , , ? . , : « create_foo() , create_bar()», : « create_bar() y, ». , , . , , , , GPT-3, , .
- , , , , - , . , , , . , , , , , , , , , .
-, Linux?
