TDD مع AI: اكتب كود أقل وأفضل

لو بتستخدم أدوات الذكاء الاصطناعي في كتابة الكود، فـ Test Driven Development (TDD) بقى من المهارات المهمة جدًا لأي Software Engineer.
الفكرة ببساطة إنك ما تبدأش بكتابة الكود مباشرة. الأول تفهم الـ Business Context، وتحدد الـ Use Cases والـ Scenarios والـ Edge Cases، وبعدها تكتب Tests واضحة تحدد السلوك المطلوب. ثم تستخدم الكود لتنفيذ هذه المتطلبات بأقل تعقيد ممكن.

وده مهم بشكل خاص مع AI؛ لأن الأداة ممكن تكتب كود بسرعة جدًا، لكن السرعة في كتابة الكود مش معناها إن الكود هو الحل الصحيح.

---

ما هو Test Driven Development؟​

Test Driven Development أو TDD هو أسلوب لتطوير البرمجيات يعتمد على كتابة الاختبارات قبل كتابة الكود الذي ينفذ الوظيفة المطلوبة.

بشكل مبسط، الدورة المعتادة في TDD تكون:

1. تكتب Test يصف السلوك المطلوب.
2. تشغل الـ Test وتجد أنه يفشل.
3. تكتب أقل قدر ممكن من الكود لجعل الـ Test ينجح.
4. تحسن وتنظف الكود بدون تغيير السلوك المطلوب.
5. تنتقل إلى السيناريو التالي.

الهدف هنا مش إنك تكتب أكبر كمية من الـ Tests أو الكود، لكن إنك تحول المتطلبات إلى سلوك واضح يمكن التحقق منه.

---

لماذا TDD مهم مع استخدام AI في البرمجة؟​

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

الجزء الأصعب هو تحديد:

• ماذا يجب أن يفعل النظام؟
• ماذا يحدث في الحالات غير المتوقعة؟
• ما الـ Business Rules التي يجب الالتزام بها؟
• ما الذي يجب أن يحدث عندما تكون البيانات ناقصة أو غير صحيحة؟
• ما الحالات التي يجب رفضها؟
• وما الحالات التي يجب قبولها؟

هنا يظهر دور الـ Software Engineer.

بدل ما تقول لأداة AI: "اكتب لي نظام حجز"، الأفضل أن تحدد لها الـ Use Cases والـ Scenarios والـ Constraints والـ Tests التي يجب أن ينجح فيها الكود.
بكده أنت بتحدد ما الذي يجب أن يفعله البرنامج، وتترك للأداة جزءًا من مهمة تنفيذ الحل.

---

TDD يجبرك تفهم الـ Business Context​

من أهم فوائد TDD إنك ما تقدرش تكتب Test جيد لو أنت مش فاهم المشكلة أصلًا.
تخيل إنك بتطور نظام لشركة فيها حجوزات.

قبل ما تكتب أي كود، لازم تعرف مثلًا:

• هل يسمح النظام بأكثر من حجز لنفس المورد في نفس الوقت؟
• ماذا يحدث لو انتهى الحجز في نفس لحظة بداية حجز آخر؟
• هل يمكن تعديل الحجز بعد بدايته؟
• ماذا يحدث إذا أرسل المستخدم تاريخًا غير صحيح؟
• هل المستخدم يقدر يلغي الحجز في أي وقت؟
• هل توجد صلاحيات مختلفة بين المستخدم والمدير؟

دي كلها Business Rules، وليست مجرد تفاصيل برمجية.
لما تحاول تحويلها إلى Tests، هتكتشف بسرعة الأماكن اللي أنت مش فاهم فيها النظام بشكل كافٍ.
وده من أهم أدوار TDD: تحويل فهمك للمشكلة إلى سلوك قابل للاختبار.

---

التفكير في Edge Cases قبل كتابة الكود​

من الأخطاء الشائعة إن المطور يفكر فقط في السيناريو الطبيعي.
مثلًا: "المستخدم يدخل رقم صحيح، والنظام يرجع النتيجة."

لكن ماذا لو:

• الرقم يساوي صفر؟
• الرقم سالب؟
• القيمة فارغة؟
• البيانات غير موجودة؟
• المستخدم ليس لديه صلاحية؟
• الطلب مكرر؟
• هناك بيانات متعارضة؟

في TDD، أنت بتحاول تحديد هذه الحالات قبل أو أثناء كتابة الـ Tests.
وده بيساعدك على اكتشاف المشاكل في تصميم الحل قبل ما تتحول إلى Bugs داخل النظام.

---

كيف تستخدم TDD مع AI بشكل عملي؟​

ممكن تعتبر الـ Tests والـ Use Cases بمثابة حدود واضحة لأداة AI.
بدل ما تطلب منها: "اكتب لي الكود كاملًا."

