Introdução ao desenvolvimento de uma solução típica de código aberto

Em 11 de setembro, um Java Meetup foi realizado em São Petersburgo, dedicado inteiramente ao Apache Ignite . Muito obrigado aos organizadores pelo convite e pela oportunidade de falar sobre o código aberto em nome do desenvolvedor deste mesmo código aberto. Dada a reação positiva do público, decidi compartilhar a apresentação com aqueles que não puderam participar da reunião.

Abaixo do corte, você encontrará uma versão em texto da apresentação, cheia de percepção subjetiva de código aberto, tanto positiva quanto negativa.




Então, meu nome é Anton Vinogradov e, nos últimos 4 anos, desenvolvo o projeto Open Source Apache Ignite. Usando o exemplo dele, quero falar sobre como o Open Source é feito, que benefícios pessoais você pode obter ao participar da comunidade e, finalmente, quero inspirá-lo a participar.




Vou falar sobre código aberto usando o exemplo do Apache Ignite - um dos muitos projetos da Apache Software Foundation. A ASF é uma das maiores comunidades de código aberto com quase 20 anos de história. Ele deve seus sucessos, em primeiro lugar, aos processos e princípios de motivação, estabelecidos em 1999, mas ainda hoje relevantes. Esse lado "filosófico" da comunidade foi descrito em detalhes em seu artigo por Dmitry Pavlov , mas consideraremos o lado "aplicado" do desenvolvimento de código aberto usando o exemplo do Apache Ignite.

Suponha que você decida contribuir com o desenvolvimento da comunidade. Como fazer isso?


Em geral, não se pode dizer que Código Aberto seja sobre código. Muitas atividades diferentes podem dar uma contribuição significativa e apenas algumas delas estão diretamente relacionadas ao código.

• Se você encontrar um problema - indique-o na lista de usuários, onde será resolvido;
• Se você estiver pronto, poderá participar do estudo de tarefas na lista de desenvolvedores e na coordenação de ações;
• Se você é um desenvolvedor legal, esta é uma oportunidade para você escrever muitos códigos bons;
• O qual poderá revisar um revisor legal;
• Se você é um bom gerente, pode ajudar com o lançamento do lançamento;
• Se você é um bom contador de histórias ou apenas um fã do projeto, como eu, pode se popularizar.

A contribuição mais importante para o Open Source é informar a comunidade sobre os problemas do produto e suas deficiências. Mas aqui é importante entender que o código aberto não é um desenvolvimento personalizado e a comunidade não deve nada a você. 90% do sucesso depende de você. Se você encontrar um problema, sua contribuição para o Open Source será a análise detalhada e a busca de soluções. Espera-se que você participe ativamente da discussão do problema. Se você denunciar e sair, o problema não será resolvido.

Opção ideal: você veio, falou sobre o problema e está pronto para conduzir esse segmento até o fim, para resolver o problema.

Cada problema discutido, mas não resolvido na lista de usuários, entra na lista devista, onde está sendo resolvido. Aqui, os desenvolvedores discutem como implementar adequadamente um recurso ou fechar um bug.


O Devlist é um tipo de "lugar de poder" do projeto, no qual você pode conversar com desenvolvedores legais que poderiam potencialmente ganhar muito dinheiro em treinamentos, seminários, consultas e artigos de redação. Mas essas pessoas estão ocupadas escrevendo código real, exatamente o código que está agora na vanguarda do progresso. Parece-me que você simplesmente não tem outra maneira de se comunicar com essas pessoas, exceto no devlist.

Além disso, um devlist é uma correspondência ponderada, onde você tem a oportunidade de pensar por uma hora ou duas e só então responder com uma carta, ao contrário de mensageiros, onde é difícil ler a correspondência e entender tudo globalmente. No meu entendimento, um devlist é um diário técnico especializado tão bom que você não apenas pode ler, mas também participa diretamente de sua criação.

