من هاك تصحيح الجمعة إلى الإصدار: تأملات حول إنشاء وإصدار مشروع مفتوح المصدر

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

• تأملات (هذا)
• تعلم Go lang كمطور Java (TODO)
• ملفات الصحة والمجتمع مفتوحة المصدر (TODO)
• أمن المصدر المفتوح (TODO)

الاحتياجات

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

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

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

لذلك قررت إنشاء تطبيق CLI كامل له.

القرارات المسبقة التي يجب اتخاذها

هل توجد مثل هذه الأداة بالفعل؟

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

توجد أيضًا بعض الأدوات التجارية، لكنني شعرت أن هذه الأداة الصغيرة هي شيء يجب أن يكون موجودًا أيضًا في النماذج مفتوحة المصدر.

الخلاصة: كان هناك مكان لأداة CLI هذه في هذا العالم.

اختراقها في أيام العمل أو في أوقات الفراغ الخاصة؟

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

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

الخلاصة: يجب أن أفعل ذلك من أجل المتعة في وقت فراغي.

اختيار مكدس التكنولوجيا

لقد أمضيت معظم وقتي على مر السنين في عالم Java/Kotlin، مع عدد قليل من المشاريع في JS/TS، وPython/Ruby، ومثل أي مطور كبير، كنت أشارك في مشاريع أخرى في بعض الأحيان.
لفترة طويلة، كنت أرغب حقًا في تعلم Go و/أو Rust. لذلك ستكون هذه فرصة للحصول على الدافع للتعمق في لغة جديدة
سبب اختياري لـ Go هو أن عددًا لا بأس به من تطبيقات CLI في عالم DevOps مفتوح المصدر مكتوبة بها، وأريد أن أكون قادرًا على إرسال التصحيحات إلى مشاريع الطرف الثالث في بعض الأحيان. كما أن الكتابة بلغة Go تعني ثنائيًا واحدًا يحتوي على العديد من البنيات المستهدفة.

كان بإمكاني القيام بذلك في Java، على سبيل المثال، باستخدام Pico CLI وGraalVM حيث كان لدي انطباع جيد عنهما منذ المحاولات السابقة ولكني قررت أنني أريد حقًا أن أتعلم لغة Go بدلاً من ذلك.

الخلاصة: يجب أن أفعل ذلك في Go وأتعلم من ذلك.

أهداف التعلم الأخرى

مع هذا، أردت أيضًا التعمق في موضوعات تقديم مشروع مفتوح المصدر معبأ بشكل جيد، باتباع معظم الممارسات الأمنية - بطاقات الأداء، SLSA،

واستخدام أدوات مثل GoRelease لإنشاء إصدارات من أنواع مختلفة.

الخلاصة: اغتنم الفرصة للتعلم والتعمق في المواضيع التي تختارها.

احتفظ بالنطاق

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

الخلاصة: أطلق المشروع كألفا عندما تشعر بالحرج والفخر به بنفس القدر.

التقدير - ما مدى صعوبة ذلك؟

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

الخلاصة: اضرب تقدير وقتك بثلاثة عند تعلم مجموعات أساسية جديدة تتضمن التجريب. سيكون بناء جملة اللغة هو الشيء الصغير.

عملية الخلق

الالتزام الأولي

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

ولكن كما يعلم جميع كبار المطورين، فإن نجاح شيء ما هو عدة أميال من إطلاق المنتج.

قريباً، أليس كذلك؟ ليس حقيقيًا.

العثور على الوقت

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

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

الأشياء التي نسيتها

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

متلازمة المحتال تضرب

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

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

الطحن

حسنًا، ماذا يمكنني أن أقول - يتم ذلك عندما يتم ذلك.

كانت هناك بضع ليالٍ متأخرة من التصحيح، وإعادة البناء، ولكن أيضًا لحظات لا حصر لها من التدفق والدوبامين.

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

العواقب والدروس المستفادة

1. اضبط النطاق مبكرًا: قرر أين تتوقف. قم بإعداد هيكل المشروع والوثائق والإصدارات وخطوط الأنابيب وإرشادات المجتمع مبكرًا. المستقبل سوف تشكر ماضيك.

2. لا تتوتر، استمتع بعملية التعلم: يتم تنفيذها عند الانتهاء منها.

3. كن مثابرًا: المصدر المفتوح هو ماراثون، وليس سباق سريع. لا تحترق. إنها هواية وليست حياتك. ومع ذلك كن مثابرا. افعل شيئًا صغيرًا كل يوم.

4. تعلم، تعلم، تعلم: انظر إلى كل شيء كفرصة للتعلم والتحسين، وليس كمشكلة.

5. البرمجة هي الجزء السهل: الكود الرئيسي هو ما سيأخذك في أقل وقت؛ كل شيء آخر، مثل الوثائق والاختبارات وما إلى ذلك، هو المكان الذي يتم فيه قضاء الوقت.

6. قم بالإضافات: إنها ممتعة مثل البرمجة. نعم، حتى التوثيق يمكن أن يوفر عليك ساعات من الشرح وإعادة الشرح. اجعلها ممتعة إذا كنت تشعر بالملل. المستندات كرمز، vim-pong، وما إلى ذلك.

7. خذ فترات راحة: الإرهاق حقيقي. التراجع عندما تحتاج إلى ذلك. تمامًا مثل أي عملية تعلم إبداعية أخرى، قم بذلك على دفعات.

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

9. استمتع بالرحلة: إنه لأمر رائع أن تبدع.

10. أكمل: هناك ملايين المشاريع نصف المنجزة في هذا العالم. أكمله.

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

حسنًا، قرصنة سعيدة، والآن اذهب وفكر فيما تريد أن تفعله بعد ذلك!!

روابط

المشروع: Git Provider Sync