Introduction au développement d'une solution Open Source typique

Le 11 septembre, un Meetup Java s'est tenu à Saint-Pétersbourg, entièrement dédié à Apache Ignite . Un grand merci aux organisateurs pour l'invitation et l'opportunité de parler d'Open Source au nom du développeur de ce très Open Source. Compte tenu de la réaction positive du public, j'ai décidé de partager la présentation avec ceux qui n'ont pas pu assister à la réunion.

Sous la coupe, vous trouverez une version texte de la présentation, pleine de perception subjective de l'Open Source, à la fois positive et négative.




Donc, je m'appelle Anton Vinogradov et depuis 4 ans je développe le projet Open Source Apache Ignite. En utilisant son exemple, je veux parler de la façon dont l'Open Source est réalisé, des avantages personnels que vous pouvez retirer de votre participation à la communauté et, finalement, je veux vous inspirer à participer.




Je vais parler d'Open Source en utilisant l'exemple d'Apache Ignite - l'un des nombreux projets de la Apache Software Foundation. ASF est l'une des plus grandes communautés Open Source avec près de 20 ans d'histoire. Elle doit ses succès, tout d'abord, aux processus et principes de motivation, fixés dès 1999, mais toujours d'actualité. Ce côté "philosophique" de la communauté a été décrit en détail dans son article par Dmitry Pavlov , mais nous considérerons le côté "appliqué" du développement Open Source en utilisant l'exemple d'Apache Ignite.

Supposons que vous décidiez de contribuer au développement communautaire. Comment faire


En général, on ne peut pas dire que l'Open Source concerne le code. De nombreuses activités différentes peuvent apporter une contribution significative, et seules certaines d'entre elles sont directement liées au code.

• Si vous trouvez un problème - indiquez-le sur la liste des utilisateurs, où il sera résolu;
• Si vous êtes prêt, vous pouvez participer à l'étude des tâches sur la devlist et à la coordination des actions;
• Si vous êtes un développeur sympa, c'est l'occasion pour vous d'écrire beaucoup de bon code;
• Qui sera en mesure de réviser un critique cool;
• Si vous êtes un bon gestionnaire, vous pouvez aider à la publication de la version;
• Si vous êtes un bon conteur ou simplement un fan du projet, comme moi, alors vous pouvez vous engager dans la vulgarisation de la solution.

La contribution la plus importante à l'Open Source est d'informer la communauté sur les problèmes du produit et ses défauts. Mais ici, il est important de comprendre que l'Open Source n'est pas un développement personnalisé et que la communauté ne vous doit rien. 90% du succès dépend de vous. Si vous rencontrez un problème, votre contribution à l'Open Source sera son analyse détaillée et sa recherche de solutions. Il est prévu que vous participiez activement à la discussion du problème. Si vous le signalez et partez, le problème ne sera pas résolu.

Option idéale: vous êtes venu, avez parlé du problème et êtes prêt à conduire ce fil jusqu'au bout, pour résoudre le problème.

Chaque problème discuté, mais non résolu dans la liste des utilisateurs, tombe dans la liste de développement, où il est en cours d'élaboration. Ici, les développeurs discutent de la façon d'implémenter correctement une fonctionnalité ou de fermer un bogue.


Devlist est une sorte de «lieu de pouvoir» du projet où vous pouvez parler avec des développeurs sympas qui pourraient potentiellement gagner beaucoup d'argent lors de formations, séminaires, consultations, rédaction d'articles. Mais ces gens sont occupés à écrire du vrai code, exactement le code qui est maintenant à la pointe du progrès. Il me semble que vous n'avez tout simplement aucun autre moyen de communiquer avec ces personnes, sauf sur la liste de développement.

De plus, une devlist est une correspondance réfléchie, où vous avez la possibilité de réfléchir pendant une heure ou deux et de répondre ensuite par une lettre, contrairement aux messagers, où il est difficile de lire la correspondance et de tout comprendre globalement. À ma connaissance, un devlist est un si bon journal technique spécialisé que vous pouvez non seulement lire, mais aussi participer directement à sa création.