O trabalho em uma lista de devedores, como qualquer trabalho em código aberto, é público. Se você fizer alguma contribuição, ela será pesquisada pelo seu atual / futuro empregador ou colegas. Para mim, pessoalmente, ao avaliar um candidato a emprego, sua participação nas donzelas é mais importante que seu perfil no github. Um perfil no github caracteriza apenas a capacidade de escrever código, e a experiência em um devlist também caracteriza a experiência do desenvolvimento da equipe. Além disso, uma experiência em que é importante responsabilidade individual e não coletiva. Na minha opinião, essa habilidade é mais importante para um bom desenvolvedor, e é melhor desenvolvida ao se comunicar em desvistas em código aberto.

Prosseguimos diretamente para o desenvolvimento.


Depois de concordar com as melhorias na lista de devedores, e geralmente as decisões fundamentais de design são acordadas, a tarefa está pronta para implementação. A tarefa geralmente é realizada pelas mesmas pessoas que a propuseram e entregaram, mas nem sempre. Uma pessoa não pode ser dominada por alguns recursos em um período de tempo razoável - especialmente se for um recurso na metade do Ignite.

Se você é um bom desenvolvedor e está pronto para ver o Código Aberto - venha e escolha uma das tarefas elaboradas, coordene-o com o autor e comece a serrar.

No código aberto, todas as comunicações são públicas. A discussão está na lista de devedores ou no rastreador de problemas. É importante tentar evitar implementar algo sem discussão, porque há uma alta probabilidade de fazer algo errado. É uma boa prática esclarecer todos os pontos-chave antes de iniciar o desenvolvimento, para não fazer muito trabalho.

Agora sobre o importante.

O desenvolvimento de código aberto é uma escola boa e gratuita. Desenvolvedores legais, profissionais em seu campo, decompõem tarefas, permitem implementá-las, ajudam com qualquer dificuldade - e, finalmente, aparece um commit que o caracteriza como um excelente desenvolvedor. Como eu disse, isso pode ser pesquisado no Google, isso faz parte do seu portfólio.

Se você não deseja vender algo de graça, considere que essa contribuição é, grosso modo, o seu histórico de crédito. Isso mostra que você está fazendo tudo certo, pode escrever código e discutir tarefas, e é fácil trabalhar com você.

Um momento perigoso no desenvolvimento de código aberto é que absolutamente qualquer um pode entrar nele. Eu acho que em todo projeto de código aberto existe uma pessoa que distrai todos por anos e depois sai sem dar qualquer contribuição. E é bom se ele sair.

Não ser essa pessoa é uma contribuição importante para a comunidade Open Source!

Então, você decidiu arquivar algo em código aberto. É provável que a primeira vez que você faça tudo errado. Com o tempo, você ganhará experiência que o ajudará a fazer tudo certo - mas não na primeira vez.

Nesse caso, a revisão o ajudará.


Na maioria dos projetos (no Apache Ignite, com certeza), a revisão ocorre antes da consolidação, o que permite manter limpas as brunches do mestre ou do desenvolvimento. E temos vários requisitos fundamentais que devem ser atendidos antes que o código seja enviado para revisão.

Estilo de código.
O projeto tem muito código, é escrito por pessoas diferentes, com motivações diferentes e em momentos diferentes. Se tivesse sido escrito de maneiras diferentes, seria impossível ler. Portanto, o estilo do código é fundamental para nós. Se você for informado em uma revisão que precisa de uma linha vazia, isso é importante.

Cada recurso deve passar por uma regressão.
Se o projeto for grande, você nunca imaginará como sua pequena conclusão afetará toda a funcionalidade. Atualmente, temos cerca de 50 mil testes, cada recurso é coberto por um ou mais. Em relação aos testes reprovados, a regressão ajudará a determinar que você quebrou alguma coisa. Para você, essa é uma boa maneira de não pensar muito e entender tudo rapidamente - há um colapso ou não. Se falarmos sobre os custos dos testes, temos um cluster de ~ cem máquinas que executam uma regressão de um brunch em duas horas.

