Einführung in die Entwicklung einer typischen Open Source-Lösung

Am 11. September fand in St. Petersburg ein Java-Meetup statt, das ausschließlich Apache Ignite gewidmet war . Vielen Dank an die Organisatoren für die Einladung und die Gelegenheit, im Namen des Entwicklers dieses Open Source über Open Source zu sprechen. Angesichts der positiven Reaktion des Publikums beschloss ich, die Präsentation mit denen zu teilen, die nicht an dem Treffen teilnehmen konnten.

Unter dem Schnitt finden Sie eine Textversion der Präsentation, die voller subjektiver Wahrnehmung von Open Source ist, sowohl positiv als auch negativ.




Mein Name ist also Anton Vinogradov und ich habe in den letzten 4 Jahren das Open Source Apache Ignite-Projekt entwickelt. Anhand seines Beispiels möchte ich darüber sprechen, wie Open Source gemacht wird, welche persönlichen Vorteile Sie aus der Teilnahme an der Community ziehen können, und letztendlich möchte ich Sie zur Teilnahme inspirieren.




Ich werde am Beispiel von Apache Ignite - einem der vielen Projekte der Apache Software Foundation - über Open Source sprechen. ASF ist eine der größten Open Source-Communities mit einer fast 20-jährigen Geschichte. Sie verdankt ihre Erfolge vor allem den bereits 1999 festgelegten, aber bis heute relevanten Motivationsprozessen und -prinzipien. Diese "philosophische" Seite der Community wurde in seinem Artikel von Dmitry Pavlov ausführlich beschrieben, aber wir werden die "angewandte" Seite der Open Source-Entwicklung am Beispiel von Apache Ignite betrachten.

Angenommen, Sie möchten zur Entwicklung der Community beitragen. Wie kann man das machen?


Im Allgemeinen kann man nicht sagen, dass es bei Open Source um Code geht. Viele verschiedene Aktivitäten können einen wesentlichen Beitrag leisten, und nur einige von ihnen stehen in direktem Zusammenhang mit dem Code.

• Wenn Sie ein Problem finden, geben Sie es in der Benutzerliste an, wo es ausgearbeitet wird.
• Wenn Sie bereit sind, können Sie am Studium der Aufgaben auf der Devlist und an der Koordination der Aktionen teilnehmen.
• Wenn Sie ein cooler Entwickler sind, ist dies eine Gelegenheit für Sie, viel guten Code zu schreiben.
• Welches wird in der Lage sein, einen coolen Rezensenten zu überarbeiten;
• Wenn Sie ein guter Manager sind, können Sie bei der Veröffentlichung der Veröffentlichung helfen.
• Wenn Sie wie ich ein guter Geschichtenerzähler oder nur ein Fan des Projekts sind, können Sie die Lösung bekannt machen.

Der wichtigste Beitrag zu Open Source besteht darin, die Community über die Probleme des Produkts und seine Mängel zu informieren. Aber hier ist es wichtig zu verstehen, dass Open Source keine benutzerdefinierte Entwicklung ist und die Community Ihnen nichts schuldet. 90% des Erfolgs liegt bei Ihnen. Wenn Sie ein Problem finden, besteht Ihr Beitrag zu Open Source in der detaillierten Analyse und Suche nach Lösungen. Es wird erwartet, dass Sie sich aktiv an der Diskussion des Problems beteiligen. Wenn Sie es melden und gehen, wird das Problem nicht gelöst.

Ideale Option: Sie sind gekommen, haben über das Problem gesprochen und sind bereit, diesen Thread bis zum Ende zu führen, um das Problem zu lösen.

Jedes besprochene, aber in der Benutzerliste nicht gelöste Problem fällt in die Devlist, in der es ausgearbeitet wird. Hier diskutieren Entwickler, wie eine Funktion ordnungsgemäß implementiert oder ein Fehler geschlossen werden kann.


