مقدمة لتطوير حل مفتوح المصدر نموذجي

في 11 سبتمبر ، عقد Java Meetup في سانت بطرسبرغ ، مخصصًا بالكامل لـ Apache Ignite . شكرا جزيلا للمنظمين على الدعوة وفرصة التحدث عن Open Source بالنيابة عن مطور هذا المصدر المفتوح للغاية. نظرًا لرد الفعل الإيجابي للجمهور ، قررت مشاركة العرض التقديمي مع أولئك الذين لم يتمكنوا من حضور الاجتماع.

تحت القطع سوف تجد نسخة نصية من العرض التقديمي ، مليئة بالإدراك الذاتي للمصدر المفتوح ، سواء كانت إيجابية أو سلبية.




لذا ، اسمي أنطون فينوجرادوف ، وعلى مدى السنوات الأربع الماضية ، كنت أقوم بتطوير مشروع Apache Ignite مفتوح المصدر. باستخدام مثاله ، أود أن أتحدث عن كيفية عمل المصدر المفتوح ، وما هي الفوائد الشخصية التي يمكنك الحصول عليها من المشاركة في المجتمع ، وفي النهاية ، أريد أن ألهمك للمشاركة.




سأتحدث عن Open Source باستخدام مثال Apache Ignite - أحد المشاريع العديدة لمؤسسة Apache Software Foundation. ASF هي واحدة من أكبر مجتمعات المصادر المفتوحة مع ما يقرب من 20 عامًا من التاريخ. يعود الفضل في نجاحاتها ، أولاً وقبل كل شيء ، إلى عمليات ومبادئ التحفيز ، التي تم تحديدها منذ عام 1999 ، ولكنها لا تزال ذات صلة اليوم. تم وصف هذا الجانب "الفلسفي" من المجتمع بالتفصيل في مقاله بواسطة ديمتري بافلوف ، لكننا سننظر في الجانب "التطبيقي" لتطوير المصدر المفتوح باستخدام مثال Apache Ignite.

لنفترض أنك قررت المساهمة في تنمية المجتمع. كيف تفعل ذلك؟


بشكل عام ، لا يمكن للمرء أن يقول أن المصدر المفتوح يتعلق بالكود. يمكن أن تقدم العديد من الأنشطة المختلفة مساهمة كبيرة ، وبعضها فقط مرتبط مباشرة بالكود.

• إذا وجدت مشكلة - اذكرها في قائمة المستخدمين ، حيث سيتم حلها ؛
• إذا كنت جاهزًا ، يمكنك المشاركة في دراسة المهام في قائمة التطوير وتنسيق الإجراءات ؛
• إذا كنت مطورًا رائعًا ، فهذه فرصة لك لكتابة الكثير من التعليمات البرمجية الجيدة ؛
• والتي ستكون قادرة على مراجعة مراجع باردة ؛
• إذا كنت مديرًا جيدًا ، فيمكنك المساعدة في تحرير الإصدار ؛
• إذا كنت راويًا جيدًا أو مجرد معجب بالمشروع ، مثلي ، فيمكنك المشاركة في تعميم الحل.

أهم مساهمة في المصادر المفتوحة هي إعلام المجتمع بمشاكل المنتج وأوجه القصور فيه. ولكن هنا من المهم أن نفهم أن المصدر المفتوح ليس تطويرًا مخصصًا وأن المجتمع لا يدين لك بأي شيء. 90٪ من النجاح متروك لك. إذا وجدت مشكلة ، فإن مساهمتك في Open Source ستكون تحليلها المفصل والبحث عن الحلول. من المتوقع أن تشارك بنشاط في مناقشة المشكلة. إذا أبلغت عنها وغادرت ، فلن يتم حل المشكلة.

الخيار المثالي: جئت وتحدثت عن المشكلة وأنت على استعداد لدفع هذا الخيط إلى النهاية لحل المشكلة.

كل مشكلة تمت مناقشتها ، ولكن لم يتم حلها في قائمة المستخدمين ، تندرج في قائمة المطورين ، حيث يتم حلها. هنا ، يناقش المطورون كيفية تنفيذ ميزة أو إغلاق خطأ بشكل صحيح.


