انتقل إلى المحتوى الرئيسي

الدرس 3 — الدفاتر وسير العمل

الدفتر (notebook) هو مستند يخلط خلايا كود وخلايا نصّ ومخرجات — أرقاماً وجداول ورسوماً — في تدفّق واحد. وهو الأداة الافتراضية في عمل البيانات، ولسبب وجيه، وفي الوقت نفسه أحد أكبر مصادر الفوضى في المشاريع.

لماذا يهيمن الدفتر في الاستكشاف​

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

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

Google Colab: بلا تنصيب وبمعالج رسومي مجاني​

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

الحدود التي يجب معرفتها: الجلسة تُقطع بعد فترة خمول، والملفّات المؤقّتة تُمحى، وحدّ الاستخدام المجاني للمعالج الرسومي غير مضمون في أوقات الذروة. للتعلّم والتجارب هذا كافٍ تماماً؛ ولتدريب طويل جدّاً لا.

العيوب الثلاثة التي تجعله سيّئاً للإنتاج​

هنا تأتي النقطة المهمّة، لأنّ تجاهلها يخلق مشاريع لا تعمل عند أحد آخر.

ترتيب التنفيذ خفيّ. يمكنك تنفيذ الخلية 12 ثم 5 ثم 30. والمستند يظهر بترتيب من الأعلى إلى الأسفل، لكنّ الحالة التي أنتجت النتائج ليست هذا الترتيب. النتيجة: دفتر يعمل عندك ويفشل عند من ينفّذه من البداية إلى النهاية. الاختبار الحاسم: أعد تشغيل النواة ونفّذ كلّ الخلايا بالترتيب. إذا لم تحصل النتيجة نفسها، فدفترك ليس صحيحاً بل محظوظ.

الحالة تتراكم بصمت. متغيّر عرّفته ثم حذفت خليّته يبقى في الذاكرة. وكود يقرأ متغيّراً لم يعد معرّفاً في المستند يعمل عندك، ويكسر عند غيرك.

المراجعة في Git مؤلمة. الدفتر ملفّ JSON يحتوي الكود والمخرجات وبيانات وصفية للتنفيذ. تغيير سطر واحد قد ينتج فرقاً (diff) بمئات الأسطر لأنّ الصور المضمّنة تغيّرت. المراجعة الجدّية للكود تصبح شبه مستحيلة.

ما ينبغي ألا يبقى في دفتر أبداً

منطق سيُستخدَم أكثر من مرّة، أو سيدخل الإنتاج، أو سيعتمد عليه فريق. دالّة تحويل البيانات، وخطّ المعالجة، وتعريف النموذج: هذه تنتقل إلى ملفّات .py مع اختبارات.

سير العمل السليم​

النمط الذي تستخدمه الفرق الجيّدة بسيط: استكشف في الدفتر، ثم انقل ما يستحقّ البقاء إلى وحدات كود.

الحلقة مفيدة: الدفتر يبقى مكان التجربة، والوحدات تحمل الحقيقة، وتستوردها في الدفتر فلا تتكرّر النسخ.

بنية مشروع تُغنيك عن التفكير​

بنية واحدة تكفي لمعظم المشاريع، والفائدة أنّها تصبح تلقائية:

  • data/ للبيانات — لا تُرسَل إلى Git، وتُوصف بمصدرها في ملفّ نصّي.
  • notebooks/ للاستكشاف، بترقيم يوضّح الترتيب.
  • src/ للكود الذي يستحقّ البقاء: قراءة البيانات، السمات، النموذج.
  • tests/ لاختبارات هذا الكود.
  • requirements.txt أو ما يعادله لتثبيت الإصدارات.
  • README.md يشرح كيف يُشغَّل المشروع من الصفر.

الملفّ الأخير هو الأهمّ وأكثرها إهمالاً. اكتبه بافتراض أنّك ستعود بعد ستّة أشهر ولن تتذكّر شيئاً، لأنّ هذا ما سيحدث.

المحرّرات: خارج المتصفّح​

الدفتر ليس الطريق الوحيد. محرّر مثل VS Code يشغّل الدفاتر ويشغّل ملفّات بايثون في الوقت نفسه، مع إكمال تلقائي حقيقي ومصحّح أخطاء وتكامل مع Git. الانتقال إليه بعد أوّل شهرين يوفّر وقتاً كثيراً، خصوصاً حين يكبر الكود.

في ثلاث جمل​

الدفتر مثالي للاستكشاف لأنّه يطابق حلقة «جرّب وانظر»، وColab يزيل عقبة التنصيب ويعطي معالجاً رسومياً مجاناً. لكنّه سيّئ للهندسة: ترتيب التنفيذ خفيّ، والحالة تتراكم، والمراجعة في Git مؤلمة. والسير السليم هو الاستكشاف في الدفتر ونقل ما يستحقّ البقاء إلى وحدات .py مع اختبارات.

التالي — الدرس 4: scikit-learn ←