Devlist ist eine Art "Ort der Macht" des Projekts, an dem Sie mit coolen Entwicklern sprechen können, die möglicherweise viel Geld bei Schulungen, Seminaren, Konsultationen und beim Schreiben von Artikeln verdienen könnten. Aber diese Leute sind damit beschäftigt, echten Code zu schreiben, genau den Code, der jetzt auf dem neuesten Stand des Fortschritts ist. Es scheint mir, dass Sie einfach keine andere Möglichkeit haben, mit diesen Leuten zu kommunizieren, außer auf der Devlist.

Darüber hinaus ist eine Devlist eine nachdenkliche Korrespondenz, bei der Sie die Möglichkeit haben, ein oder zwei Stunden nachzudenken und erst dann mit einem Brief zu antworten, im Gegensatz zu Boten, bei denen es schwierig ist, die Korrespondenz zu lesen und alles global zu verstehen. Nach meinem Verständnis ist eine Devlist eine so gute Fachzeitschrift, dass Sie sie nicht nur lesen, sondern auch direkt an ihrer Erstellung beteiligen können.

Die Arbeit in einer Devlist ist wie jede Arbeit in Open Source öffentlich. Wenn Sie einen Beitrag dazu leisten, wird dieser von Ihrem derzeitigen / zukünftigen Arbeitgeber oder Ihren Kollegen gegoogelt. Für mich persönlich ist bei der Bewertung eines Kandidaten für eine Anstellung seine Teilnahme an den Mädchen wichtiger als sein Profil auf dem Github. Ein Profil auf einem Github kennzeichnet nur die Fähigkeit, Code zu schreiben, und die Erfahrung auf einer Devlist kennzeichnet auch die Erfahrung der Teamentwicklung. Darüber hinaus ist eine solche Erfahrung, wo es wichtig ist, individuelle Verantwortung und nicht kollektiv. Meiner Meinung nach ist diese Fähigkeit für einen guten Entwickler am wichtigsten und wird am besten für die Kommunikation mit Entwicklern in Open Source entwickelt.

Wir gehen direkt zur Entwicklung über.


Nachdem Sie sich auf Verbesserungen an der Devlist geeinigt haben und in der Regel grundlegende Entwurfsentscheidungen getroffen wurden, ist die Aufgabe zur Implementierung bereit. Die Aufgabe wird meistens von denselben Personen ausgeführt, die sie vorgeschlagen und ausgeführt haben, jedoch nicht immer. Eine Person kann von einigen Funktionen nicht in angemessener Zeit beherrscht werden - insbesondere, wenn es sich um eine Funktion in der Hälfte von Ignite handelt.

Wenn Sie ein guter Entwickler sind und bereit sind, Open Source zu sägen, wählen Sie eine der ausgearbeiteten Aufgaben aus, koordinieren Sie sie mit dem Autor und beginnen Sie mit dem Sägen.

In Open Source sind alle Kommunikationen öffentlich. Die Diskussion befindet sich entweder auf der Devlist oder im Issue Tracker. Es ist wichtig zu vermeiden, dass etwas ohne Diskussion implementiert wird, da die Wahrscheinlichkeit hoch ist, dass etwas falsch gemacht wird. Es empfiehlt sich, vor Beginn der Entwicklung alle wichtigen Punkte zu klären, um nicht zu viel Arbeit zu leisten.

Nun zum Wichtigen.

Open Source Development ist eine gute und freie Schule. Coole Entwickler, Fachleute auf ihrem Gebiet, zerlegen Aufgaben, ermöglichen es Ihnen, sie zu implementieren, helfen bei Schwierigkeiten - und letztendlich erscheint ein Commit, das Sie als exzellenten Entwickler auszeichnet. Wie gesagt, das kann gegoogelt werden, das ist Teil Ihres Portfolios.

Wenn Sie etwas nicht kostenlos verkaufen möchten, denken Sie daran, dass dieser Beitrag grob gesagt Ihre Kreditwürdigkeit ist. Es zeigt, dass Sie alles richtig machen, Code schreiben und Aufgaben diskutieren können und es einfach ist, mit Ihnen zu arbeiten.

