تجنب توسع نطاق العمل

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

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

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

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

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

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