أعادت GitHub بناء واجهة عرض طلبات السحب في تطبيق GitHub Copilot لمعالجة حالة قصوى: طلب سحب يضم 2,200 ملف، وأكثر من مليون سطر متغير، وما يزيد على 400 تعليق مراجعة مضمّن. الهدف لم يكن تسريع عرض فرق كبير فحسب، بل إبقاء التمرير والمراجعة قابلين للاستخدام بعدما تضيف المحادثة نفسها أبعاداً متغيرة إلى المستند.
تستند الواجهة التقليدية للفرق الكبيرة إلى التحميل الافتراضي، أي إبقاء العناصر الظاهرة قرب إطار العرض فقط، مع إعادة استخدام عناصر DOM أثناء التمرير. وينجح هذا النموذج بسهولة نسبية عندما يكون كل عنصر سطراً برمجياً بارتفاع معروف. لكن التعليقات لا تملك هذه الخاصية؛ فارتفاعها يتغير تبعاً لالتفاف Markdown، وفتح أقسام <details>، وظهور محرر الرد، والصور، والتعديلات المقترحة، وحالات التفاعل المختلفة.
هندستان بدلاً من جدول ارتفاع واحد
أبقت GitHub على هندسة ثابتة لأسطر الشيفرة، تستخدم حسابات مسبقة للمواقع والارتفاعات ولا تعيد بناءها عندما يتغير تعليق. في المقابل، وضعت التعليقات ومحررات الردود والكتل الديناميكية في فهرس مستقل. لكل كتلة مفتاح ثابت مرتبط بالملف والسطر والجانب، إضافة إلى بصمة للمحتوى وحالة الأقسام المفتوحة وعرض القياس الأخير.
يُستخدم الارتفاع المقاس عندما تكون القياسات صالحة، أو قيمة مخزنة مؤقتاً عندما تظل البصمة والعرض متوافقين، وإلا تستخدم الواجهة تقديراً مؤقتاً. وبهذا لا يؤدي تمدد تعليق واحد إلى إعادة حساب هندسة ملايين الأسطر.
القياس خارج مسار التمرير
تخلت GitHub عن تصميم أولي كان يعتمد على ResizeObserver مستقل لكل كتلة ويكتب القياس مباشرة إلى التخطيط. هذا النمط قد يخلق حلقة تغذية راجعة، لأن تغيير التخطيط يعيد تشغيل المراقبة، كما أن كلفته تزداد مع عدد الكتل المركبة.
التصميم الذي شحنته الشركة يستخدم دورة قياس واحدة مرتبطة بفترات السكون وبعد انتهاء التمرير. لا تُقاس عادةً إلا الكتل الموجودة ضمن نحو 2,400 بكسل من إطار العرض، بينما تُترك الكتل البعيدة على تقديراتها حتى تقترب. وتُقرأ قياسات العناصر الظاهرة دفعة واحدة لتجنب عمليات إعادة تدفق متكررة.
تظل المراقبات موجودة لرصد تغييرات مثل تحميل صورة أو الكتابة في محرر الرد، لكنها تضع علامة على الكتلة كي تعيد دورة القياس قراءتها، بدلاً من تعديل الارتفاع مباشرة. الاستثناء هو التغيير الذي سببه المستخدم في كتلة ظاهرة، مثل فتح قسم أو محرر رد؛ عندها يمكن تطبيق تصحيح متزامن واحد في الإطار نفسه، ما يمنع ظهور خطوة مرئية بين تمدد التعليق وتحرك الشيفرة أسفله.
تصحيح التخطيط من دون فقدان موضع القراءة
عندما يختلف الارتفاع الفعلي عن التقدير، لا تصحح الواجهة الموضع اعتماداً على عدد البكسلات وحده. فهي تحفظ هوية العنصر الذي يقرأه المستخدم، سواء كان سطراً أو كتلة تعليق، وتحدد الإزاحة داخله، ثم تطبق فروق الارتفاع وتعيد حساب موضع العنصر نفسه. بهذه الطريقة يبقى العنصر المثبت في المكان ذاته تقريباً.
لا تُجرى التصحيحات عادةً أثناء تمرير المستخدم أو زخمه، ولا تُستخدم التعديلات الناتجة عن محتوى أسفل الشاشة لتحريك العرض. واجه الفريق خطأً عندما اعتُبر التمرير البرمجي الناتج عن تغيير عرض اللوحة تمريراً من المستخدم، ما أدى إلى فقدان التصحيح وانجراف الملف المقروء. عولج ذلك بالفصل بين تفاعل المستخدم والتغييرات التي تسببها الواجهة نفسها.
خط بيانات واختبارات تعمل آلياً
لا تعتمد الاستجابة على العرض الافتراضي وحده. تُرسل بنية الفرق وبيانات الملفات أولاً كي تظهر شجرة الملفات والبيانات الوصفية أثناء تحميل بقية المستند، بينما تُؤجل أعمال مثل تمييز الصياغة وبناء Markdown التفصيلي إلى أن تقترب العناصر من إطار العرض. كما تحتفظ الواجهة مؤقتاً بآخر عدد قليل من الفروق المستخدمة، مع إخلاء ما يتجاوز ذلك لتقليل استهلاك الذاكرة.
ولكشف العيوب التي لا تظهر إلا عند التمرير العميق، أضافت GitHub إشارات قياس دائمة واختبارات آلية تراقب عدد الصفوف والكتل المركبة، ووقت الإطار، وحجم تصحيحات التمرير، وتسرب المراقبات، ووجود فراغات غير مملوءة. وشغّل الفريق تدفقات آلية على تطبيق سطح المكتب وتحت محرك العرض الفعلي، مع حالات مثل فتح الأقسام، تشغيل محررات الرد، تغيير حجم النافذة، والتنقل داخل قائمة ملفات كبيرة.
لماذا يهم هذا التصميم؟
النتيجة المعلنة هي أن طلب سحب بمليون سطر ومئات التعليقات يتصرف مثل طلب عادي: تُعرض التعليقات كاملة بدلاً من قصها داخل شريط تمرير متداخل، ويؤدي توسيع قسم إلى تحريك الشيفرة أسفله دون قفزات عشوائية، كما يمكن العودة إلى طلب سحب مع الاحتفاظ بموضع القراءة. القيمة الهندسية الأهم أن GitHub لم تحاول جعل كل المحتوى ذا طبيعة واحدة؛ بل أبقت الجزء الحتمي سريعاً وفصلته عن المحتوى الذي لا يمكن معرفة حجمه قبل عرضه.
مع ذلك، لا تدعي المادة أن جميع طلبات السحب الكبيرة أصبحت سهلة للمراجعة من ناحية الفهم أو إدارة المخاطر. ما عالجته هو أداء واجهة العرض وسلوكها أثناء القياس والتغير. كما أن النتائج مرتبطة بتطبيق GitHub Copilot وتصميمه الداخلي، ولا تقدم أرقاماً مستقلة عن استهلاك الذاكرة أو مؤشرات الأداء عبر أجهزة ومحركات مختلفة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.