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

Jack Franklin

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

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

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

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

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

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

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

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

في هذه المرحلة، أصبحنا جاهزين لنقل البيانات ولدينا خادم 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"

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