Devlist هو نوع من "مكان القوة" للمشروع حيث يمكنك التحدث مع المطورين الرائعين الذين يمكن أن يكسبوا الكثير من المال في التدريبات والندوات والاستشارات وكتابة المقالات. لكن هؤلاء الناس مشغولون بكتابة رمز حقيقي ، بالضبط الرمز الموجود الآن في طليعة التقدم. يبدو لي أنه ليس لديك ببساطة طريقة أخرى للتواصل مع هؤلاء الأشخاص ، باستثناء القائمة.

بالإضافة إلى ذلك ، قائمة المطورين هي مراسلات مدروسة ، حيث لديك الفرصة للتفكير لمدة ساعة أو ساعتين ثم فقط الرد برسالة ، على عكس الرسل ، حيث يصعب قراءة المراسلات وفهم كل شيء على مستوى العالم. حسب فهمي ، قائمة المطورين هي مجلة فنية متخصصة جيدة لا يمكنك قراءتها فحسب ، بل يمكنك أيضًا المشاركة المباشرة في إنشائها.

العمل في قائمة تطوير ، مثل أي عمل مفتوح المصدر ، علني. إذا قدمت أي مساهمة في ذلك ، فسيتم بحثها من قبل صاحب العمل أو الزملاء الحاليين أو المستقبليين. بالنسبة لي شخصياً ، عند تقييم مرشح للعمل ، فإن مشاركته في البكر أكثر أهمية من ملفه الشخصي على github. لا يميز الملف الشخصي على github سوى القدرة على كتابة التعليمات البرمجية ، كما أن الخبرة في قائمة devist تميز أيضًا تجربة تطوير الفريق. علاوة على ذلك ، مثل هذه التجربة حيث أنها مسؤولية فردية مهمة وليست جماعية. في رأيي ، هذه المهارة هي الأكثر أهمية لمطور جيد ، ويتم تطويرها بشكل أفضل عند التواصل مع الانحرافات في المصدر المفتوح.

نشرع مباشرة في التنمية.


بعد الموافقة على التحسينات في قائمة التطوير ، وعادة ما يتم الاتفاق على قرارات التصميم الأساسية ، تكون المهمة جاهزة للتنفيذ. يتم تنفيذ المهمة في الغالب من قبل نفس الأشخاص الذين اقترحوها وسلموها ، ولكن ليس دائمًا. لا يمكن إتقان شخص واحد من خلال بعض الميزات في فترة زمنية معقولة - خاصة إذا كانت ميزة في نصف Ignite.

إذا كنت مطورًا جيدًا ومستعدًا لمشاهدة المصدر المفتوح - تعال واختر إحدى المهام التي تم العمل عليها ، وقم بتنسيقها مع المؤلف وابدأ النشر.

في المصدر المفتوح ، جميع الاتصالات عامة. المناقشة إما في قائمة التطوير أو في أداة تتبع المشكلات. من المهم محاولة تجنب تنفيذ شيء ما دون مناقشة ، لأن هناك احتمال كبير لفعل شيء خاطئ. من الممارسات الجيدة توضيح جميع النقاط الرئيسية قبل بدء التطوير ، حتى لا تؤدي الكثير من العمل.

الآن عن المهم.

تطوير المصدر المفتوح مدرسة جيدة ومجانية. رائع للمطورين ، المحترفين في مجالهم ، يحللون المهام ، ويتيحون لك تنفيذها ، والمساعدة في أي صعوبات - وفي النهاية يظهر الالتزام الذي يميزك كمطور ممتاز. كما قلت ، يمكن أن يكون هذا جوجل ، وهذا جزء من محفظتك.

إذا كنت لا ترغب في بيع شيء ما مجانًا ، ضع في اعتبارك أن هذه المساهمة هي ، تقريبًا ، سجل الائتمان الخاص بك. يظهر لك أنك تفعل كل شيء بشكل صحيح ، ويمكنك كتابة التعليمات البرمجية ومناقشة المهام ، ومن السهل العمل معك.

