نقل بيانات Puppeteer إلى TypeScript

نحن من المعجبين بـ TypeScript في فريق "أدوات المطوّرين"، لدرجة أنّنا نستخدمه لإنشاء الرموز البرمجية الجديدة في "أدوات المطوّرين"، ونحن في منتصف عملية نقل كبيرة لقاعدة البيانات بالكامل كي يتم التحقّق من أنواعها باستخدام TypeScript. يمكنك الاطّلاع على مزيد من المعلومات عن عملية نقل البيانات هذه في محادثتنا في Chrome Dev Summit 2020. لذلك، كان من المنطقي النظر في نقل قاعدة رموز Puppeteer البرمجية إلى TypeScript أيضًا.

التخطيط لعملية نقل البيانات

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

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

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

من الأمور التي استغرقت وقتًا في البداية هي إعداد عملية التكامل المستمر (CI). لاحظنا أنّ عمليات دمج الإصدارات التي يتم إجراؤها على طلبات الربط كانت غير متّسقة وغالبًا ما كانت تنتهي بالفشل. وقد حدث ذلك كثيرًا لدرجة أنّنا اعتدنا على تجاهل عملية التطوير المتكامل (CI) ودمج طلبات الربط على أي حال، بافتراض أنّ الخطأ كان مشكلة لمرة واحدة في عملية التطوير المتكامل بدلاً من مشكلة في Puppeteer.

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

اختيار ملف واحد ونشره

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

بالإضافة إلى ذلك، ساهمت معالجة الملفات واحدًا تلو الآخر (مع إصدارات Puppeteer العادية، لكي لا يتم طرح جميع التغييرات في إصدار npm نفسه) في الحد من المخاطر. اخترنا DeviceDescriptors.js كأول ملف، لأنّه كان أحد الملفات الأكثر بساطة في قاعدة البيانات. قد يبدو لك أنّ كل هذا العمل التحضيري الذي أجريته قد أدى إلى تغيير بسيط، ولكن الهدف ليس إجراء تغييرات كبيرة على الفور، بل المتابعة بحذر ومنظّم ملفًا تلو الآخر. إنّ الوقت الذي تقضيه في التحقّق من المنهجية يُوفّر بالتأكيد الوقت لاحقًا في عملية نقل البيانات عند الوصول إلى هذه الملفات الأكثر تعقيدًا.

إثبات النمط وتكراره

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

نقل البيانات وتحسينها لاحقًا

بالنسبة إلى أي ملف JavaScript فردي، كانت العملية التي اتّبعناها على النحو التالي:

  1. أعِد تسمية الملف من .js إلى .ts.
  2. شغِّل محوِّل TypeScript البرمجي.
  3. أصلِح أي مشاكل.
  4. أنشئ طلب سحب.

كان معظم العمل في طلبات سحب البيانات الأولية هذه هو استخراج واجهات TypeScript لهياكل البيانات الحالية. في ما يتعلّق بطلب سحب الملفات الأول الذي نقل DeviceDescriptors.js الذي ناقشناه سابقًا، تم نقل الرمز البرمجي من:

module.exports = [
  { 
    name: 'Pixel 4',
     // Other fields omitted to save space
  }, 
  
]

وأصبح:

interface Device {
  name: string,
  
}

const devices: Device[] = [{name: 'Pixel 4', }, ]

module.exports = devices;

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

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

نقل الاختبارات لاختبار تعريفات الأنواع

بعد نقل رمز المصدر بالكامل إلى TypeScript، تمكّنا من التركيز على الاختبارات. كانت اختباراتنا شاملة للغاية، ولكنّها كانت مكتوبة جميعًا بلغة JavaScript. وهذا يعني أنّه لم يتم اختبار تعريفات الأنواع. أحد الأهداف المُطوّلة للمشروع (الذي ما زلنا نعمل عليه) هو توفير تعريفات أنواع عالية الجودة بشكل تلقائي باستخدام Puppeteer، ولكن لم يكن لدينا أي عمليات تحقّق في قاعدة بياناتنا حول تعريفات الأنواع.

من خلال نقل الاختبارات إلى TypeScript (باتّباع العملية نفسها، ملفًا تلو الآخر)، اكتشفنا مشاكل في TypeScript كان من الممكن أن يجد المستخدمون لنا حلولاً لها. لا تغطّي اختباراتنا الآن جميع وظائفنا فحسب، بل تعمل أيضًا كفحص جودة لـ TypeScript.

لقد استفادنا كثيرًا من TypeScript بصفتنا مهندسين نعمل على قاعدة بيانات Puppeteer. بالإضافة إلى بيئة التطوير المتكامل (CI) المحسّنة كثيرًا، ساعدنا ذلك في زيادة إنتاجيتنا عند العمل على Puppeteer واستخدام TypeScript لرصد الأخطاء التي كانت ستظهر في إصدار npm. يسرّنا إرسال تعريفات TypeScript عالية الجودة لتمكين جميع المطوّرين الذين يستخدمون Puppeteer من الاستفادة من هذا العمل أيضًا.

تنزيل قنوات المعاينة

ننصحك باستخدام إصدار Canary أو Dev أو الإصدار التجريبي من Chrome كمتصفّح التطوير التلقائي. تتيح لك قنوات المعاينة هذه الوصول إلى أحدث ميزات DevTools، وتتيح لك اختبار واجهات برمجة تطبيقات منصات الويب المتطوّرة، وتساعدك في العثور على المشاكل في موقعك الإلكتروني قبل أن يعثر عليها المستخدمون.

التواصل مع فريق "أدوات مطوّري البرامج في Chrome"

استخدِم الخيارات التالية لمناقشة الميزات الجديدة أو التحديثات أو أي شيء آخر مرتبط بـ "أدوات مطوّري البرامج".