Mudanças nas áreas materiais.
Se você alterar algo no "núcleo" - deverá passar pelo benchmarking. Não importa o quão difícil e resolva todos os problemas o recurso seja, se ele piorar o par de taxa de transferência / latência, ele não poderá ser mesclado. A degradação do desempenho em nosso produto é inaceitável.

API
Existem dois pontos. A nova API não deve interromper a compilação daqueles que usaram a versão antiga do produto. E não devem aparecer métodos que serão descontinuados em alguns meses. Fazendo uma API - faça-o imediatamente.

A contribuição do revisor é a mais importante das contribuições de código aberto mais difíceis. O revisor é a pessoa que está pronta para ajudá-lo; em alguns casos, ele realiza até 90% do trabalho. O revisor envia, explica, quase escreve código para você, se necessário. O problema é que, quando um recurso entra no mestre, ele é listado pelo colaborador e não pelo revisor. Aprecie o trabalho gratuito do revisor.

Se você trabalha na comunidade Open Source, tente tornar o revisor confortável. As regras básicas são tornar a correção o mais mínima possível, mas o mais clara possível. Se você vir antes da revisão que pode reduzir o volume da correção e aumentar sua compreensibilidade, faça-o.

A versão atual do Apache Ignite é 2.6. As liberações ocorrem aproximadamente a cada 3 meses.


A versão 2.7 está sendo preparada por um funcionário da Sbertekh Nikolai Izhikov, há quase um ano como colaborador do projeto. Este é um evento significativo para o projeto, pois pela primeira vez em sua história o lançamento não é realizado por um funcionário da Gridgain, a empresa que criou o Apache Ignite e o transferiu para o ASF. Isso é muito bom, porque estamos caminhando para o Código Aberto ideal, quando o produto é desatado de uma empresa comercial específica e existe de forma independente. Esperamos que a experiência seja bem-sucedida e os próximos lançamentos já sejam realizados por funcionários de outras empresas, das quais temos comissários - Trend Micro, WhatsApp, Nexign, Aurea, Pivotal, Yahoo, etc.


A popularização da solução - como no caso da devlist - é uma contribuição não apenas para o projeto, mas também para você. Essas coisas são pesquisadas e afetam as decisões de contratação. Além disso, é uma maneira de adiar o código por um tempo e fazer algo interessante, mas não menos útil.

Passamos à questão principal: por que vale a pena participar de projetos de código aberto?


Não vou parar de repetir: a participação no código aberto é seu rápido crescimento. De acordo com minhas observações, são cerca de três anos, se não mais, em comparação com o desenvolvimento aplicado. Esta é sua chance de uma entrevista chocar seu oponente com a frase "Eu vi essa coisa, eu sei exatamente como ela funciona, mas você está errado!" - Fiz isso duas vezes, a experiência é inesquecível.

Qualquer bom programador deve ficar de olho nas tendências. O código-fonte aberto é a tendência mais quente e promissora do nosso tempo no desenvolvimento de software. A participação nessa tendência garante o respeito de seus colegas (agora) e alguma estabilidade, garantias financeiras (no futuro).


Muitas empresas não possuem tantos Open Source, como normalmente se pensa. Muitas empresas procuram funcionários fundamentalmente com experiência em código aberto ou um projeto específico em período integral. É importante que as empresas tenham experiência interna no projeto, para poder influenciar seu desenvolvimento. Por exemplo, uma empresa pode solicitar que você adicione segurança a um produto ou corrija um bug existente apenas em sua produção. E faça isso rapidamente, não quando a comunidade concordar. Se você tem experiência trabalhando em código aberto ou em um projeto específico, isso será uma vantagem competitiva para você ao contratar ou continuar trabalhando na sua empresa.

Como evidência, nossa equipe, que está cortando o código-fonte aberto na Sberbank Technologies, possui vagas extremamente interessantes ( MSK e SPB ) e o Apache Ignite não é o único produto que estamos finalizando.



Espero que todos estejam interessados, e muitos pensem em participar do movimento Open Source, e aqueles que já pensaram sobre o assunto passem a ações concretas.

Ps Para quem gosta de som quente e de tubo - está disponível uma versão em áudio de "Sem categoria".