لحظة خطيرة في تطوير المصدر المفتوح هي أنه يمكن لأي شخص الدخول إليها على الإطلاق. أعتقد أنه في كل مشروع مفتوح المصدر يوجد شخص يصرف الجميع لسنوات ، ثم يغادر دون تقديم أي مساهمة. ومن الجيد إذا غادر.

إن عدم كونك هذا الشخص هو مساهمة مهمة في مجتمع المصادر المفتوحة!

لذا ، قررت تقديم شيء في Open Source. من المحتمل أنه في المرة الأولى التي تفعل فيها كل شيء بشكل خاطئ. بمرور الوقت ، سوف تكتسب الخبرة التي ستساعدك على القيام بكل شيء بشكل صحيح - ولكن ليس في المرة الأولى.

في هذه الحالة ، ستساعدك المراجعة.


في معظم المشاريع (في Apache Ignite على وجه اليقين) ، تتم المراجعة قبل التنفيذ ، مما يسمح لك بالحفاظ على تنظيف وجبات الإفطار الرئيسية أو التطوير. ولدينا عدد من المتطلبات الأساسية التي يجب استيفاؤها قبل تقديم الرمز للمراجعة.

نمط الكود.
يحتوي المشروع على الكثير من التعليمات البرمجية ، وهو مكتوب من قبل أشخاص مختلفين ، بدوافع مختلفة وفي أوقات مختلفة. لو كانت مكتوبة بطرق مختلفة ، لكان من المستحيل قراءتها. لذلك ، فإن نمط الكود أساسي بالنسبة لنا. إذا قيل لك في مراجعة أنك بحاجة إلى سطر فارغ ، فهذا مهم.

يجب أن تمر كل ميزة من خلال الانحدار.
إذا كان المشروع كبيرًا ، فلن تخمن أبدًا كيف سيؤثر إكمالك الصغير على جميع الوظائف. حاليًا ، لدينا حوالي 50 ألف اختبار ، يتم تغطية كل ميزة بواحد أو أكثر. فيما يتعلق بالاختبارات الساقطة ، سيساعد الانحدار في تحديد أنك كسرت شيئًا ما. بالنسبة لك ، هذه طريقة جيدة لعدم التفكير كثيرًا وفهم كل شيء بسرعة - هل هناك انهيار أم لا. إذا تحدثنا عن تكاليف الاختبار ، فلدينا مجموعة من مائة آلة تعمل على تراجع وجبة غداء واحدة في ساعتين.

التغييرات في المجالات المادية.
إذا قمت بتغيير شيء ما في "الأساسية" - يجب أن تذهب من خلال قياس الأداء. بغض النظر عن مدى صعوبة وحل جميع المشاكل التي تواجهها الميزة ، إذا أدت إلى تفاقم زوج الإنتاجية / الكمون ، فلا يمكن دمجها. تدهور الأداء في منتجاتنا غير مقبول.

API
هناك نقطتان. لا يجب أن تكسر واجهة برمجة التطبيقات الجديدة تجميع أولئك الذين استخدموا الإصدار القديم من المنتج. ولا ينبغي أن تظهر الأساليب التي سيتم إيقافها في غضون شهرين. القيام بواجهة برمجة التطبيقات - افعل ذلك على الفور.

تعد مساهمة المراجع أهم مساهمات المصادر المفتوحة الأكثر صعوبة. المراجع هو الشخص المستعد لمساعدتك ، وفي بعض الحالات يقوم بما يصل إلى 90٪ من العمل. يدفع المراجع ، ويشرح ، ويكتب الرمز تقريبًا لك ، إذا لزم الأمر. تكمن المشكلة في أنه عندما تقع إحدى الميزات في عنصر رئيسي ، يتم إدراجها بواسطة المساهم وليس بواسطة المراجع. نقدر العمل المجاني للمراجع.

إذا كنت تعمل في مجتمع المصدر المفتوح ، فحاول أن تجعل المراجع مرتاحًا. القواعد الأساسية هي جعل الإصلاح عند أدنى حد ممكن ، ولكن واضح قدر الإمكان. إذا رأيت قبل المراجعة أنه يمكنك تقليل حجم الإصلاح وزيادة فهمه ، فقم بذلك.