Le travail dans une liste de développement, comme tout travail en Open Source, est public. Si vous y apportez une contribution, celle-ci sera googlé par votre employeur ou vos collègues actuels / futurs. Pour moi personnellement, lors de l'évaluation d'un candidat à un emploi, sa participation dans les jeunes filles est plus importante que son profil sur le github. Un profil sur un github ne caractérise que la capacité d'écrire du code, et l'expérience sur une liste de développement caractérise également l'expérience du développement d'équipe. De plus, une telle expérience où il s'agit d'une responsabilité individuelle importante, et non collective. À mon avis, cette compétence est la plus importante pour un bon développeur, et elle est mieux développée lors de la communication en devists en Open Source.

Nous procédons directement au développement.


Après s'être mis d'accord sur des améliorations sur la liste de développement, et les décisions de conception généralement fondamentales sont convenues, la tâche est prête pour la mise en œuvre. La tâche est le plus souvent réalisée par les mêmes personnes qui l'ont proposée et livrée, mais pas toujours. Une personne ne peut pas être maîtrisée par certaines fonctionnalités dans un délai raisonnable - surtout s'il s'agit d'une fonctionnalité à moitié Ignite.

Si vous êtes un bon développeur et que vous êtes prêt à utiliser l'Open Source - venez choisir l'une des tâches élaborées, coordonnez-la avec l'auteur et commencez à scier.

En Open Source, toutes les communications sont publiques. La discussion se fait soit sur la liste de développement, soit dans le tracker de problème. Il est important d'essayer d'éviter de mettre en œuvre quelque chose sans discussion, car il y a une forte probabilité de faire quelque chose de mal. Il est recommandé de clarifier tous les points clés avant de commencer le développement, afin de ne pas faire trop de travail.

Maintenant sur l'important.

Le développement open source est une bonne école gratuite. Des développeurs sympas, des professionnels dans leur domaine, décomposent les tâches, vous permettent de les mettre en œuvre, vous aident avec toutes les difficultés - et finalement un commit apparaît qui vous caractérise comme un excellent développeur. Comme je l'ai dit, cela peut être googlé, cela fait partie de votre portefeuille.

Si vous ne voulez pas vendre quelque chose gratuitement, considérez que cette contribution est, en gros, votre historique de crédit. Cela montre que vous faites tout correctement, vous pouvez écrire du code et discuter des tâches, et c'est facile de travailler avec vous.

Un moment dangereux dans le développement Open Source est que tout le monde peut y participer. Je pense que dans chaque projet Open Source, il y a une personne qui distrait tout le monde pendant des années, puis part sans apporter aucune contribution. Et c'est bien s'il part.

Ne pas être cette personne est une contribution importante à la communauté Open Source!

Vous avez donc décidé de déposer quelque chose en Open Source. Il est probable que la première fois que vous faites tout mal. Au fil du temps, vous acquerrez une expérience qui vous aidera à tout faire correctement - mais pas la première fois.

Dans ce cas, l'examen vous aidera.


Dans la plupart des projets (dans Apache Ignite à coup sûr), la revue a lieu avant la validation, ce qui vous permet de garder les brunchs de master ou de développement propres. Et nous avons un certain nombre d'exigences fondamentales qui doivent être remplies avant que le code soit soumis pour examen.

Style de code.
Le projet a beaucoup de code, il est écrit par différentes personnes, avec des motivations différentes et à des moments différents. S'il avait été écrit de différentes manières, il aurait été impossible de le lire. Par conséquent, le style de code est fondamental pour nous. Si, dans un avis, on vous dit que vous avez besoin d'une ligne vide, c'est important.

Chaque fonctionnalité doit passer par une régression.
Si le projet est volumineux, vous ne devinerez jamais comment votre petit achèvement affectera toutes les fonctionnalités. Actuellement, nous avons environ 50 000 tests, chaque fonctionnalité est couverte par un ou plusieurs. En ce qui concerne les tests tombés, la régression aidera à déterminer que vous avez cassé quelque chose. Pour vous, c'est un bon moyen de ne pas trop penser et de tout comprendre rapidement - y a-t-il une panne ou non. Si nous parlons des coûts des tests, nous avons un cluster d'une centaine de machines qui exécutent une régression d'un brunch en deux heures.

Changements dans les domaines matériels.
Si vous changez quelque chose dans le «noyau» - vous devez passer par l'analyse comparative. Peu importe la difficulté et la résolution de tous les problèmes de la fonctionnalité, si elle aggrave la paire débit / latence, elle ne peut pas être fusionnée. La dégradation des performances de notre produit est inacceptable.