Ein gefährlicher Moment in der Open Source-Entwicklung ist, dass absolut jeder darauf eingehen kann. Ich denke, dass es in jedem Open Source-Projekt eine Person gibt, die alle jahrelang ablenkt und dann geht, ohne einen Beitrag zu leisten. Und es ist gut, wenn er geht.

Nicht diese Person zu sein ist ein wichtiger Beitrag für die Open Source Community!

Sie haben sich also entschlossen, etwas in Open Source abzulegen. Es ist wahrscheinlich, dass Sie beim ersten Mal alles falsch machen. Mit der Zeit werden Sie Erfahrungen sammeln, die Ihnen helfen, alles richtig zu machen - aber nicht beim ersten Mal.

In diesem Fall hilft Ihnen die Überprüfung.


In den meisten Projekten (sicher in Apache Ignite) erfolgt die Überprüfung vor dem Festschreiben, sodass Sie den Master- oder Entwicklungsbrunch sauber halten können. Und wir haben eine Reihe grundlegender Anforderungen, die erfüllt sein müssen, bevor der Code zur Überprüfung eingereicht wird.

Codestil.
Das Projekt hat viel Code, es wird von verschiedenen Leuten geschrieben, mit verschiedenen Motivationen und zu verschiedenen Zeiten. Wenn es anders geschrieben worden wäre, wäre es unmöglich gewesen zu lesen. Daher ist der Codestil für uns von grundlegender Bedeutung. Wenn Ihnen in einer Überprüfung mitgeteilt wird, dass Sie eine leere Zeile benötigen, ist dies wichtig.

Jedes Feature muss eine Regression durchlaufen.
Wenn das Projekt groß ist, werden Sie nie erraten, wie sich Ihre kleine Fertigstellung auf alle Funktionen auswirkt. Derzeit haben wir ungefähr 50.000 Tests, wobei jede Funktion von einem oder mehreren abgedeckt wird. In Bezug auf gefallene Tests hilft die Regression festzustellen, dass Sie etwas kaputt gemacht haben. Für Sie ist dies eine gute Möglichkeit, nicht zu viel nachzudenken und schnell alles zu verstehen - gibt es eine Panne oder nicht. Wenn wir über die Testkosten sprechen, haben wir eine Gruppe von ~ hundert Maschinen, die eine Regression von einem Brunch in zwei Stunden ausführen.

Änderungen in Materialbereichen.
Wenn Sie etwas im "Kern" ändern, müssen Sie das Benchmarking durchlaufen. Unabhängig davon, wie schwierig und problematisch das Feature ist, kann es nicht zusammengeführt werden, wenn es das Durchsatz- / Latenzpaar verschlechtert. Leistungseinbußen bei unserem Produkt sind nicht akzeptabel.

API
Es gibt zwei Punkte. Die neue API sollte die Kompilierung derjenigen, die die alte Version des Produkts verwendet haben, nicht beschädigen. Und es sollten keine Methoden erscheinen, die in ein paar Monaten veraltet sein werden. API erstellen - sofort ausführen.

Der Beitrag des Rezensenten ist der wichtigste der schwierigsten Open-Source-Beiträge. Der Prüfer ist die Person, die bereit ist, Ihnen zu helfen. In einigen Fällen erledigt er bis zu 90% der Arbeit. Der Prüfer drückt, erklärt, schreibt bei Bedarf fast Code für Sie. Das Problem ist, dass ein Feature, wenn es in den Master fällt, vom Mitwirkenden und nicht vom Prüfer aufgelistet wird. Schätzen Sie die unentgeltliche Arbeit des Rezensenten.

Wenn Sie in der Open Source-Community arbeiten, versuchen Sie, den Prüfer komfortabel zu machen. Die Grundregeln bestehen darin, die Korrektur so gering wie möglich, aber so klar wie möglich zu gestalten. Wenn Sie vor der Überprüfung feststellen, dass Sie das Volumen des Fixes reduzieren und dessen Verständlichkeit verbessern können, tun Sie dies.

