صحيح ، طوال هذا الوقت ، ظل شيء ما على حاله. على وجه التحديد ، يتم إرسال الرمز إلى قائمة بريدية (أو عدة قوائم) ، وهناك تتم مراجعتها ومناقشتها حتى يتم اعتبارها جاهزة للتضمين في Linux kernel. ولكن على الرغم من حقيقة أن عملية العمل مع الكود هذه قد تم استخدامها بنجاح لسنوات عديدة ، فقد تعرضت لانتقادات مستمرة على سبيل المثال ، هذا
أحدث مقال نشرته مؤخراً سارة نوفوتني من مايكروسوفت ضجة كبيرة على الإنترنت. ذكرت تلك المقالة أن تقنيات التعاون في التعليمات البرمجية المستخدمة في تطوير نواة لينكس قديمة. تقول إنه إذا أراد مجتمع مطوري Linux جذب المهنيين الشباب إلى صفوفه ، فسيكون من الجيد استبدال هذه الأساليب بشيء أكثر حداثة. في الجدل الدائر حول هذه الأفكار ، اشتبك المدافعون عنهم وخصومهم.
أعتقد أن موقفي يسمح لي بتقديم بعض الأفكار المتعلقة بتطوير نواة لينكس. منذ ما يقرب من عشر سنوات ، كنت أكتب تعليمات برمجية لنظام Linux ومشاريع أخرى منظمة بطريقة مماثلة. عندما كنت في Red Hat ، ساهمت في كود البنية التحتية للنواة x86 ، و KVM Hypervisor ، ورمز محاكي QEMU ، وكود Xen Hypervisor. كما شاركت في تطوير مشاريع أخرى. لم أفعل الكثير من نظام Linux لمدة 7 سنوات تقريبًا ، ولكن فقط بسبب حقيقة أنني كرست وقتي للعمل على إطار عمل C ++ Seastar وقاعدة بيانات ScyllaDB... تم تطوير كلا المشروعين باستخدام منهجية مشابهة جدًا لتلك المستخدمة في تطوير Linux. أنا الآن أعمل كمهندس رئيسي في شركة Datadog ، وهي شركة تكون فيها عمليات تطوير البرامج معاكسة تمامًا لتلك المستخدمة في Linux. هذا أقرب بكثير إلى كيفية تنظيم التطوير في شركات الويب الأخرى.
إذن إلى أي جانب أنا؟ اسمحوا لي أن أوضح على الفور أنني لا أحب عملية تطوير Linux. أنا متأكد تمامًا من أن هذا لا يمثل عائقًا أمام المطورين الجدد فحسب ، بل يمثل أيضًا عائقًا أمام الإنتاجية العالية للكود (وهذا لا يتعلق على الإطلاق باستخدام البريد الإلكتروني). هذا هو مصدر المشاعر السلبية التي يعاني منها المطورون. ولن أتبع هذا النموذج لأي مشروع يكون لي فيه الحق الحصري في اتخاذ قرارات حول كيفية تنظيم العمل.
ولكن في الوقت نفسه ، يبدو أن العديد من منتقدي عملية تطوير Linux يعتقدون أن حقيقة أن المدافعين عنها يقاتلون من أجلها بشدة هي نتيجة لحقيقة أن مجتمع Linux مليء بكبار السن الذين لديهم سيطرة خانقة على التقاليد و لا ترغب في التغيير تحت أي ذريعة. ليس هذا هو الحال (على الرغم من أنني متأكد من وجود مثل هؤلاء الأشخاص في مجتمع Linux). تجلب عملية تطوير Linux kernel بعض الفوائد الفريدة والمهمة لمستخدميها. إذا طبقت نفس المبادئ على أي مشروع آخر ، فلن يستفيد منه هذا المشروع إلا.
أي أداة أخرى ، إلى جانب البريد الإلكتروني ، تملي على أولئك الذين يستخدمونها مخططات عمل صارمة إلى حد ما ، مما يحرم Linux من هذه الميزة. والقوائم البريدية هي مجرد آلية ملحوظة تجذب انتباه المتحاورين. نحن بحاجة إلى أدوات يمكنها تقليل الحواجز أمام دخول مطوري Linux. الأدوات التي يمكن أن تصحح العيوب في عملية التطوير. واحد يسمح للمؤسسات المختلفة بالتعرف على نقاط القوة في منظمة تطوير Linux. يمكن لأدوات مثل هذه أن تحدث فرقًا في صناعة تطوير البرمجيات بأكملها.
هناك العديد من هذه الآليات التي لها فائدة كبيرة. حتى لا أطيل حديثنا ، سأركز على أحدهما ، والذي أعتبره الأهم. سأبذل قصارى جهدي للكشف عن جوهرها وأتحدث عن السبب ، على الرغم من قوتها ، فهي تسبب الكثير من المشاعر السلبية لدى المطورين. سأخبرك أيضًا عن سبب قدرتها ، من ناحية ، على الاستفادة من المشاريع الأخرى ، ومن ناحية أخرى ، سبب أهميتها بشكل لا يصدق لنظام Linux.
الالتزام بالرسائل والتصحيحات
في عالم تطوير نواة لينكس ، توجد قاعدة: يجب تقسيم الكود المراد تضمينه في النواة إلى تصحيحات منفصلة. كل واحد منهم يجب أن يحل مشكلة واحدة فقط. يجب إعداد رسالة التزام هادفة لكل رقعة. غالبًا ما يحدث أن تكون هذه الرسائل أطول من الشفرة التي يصفونها.
هذا مثال رئيسي على ما ينقص بشكل عام في المشاريع الأخرى. تبدو معظم رسائل الالتزام التي رأيتها في المشاريع الحديثة على GitHub مثل "التغييرات اعتبارًا من 25 أغسطس" ، أو أفضل قليلاً (ولكن قليلاً فقط) ، مثل "تنفيذ الوظيفة X". إذا احتاج أي شخص إلى النظر إلى رمز مثل هذا في المستقبل ، فلن يكون من السهل عليه معرفة سبب إجراء هذه التغييرات على الكود. قد تكون بعض الأخطاء التي تم إصلاحها من خلال هذه الالتزامات خفية. إذا كنت لا تعرف بالضبط كيف تم إصلاح هذه الأخطاء ، فيمكنهم العودة بسهولة إلى المشروع. عندما أقرأ رسالة الالتزام القصيرة التي لا معنى لها ، قد لا أكون على دراية بالظروف التي تم فيها اكتشاف الخطأ.
هذا مثال صغير. ألقِ نظرة على الالتزام بنواة Linuxمن صنع صديقي العزيز يوهان وينر. من السهل بالنسبة لي أن أتخيل كيف تبدو رسالة إلى التزام مشابه في مشروع آخر "إزالة التحذيرات". وعندما أقرأ رسالة الالتزام التي تمت مناقشتها هنا ، أتعلم لماذا من الممكن ، دون الإضرار بالمشروع ، التخلص من هذه التحذيرات ، حول الظروف التي لن يؤدي فيها هذا ، في الواقع ، إلى أي شيء سيء ، وماذا يجب اتباع القواعد إذا تقرر يومًا ما تغيير هذا الرمز.
أنا متأكد من أن هناك أشخاصًا في العديد من المنظمات يفعلون ذلك. ولكن عند العمل على Linux kernel ، يجب على كل من يشارك في هذا العمل القيام بذلك. لذلك ، أنا واثق تمامًا من أنه من خلال قراءة رسالة الالتزام ، سوف أفهم كل شيء يمكن فهمه حول التغييرات المقابلة في الكود. إذا كنا نتحدث عن خطأ ، فسأعرف عن الأنظمة التي تجلى فيها ، وفي أي ظروف حدثت ، ولماذا لم تؤثر على الأنظمة الأخرى بأي شكل من الأشكال ، وما الذي يجب الانتباه إليه حتى لا يعود هذا الخطأ إلى المشروع.
هذا النوع من العمل مرغوب فيه للغاية في أي منظمة. هذا يسهل على الآخرين (والمطور نفسه ، عندما يلجأ إلى الكود الخاص به بعد فترة) لفهم أسباب إجراء تغييرات على الكود ، لفهم سبب عمل الكود بالطريقة التي يعمل بها. هذا يسهل على المبرمجين الجدد التعرف على المشروع. هذا يحل مشكلة إرجاع الأخطاء القديمة ، ويقلل من خطر أن بعض التعليمات البرمجية ، التي تبدو غير مرتبطة بالرمز المعني ، قد تكسر شيئًا ما فيها.
في مشاريع أخرى هذا "مرغوب فيه للغاية". لكن في Linux هذا ضروري للغاية لسببين:
- Linux . , . Linux, , - . , , , . ( ) , Linux. , Linux.
- (). Linux, . , 2020 , Linux , LTS-. , , - , Linux LTS-, Linux. , 2000- , . , , Red Hat .
لا تمثل Backports عادةً مشكلة للشركات الحديثة عبر الإنترنت التي لا تحتاج إلى صيانة خطوط إنتاج متوازية متعددة. إنهم ينشئون شيئًا ما ، ويمررونه إلى المستخدمين ، وهنا ينتهي الأمر. ولكن عندما تلعب backports دورها ، تصبح الأمور أكثر تعقيدًا. قد يحتاج المطور (ربما ليس مؤلف البرنامج) إلى تحديد كيفية تكييف الكود بشكل طفيف مع قاعدة كود أقدم تختلف قليلاً عن الحديثة. والحل الذي يقلل من المخاطر يمكن أن يكون (وغالبًا ما يكون) حلًا يتكون من إنشاء رقعة فقط لتنفيذ جزء معين من مجموعة كبيرة من التغييرات. تخيل التزامًا من 2000 سطر يحتوي على 5 أسطر من التعليمات البرمجية لإصلاح خطأ. تخيل أيضًا أن هذا الخطأ حدث بعد إعادة هيكلة واجهة برمجة التطبيقات. فماذا تختار:إعداد backport بناءً على مجموعة ضخمة من التغييرات ، أو بناءً على تصحيحات موثقة جيدًا وموثقة جيدًا ومقسمة؟ باعتباري شخصًا قام بعمل عدد لا يحصى من النسخ الخلفية ، فأنا أعرف بالفعل كيف سأجيب على مثل هذا السؤال.
حسنًا ، مع الملفات الخلفية أو بدونها ، يجب أن تدفع المشاريع ثمناً باهظاً مقابل مزايا التنظيم مثل هذا عندما يكون هناك تركيز كبير على توثيق التغييرات بعناية. الآن يحتاج المبرمج إلى الاهتمام ليس فقط بالكود ، ولكن أيضًا بكيفية إعادة تنظيمه وجعله يتماشى مع قواعد العمل في المشروع.
بعض عمليات إعادة بناء الكود هذه بسيطة. لنفترض أننا نتحدث عن استخدام الأمر git add -p واختيار ما سيتم إدخاله في مجموعة التغييرات. تصبح الأمور أكثر تعقيدًا عندما يواجه المبرمج تبعيات دائرية بين أجزاء الكود الفردية. تخيل وظيفة تقوم بإرجاع كائن من النوع الذي سيتم إضافته إلى المشروع بعد إضافة هذه الوظيفة إليه. من أجل التعامل مع هذا الموقف ، سيتعين عليك استخدام الكود ، والذي ، نتيجة لذلك ، لن يدخل في المشروع النهائي ، ولكنه سيؤدي فقط دور الحل المؤقت.
كل هذا يضيف مشكلة للمبرمجين ، لكن لا يمكن للمرء أن يقول إن مثل هذه المهام غير قابلة للحل تمامًا. لنفترض أنك قمت ، بدقة جراحية ، بتقسيم كل ما تفعله إلى أجزاء سهلة الاستخدام ومريحة. تبدأ المشاكل الحقيقية بعد أن يبدأ المبرمجون الآخرون في النظر إلى التعليمات البرمجية الخاصة بك. مراجعة الكود في أي منظمة مهمة للغاية. يقرأ الخبراء كود شخص آخر ويقترحون (أو يطلبون) تغييرات عليه.
افترض أنه طُلب من مبرمج إضافة معلمة جديدة إلى طريقة معينة موجودة في التصحيح الأول من مجموعة من الإصلاحات. ودعنا نفترض أيضًا أن هذه الطريقة تُستخدم في جميع التصحيحات اللاحقة.
هذا يعني أنه سيتعين على المبرمج العودة إلى التصحيح الأول وإضافة معلمة جديدة إلى الطريقة. بعد ذلك ، لم يعد بالإمكان تطبيق التصحيحات التالية. لذلك ، لن يضطر المبرمج إلى حل لغز سبب ذلك فحسب ، بل سيحتاج أيضًا إلى تصحيح جميع الأخطاء يدويًا. إذا تم اختبار جميع التصحيحات الفردية مسبقًا ، فإن نتائج هذه الاختبارات أصبحت قديمة وسيتعين اختبار التصحيحات مرة أخرى.
إعادة تنظيم العمل مشكلة صغيرة. لكن إعادة صياغة ما تم إنجازه بالفعل هي مشكلة أكثر خطورة.
هذا ما أود أن أنقله إلى مجتمع مطوري Linux وأولئك المرتبطين بهذا المجتمع: كل هذا ، بالطبع ، ممكن تمامًا. ولكن إذا لم يكن هذا عائقاً أمام المهنيين الشباب ، فأنا لا أعرف حتى ما يمكن تسميته "حاجز الدخول". من الواضح أن الحاجة إلى قضاء وقتك وجهدك وأعصابك وموارد الكمبيوتر في إعادة تنظيم ما تم إنجازه وإعادة كتابته وإعادة صياغته ليس ما يسعى إليه المبرمجون. في هذا الصدد ، صادفت فكرة واحدة تظهر بشكل دوري في هذا الشكل: "... لكن المبرمج الجيد لن يواجه أي مشاكل مع هذا." يتم التعبير عنه أيضًا على هذا النحو: "لكنه يعلم المبرمجين أسلوبًا معينًا في التفكير ، وهو بالضبط النوع الذي يجب أن يتمتع به المبرمج الجيد." يبدو لي هذا النوع من التفكير غير صادق وعديم الفائدة. في الواقع:لقد أدرجت للتو جميع نقاط القوة في هذه الطريقة ، لكنني وجدت أيضًا أن جميع عمليات إعادة بناء الكود هذه مهام مرهقة ومملة. يمكن مقارنتها بتنظيف الشقة. لنفترض أن أحدهم يقول إنه أمر جيد جدًا أن يظل المنزل نظيفًا (أتفق مع ذلك). الشخص نفسه قادر تمامًا على تنظيف الأرضيات بالمكنسة الكهربائية (يمكنني ذلك) ، لكنه في كثير من الأحيان لا يفعل ذلك. السبب في ذلك بسيط: لديه أشياء أخرى أكثر أهمية للقيام بها. على سبيل المثال ، لهذا السبب أنا سعيد للغاية لأن لدي مكنسة كهربائية من نوع Roomba. هذا الشيء سمح لي بالاستمتاع بالنظافة وفي نفس الوقت لا أضطر إلى ترتيب نفسي. وهو ما يقودني إلى فكرتي التالية ، الموجهة إلى أشخاص خارج عالم Linux.أن جميع عمليات إعادة بناء الكود هذه هي مهام مرهقة ومملة. يمكن مقارنتها بتنظيف الشقة. لنفترض أن أحدهم يقول إنه أمر جيد جدًا أن يظل المنزل نظيفًا (أتفق مع ذلك). الشخص نفسه قادر تمامًا على تنظيف الأرضيات بالمكنسة الكهربائية (يمكنني ذلك) ، لكنه في كثير من الأحيان لا يفعل ذلك. السبب في ذلك بسيط: لديه أشياء أخرى أكثر أهمية للقيام بها. على سبيل المثال ، لهذا السبب أنا سعيد للغاية لأن لدي مكنسة كهربائية من نوع Roomba. هذا الشيء سمح لي بالاستمتاع بالنظافة وفي نفس الوقت لا أضطر إلى ترتيب نفسي. وهو ما يقودني إلى فكرتي التالية ، الموجهة إلى أشخاص خارج عالم Linux.أن جميع عمليات إعادة بناء الكود هذه هي مهام مرهقة ومملة. يمكن مقارنتها بتنظيف الشقة. لنفترض أن أحدهم يقول إنه أمر جيد جدًا أن يظل المنزل نظيفًا (أتفق مع ذلك). الشخص نفسه قادر تمامًا على تنظيف الأرضيات بالمكنسة الكهربائية (يمكنني ذلك) ، لكنه في كثير من الأحيان لا يفعل ذلك. السبب في ذلك بسيط: لديه أشياء أخرى أكثر أهمية للقيام بها. على سبيل المثال ، لهذا السبب أنا سعيد للغاية لأن لدي مكنسة كهربائية من نوع Roomba. هذا الشيء سمح لي بالاستمتاع بالنظافة وفي نفس الوقت لا أضطر إلى ترتيب نفسي. وهو ما يقودني إلى فكرتي التالية ، الموجهة إلى أشخاص خارج عالم Linux.الشخص نفسه قادر تمامًا على تنظيف الأرضيات بالمكنسة الكهربائية (يمكنني ذلك) ، لكنه في كثير من الأحيان لا يفعل ذلك. السبب في ذلك بسيط: لديه أشياء أخرى أكثر أهمية للقيام بها. على سبيل المثال ، لهذا السبب أنا سعيد للغاية لأن لدي مكنسة كهربائية من نوع Roomba. هذا الشيء سمح لي بالاستمتاع بالنظافة وفي نفس الوقت لا أضطر إلى ترتيب نفسي. وهو ما يقودني إلى فكرتي التالية ، الموجهة إلى أشخاص خارج عالم Linux.الشخص نفسه قادر تمامًا على تنظيف الأرضيات بالمكنسة الكهربائية (يمكنني ذلك) ، لكنه في كثير من الأحيان لا يفعل ذلك. السبب في ذلك بسيط: لديه أشياء أخرى أكثر أهمية للقيام بها. على سبيل المثال ، لهذا السبب أنا سعيد للغاية لأن لدي مكنسة كهربائية من نوع Roomba. هذا الشيء سمح لي بالاستمتاع بالنظافة وفي نفس الوقت لا أضطر إلى ترتيب نفسي. وهو ما يقودني إلى فكرتي التالية ، الموجهة إلى أشخاص خارج عالم Linux.يستهدف الأشخاص خارج عالم Linux.يستهدف الأشخاص خارج عالم Linux.
إليك ما أود قوله لمن هم خارج مجتمع Linux: هناك نقاط قوة حقيقية جدًا في عملية التطوير المستخدمة للعمل على Linux. بعض الأدوات غير قادرة على التعامل بشكل كامل مع المهمة التي تعمل على Linux. GitHub ، على سبيل المثال ، يقوم بعمل رائع في المشاريع حيث يتم دائمًا إضافة رمز جديد بعد الرمز الموجود. يمكنك بالطبع استخدام الأمر git push - force ، بما في ذلك تضمين فرع معين بالقوة في المستودع ، ولكن التعليقات المرفقة بالالتزام ستكون في الواقع "معلقة في الهواء" ، وستكون مناقشة هذا الالتزام بلا معنى.
أدوات التطوير الحديثة تبسط الكثير. إنها تسمح لك بتشغيل تنفيذ بعض الإجراءات عند حدوث شروط معينة ، فهي تدعم التكامل المستمر وعمليات نشر المشروع ، وتخطر المبرمجين بالتغييرات في الكود ، وتحل الكثير من المهام الأخرى. لكنها بالتأكيد تعقد عملية تقسيم نتائج عمل شخص ما إلى أجزاء صغيرة يسهل التعامل معها. إن استخدام رسائل البريد الإلكتروني ذات النص العادي يعقد الكثير ، ولكن يجب ملاحظة أن تنظيم العمل هذا لا يتداخل مع تطبيق عمليات التطوير التي تؤدي إلى هدف محدد.
حتى لو كان من الممكن إجراء تقييم موضوعي ودقيق للمقدار الذي كان يمكن أن يكتسبه ويخسره نظام Linux (لا شيء كان سيخسره) من خلال التخلي عن عملية التطوير الحالية ، فلن يغير أي شيء. الحقيقة هي أن الوضع الحالي يوضح الطبيعة البشرية تمامًا ، عندما يسعى الناس للحفاظ على ما سبق أن أظهر نفسه جيدًا في الممارسة.
هل هناك طريقة للخروج من هذا الوضع؟
أعتقد بصدق أنه إذا كانت لدينا أدوات تحت تصرفنا يمكن أن توفر للمؤسسات المختلفة نفس الفوائد التي يستمدها مجتمع Linux من منهجية التطوير الخاصة به ، فسيكون ذلك مفيدًا جدًا للجميع. وإذا كانت هذه الأدوات موجودة ، فربما يمكن لمجتمع Linux استبدال رسائل البريد الإلكتروني النصية العادية بها.
ليس لدي إجابة على السؤال حول الشكل الذي قد تبدو عليه هذه الأدوات. لكنني سأسمح لنفسي باغتنام الفرصة والتأمل فيها قليلاً:
- Git — . , , , , . GitHub, - git-, «-» Linux, git, . , -, , , , . Git . CSS HTML, — , CSS HTML- . , HTML CSS? , , , .
- , , , , , . , , , ? . , : « create_foo() , create_bar()», : « create_bar() y, ». , , . , , , , GPT-3, , .
- , , , , - , . , , , . , , , , , , , , , .
-, Linux?