API
Il y a deux points. La nouvelle API ne doit pas interrompre la compilation de ceux qui ont utilisé l'ancienne version du produit. Et les méthodes ne devraient pas apparaître qui seront obsolètes dans quelques mois. Faire une API - faites-le tout de suite.

L'apport du critique est la plus importante des contributions open source les plus difficiles. Le réviseur est la personne qui est prête à vous aider, dans certains cas, il fait jusqu'à 90% du travail. Le réviseur pousse, explique, écrit presque du code pour vous, si nécessaire. Le problème est que lorsqu'une fonctionnalité tombe dans master, elle est répertoriée par le contributeur et non par le réviseur. Appréciez le travail gratuit de l'examinateur.

Si vous travaillez dans la communauté Open Source, essayez de mettre le réviseur à l'aise. Les règles de base sont de rendre le correctif aussi minimal que possible, mais aussi clair que possible. Si vous voyez avant l'examen que vous pouvez réduire le volume du correctif et augmenter sa compréhensibilité, faites-le.

La version actuelle d'Apache Ignite est 2.6. Les rejets se produisent environ tous les 3 mois.


La version 2.7 est en cours de préparation par un employé de Sbertekh Nikolai Izhikov, depuis près d'un an en tant que responsable du projet. Il s'agit d'un événement important pour le projet, car pour la première fois de son histoire, la libération n'est pas réalisée par un employé de Gridgain, la société qui a créé Apache Ignite et l'a transféré à ASF. C'est très bien, car nous nous dirigeons vers l'Open Source idéal, lorsque le produit est détaché d'une société commerciale spécifique et existe indépendamment. Nous espérons que l'expérience sera réussie, et les prochaines versions seront déjà réalisées par des employés d'autres sociétés, dont nous avons des commissaires - Trend Micro, WhatsApp, Nexign, Aurea, Pivotal, Yahoo, etc.


La vulgarisation de la solution - comme dans le cas de la devlist - est une contribution non seulement au projet, mais aussi à vous-même. Ces choses sont googlé et affectent les décisions d'embauche. De plus, c'est un moyen pour vous de reporter le code pendant un certain temps et de faire quelque chose d'intéressant, mais non moins utile.

Nous passons à la question principale: pourquoi vaut-il la peine de participer à des projets Open Source?


Je ne cesserai de répéter: la participation à l'Open Source est votre croissance rapide. Selon mes observations, c'est environ trois ans, sinon plus, par rapport au développement appliqué. C'est votre chance à une interview de choquer votre adversaire avec la phrase "J'ai vu cette chose, je sais exactement comment ça marche, mais tu as tort!" - Je l'ai fait deux fois, l'expérience est inoubliable.

Tout bon programmeur doit garder un œil sur les tendances. L'Open Source est la tendance la plus chaude et la plus prometteuse de notre temps dans le développement de logiciels. La participation à cette tendance donne une garantie de respect de vos collègues (en ce moment) et une certaine stabilité, des garanties financières (à l'avenir).


De nombreuses entreprises n'ont pas autant d'Open Source, comme on le pense généralement. De nombreuses entreprises sont à la recherche d'employés ayant fondamentalement une expérience en Open Source, ou pour un projet spécifique à temps plein. Il est important pour les entreprises d'avoir une expertise interne sur le projet, pour pouvoir influencer son développement. Par exemple, une entreprise peut vous demander d'ajouter de la sécurité à un produit ou de corriger un bogue qui n'existe que dans sa production. Et faites-le rapidement, pas lorsque la communauté est d'accord. Si vous avez une expérience de travail en Open Source ou dans un projet spécifique, ce sera un avantage compétitif pour vous lorsque vous embauchez ou continuez à travailler dans votre entreprise.

Pour preuve, notre équipe, qui coupe l'Open Source dans Sberbank Technologies, a des offres d'emploi extrêmement intéressantes ( MSK et SPB ) et Apache Ignite n'est pas le seul produit que nous finalisons.



J'espère que tout le monde était intéressé, et beaucoup penseront à participer au mouvement Open Source, et ceux qui y ont déjà pensé passeront à des actions concrètes.

Ps Pour ceux qui aiment le son chaud et le tube - une version audio de "Uncategorized" est disponible.