Die aktuelle Version von Apache Ignite ist 2.6. Veröffentlichungen erfolgen ungefähr alle 3 Monate.


Release 2.7 wird von einem Mitarbeiter von Sbertekh Nikolai Izhikov vorbereitet, der seit fast einem Jahr als Committer im Projekt tätig ist. Dies ist ein wichtiges Ereignis für das Projekt, da die Veröffentlichung zum ersten Mal in seiner Geschichte nicht von einem Mitarbeiter von Gridgain durchgeführt wird, dem Unternehmen, das Apache Ignite erstellt und an ASF übertragen hat. Dies ist sehr gut, da wir uns dem idealen Open Source nähern, wenn das Produkt von einem bestimmten Handelsunternehmen getrennt ist und unabhängig existiert. Wir hoffen, dass die Erfahrung erfolgreich sein wird und die nächsten Veröffentlichungen bereits von Mitarbeitern anderer Unternehmen durchgeführt werden, von denen wir Beauftragte haben - Trend Micro, WhatsApp, Nexign, Aurea, Pivotal, Yahoo usw.


Die Popularisierung der Lösung - wie im Fall der Devlist - ist nicht nur ein Beitrag zum Projekt, sondern auch zu sich selbst. Solche Dinge werden gegoogelt und wirken sich auf Einstellungsentscheidungen aus. Auf diese Weise können Sie den Code auch für eine Weile verschieben und etwas Interessantes, aber nicht weniger Nützliches tun.

Wir wenden uns der Hauptfrage zu: Warum lohnt es sich, an Open Source-Projekten teilzunehmen?


Ich werde nicht aufhören zu wiederholen: Die Teilnahme an Open Source ist Ihr schnelles Wachstum. Nach meinen Beobachtungen sind es im Vergleich zur angewandten Entwicklung ungefähr drei Jahre, wenn nicht mehr. Dies ist Ihre Chance bei einem Interview, Ihren Gegner mit dem Satz zu schockieren: "Ich habe dieses Ding gesehen, ich weiß genau, wie es funktioniert, aber Sie liegen falsch!" - Ich habe das zweimal gemacht, die Erfahrung ist unvergesslich.

Jeder gute Programmierer sollte Trends im Auge behalten. Open Source ist der heißeste und vielversprechendste Trend unserer Zeit in der Softwareentwicklung. Die Teilnahme an diesem Trend garantiert Ihren Kollegen (im Moment) Respekt und finanzielle Stabilität (in Zukunft).


Viele Unternehmen haben nicht so viele Open Source, wie allgemein angenommen wird. Viele Unternehmen suchen Mitarbeiter mit grundlegender Erfahrung in Open Source oder für ein bestimmtes Projekt auf Vollzeitbasis. Für Unternehmen ist es wichtig, über internes Know-how für das Projekt zu verfügen, um dessen Entwicklung beeinflussen zu können. Beispielsweise kann ein Unternehmen Sie auffordern, einem Produkt Sicherheit hinzuzufügen oder einen Fehler zu beheben, der nur in seiner Produktion vorhanden ist. Und mach es schnell, nicht wenn die Community zustimmt. Wenn Sie Erfahrung in Open Source oder in einem bestimmten Projekt haben, ist dies ein Wettbewerbsvorteil für Sie, wenn Sie in Ihrem Unternehmen einstellen oder weiterarbeiten.

Als Beweis hat unser Team, das Open Source in Sberbank Technologies schneidet, äußerst interessante Stellen ( MSK und SPB ) und Apache Ignite ist nicht das einzige Produkt, das wir finalisieren.



Ich hoffe, alle waren interessiert, und viele werden darüber nachdenken, an der Open Source-Bewegung teilzunehmen, und diejenigen, die bereits darüber nachgedacht haben, werden konkrete Maßnahmen ergreifen.

Ps Für diejenigen, die Warm- und Röhrensound mögen - eine Audioversion von „Uncategorized“ ist verfügbar.