الإصدار الحالي من Apache Ignite هو 2.6. تحدث الإطلاقات كل 3 أشهر تقريبًا.


تم إعداد الإصدار 2.7 من قبل موظف في Sbertekh Nikolai Izhikov ، لمدة عام تقريبًا الآن كمتعهد في المشروع. هذا حدث مهم للمشروع ، لأنه لأول مرة في تاريخه ، لا يتم تنفيذ الإصدار من قبل موظف في Gridgain ، الشركة التي أنشأت Apache Ignite ونقلته إلى ASF. هذا أمر جيد للغاية ، لأننا نتحرك نحو المصدر المفتوح المثالي ، عندما يكون المنتج غير مرتبط بشركة تجارية معينة ويكون موجودًا بشكل مستقل. نأمل أن تكون التجربة ناجحة ، وأن يتم تنفيذ الإصدارات القادمة بالفعل من قبل موظفي الشركات الأخرى ، والتي لدينا مفوضين منها - Trend Micro ، WhatsApp ، Nexign ، Aurea ، Pivotal ، Yahoo ، إلخ.


إن تعميم الحل - كما هو الحال في قائمة devlist - ليس مساهمة في المشروع فحسب ، بل أيضًا في نفسك. مثل هذه الأشياء غوغل وتؤثر على قرارات التوظيف. أيضًا ، هذه طريقة يمكنك من خلالها تأجيل الرمز لفترة من الوقت والقيام بشيء مثير للاهتمام ، ولكن ليس أقل فائدة.

ننتقل إلى السؤال الرئيسي: لماذا يستحق المشاركة في مشاريع مفتوحة المصدر؟


لن أتوقف عن التكرار: المشاركة في المصادر المفتوحة هي نموك السريع. وفقًا لملاحظاتي ، يستغرق الأمر حوالي ثلاث سنوات ، إن لم يكن أكثر ، مقارنة بالتطور التطبيقي. هذه فرصتك في مقابلة لصدم خصمك بعبارة "رأيت هذا الشيء ، أعرف بالضبط كيف يعمل ، لكنك مخطئ!" - فعلت ذلك مرتين ، التجربة لا تنسى.

يجب أن يراقب أي مبرمج جيد الاتجاهات. المصدر المفتوح هو الاتجاه الأكثر سخونة واعدة في عصرنا في تطوير البرمجيات. المشاركة في هذا الاتجاه تعطي ضمانة احترام من زملائك (الآن) وبعض الاستقرار والضمانات المالية (في المستقبل).


العديد من الشركات ليس لديها العديد من المصادر المفتوحة ، كما هو معتاد. تبحث العديد من الشركات عن موظفين لديهم خبرة أساسية في Open Source ، أو لمشروع محدد على أساس التفرغ. من المهم أن تمتلك الشركات خبرة داخلية في المشروع ، حتى تتمكن من التأثير على تطوره. على سبيل المثال ، قد تطلب منك الشركة إضافة أمان إلى منتج أو إصلاح خطأ موجود في إنتاجها فقط. ونفعل ذلك بسرعة ، وليس عندما يوافق المجتمع. إذا كانت لديك خبرة في العمل في Open Source أو في مشروع معين ، فستكون هذه ميزة تنافسية لك عند التوظيف أو الاستمرار في العمل في شركتك.

كدليل ، فريقنا ، الذي يقطع المصادر المفتوحة في Sberbank Technologies ، لديه شواغر مثيرة للاهتمام للغاية ( MSK و SPB ) و Apache Ignite ليس المنتج الوحيد الذي ننتهي منه.



آمل أن يكون الجميع مهتمين ، وأن يفكر الكثيرون في المشاركة في حركة المصدر المفتوح ، وأن ينتقل أولئك الذين فكروا في الأمر بالفعل إلى إجراءات ملموسة.

ملاحظة بالنسبة لأولئك الذين يحبون الصوت الدافئ والأنبوب - يتوفر إصدار صوتي من "Uncategorized".