ابدأ بتحديد المطلوب:

1. اشرح الـ Business Rules.
2. حدد الـ Use Cases.
3. حدد الـ Edge Cases.
4. اكتب الـ Tests التي تمثل هذه الحالات.
5. تأكد أن الـ Tests تعبر فعلًا عن الـ Requirements.
6. بعد ذلك اطلب تنفيذ الكود الذي يجعل هذه الـ Tests تنجح.
7. راجع الكود ونظفه بعد الوصول إلى الحل.

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

---

لا تجعل AI يكتب الكود بالكيلو​

من أكبر مشاكل استخدام AI في البرمجة إنك ممكن تحصل على كمية ضخمة من الكود بسرعة جدًا.
الكود ممكن:

• يعمل فعلًا.
• يمرر بعض الاختبارات.
• يبدو منظمًا.
• لكنه يكون أكبر من اللازم.
• أو يحتوي على Abstractions غير ضرورية.
• أو يكرر منطق موجود بالفعل.
• أو يحل مشكلة لم تكن موجودة أصلًا.

وهنا لازم يكون دور الـ Software Engineer أكبر من مجرد مراجعة الـ Syntax.

بعد ما تحصل على الحل، اسأل نفسك:

• هل الكود فعلًا محتاج كل ده؟
• هل فيه أجزاء يمكن حذفها؟
• هل فيه Logic مكرر؟
• هل الـ Abstraction ضروري؟
• هل التصميم أبسط من كده؟
• هل الكود واضح لشخص آخر سيقرأه بعد سنة؟

الهدف مش إنك تكتب أقل عدد من الأسطر بأي ثمن.
الهدف هو أبسط كود يحقق الـ Requirements بشكل صحيح وقابل للصيانة.

---

من كتابة الكود إلى تنظيف الكود​

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

ممكن تلاقي نفسك بعد فترة بتعمل الآتي:
"احذف الجزء ده."
"ممكن نشيل الـ Helper ده."
"ليه عندنا Class كامل للوظيفة دي؟"
"الـ Function دي ممكن تكون أبسط."
وهنا تظهر مهارة مهمة جدًا: معرفة ما الذي لا تحتاج إلى كتابته أصلًا.
كلما كان الـ Requirements والـ Tests أوضح، أصبح من الأسهل تقييم الكود الذي ينتجه AI بدل قبول كل ما يكتبه.

---

هل TDD يعني كتابة Tests لكل شيء؟​

لا.
TDD مش معناه إنك لازم تختبر كل سطر كود أو تكتب عشرات الاختبارات لمجرد زيادة التغطية.
الأهم هو اختبار السلوك المهم للنظام.

ركز على:

• Business Rules.
• الحالات الحرجة.
• Edge Cases المهمة.
• النتائج المتوقعة.
• الحالات التي يمكن أن تسبب مشاكل حقيقية للمستخدم.

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

---

الخلاصة​

استخدام AI في البرمجة لا يقلل أهمية الـ Software Engineer، لكنه يغير نوع المهارات التي تحتاجها.
لما الأداة تقدر تكتب الكود بسرعة، تصبح قيمة المطور أكبر في قدرته على:

• فهم الـ Business Context.
• تحديد الـ Requirements.
• التفكير في الـ Use Cases.
• اكتشاف الـ Edge Cases.
• كتابة Tests جيدة.
• مراجعة الحلول.
• تبسيط التصميم.
• حذف الكود غير الضروري.

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

---

الأسئلة الشائعة​

------------

هل TDD مناسب للمشاريع التي تستخدم AI؟​

نعم. TDD يمكن أن يكون مفيدًا جدًا مع AI لأنه يعطيك طريقة واضحة لتحديد السلوك المطلوب والتحقق من أن الكود الناتج يحقق الـ Requirements.

هل يجب كتابة الـ Tests قبل أي كود؟​

في أسلوب TDD التقليدي، نعم، تكتب Test يفشل أولًا ثم تكتب أقل قدر من الكود لجعله ينجح، وبعدها تعمل Refactoring.

هل استخدام AI يغني عن TDD؟​

لا. AI يمكنه كتابة Tests وكود، لكنه لا يعرف بالضرورة الـ Business Rules الحقيقية أو القرارات التي يجب أن يتخذها النظام. لذلك تظل مسؤولية تحديد السلوك المطلوب ومراجعة الحل على المطور.

هل TDD يجعل الكود أقل حجمًا؟​

ليس بالضرورة، لكن TDD يساعدك على التركيز على السلوك المطلوب وتقليل الحلول غير الضرورية. ومع استخدام AI، يمكن أن يساعدك ذلك على اكتشاف الكود الزائد وحذفه بدل الاحتفاظ به لمجرد أن الأداة كتبته.