أخطاء كود Lovable: كيف تفحص تطبيقًا لم تكتبه بنفسك

نقطة البداية الصادقة

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

أين تكمن أخطاء كود Lovable عادةً

تفشل التطبيقات المولَّدة بترتيب يمكن التنبؤ به. ابدأ بفحص هذه الأمور.

الفحص الذي يستمر في أداء دوره

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

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

كل هذا متاح أيضًا في لوحة تحكم TestSprite، وهي عادةً الطريق الأفضل إن لم تكن الطرفية هي مكان عملك. أما تفاصيل CLI فتجدها في مستودع CLI.

ثلاثة فحوص تستحق أن تمتلكها من اليوم الأول

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

• أنشئ شيئًا، أعد تحميل الصفحة، وتأكد أنه ما زال موجودًا. هذا الفحص وحده يكشف العطل الأكثر شيوعًا والأكثر إحراجًا.

• افعل الشيء الذي وُجد تطبيقك من أجله، بحساب جديد تمامًا. إن نجح ذلك مع شخص غريب، فلديك شيء حقيقي.

كيف تصف الخطأ حتى يصيب الإصلاح هدفه

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

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

والجمل الثلاث نفسها هي أيضًا الفحص الذي تحتفظ به. تُكتب مرة واحدة، ثم يمكن إعادة تشغيلها بعد كل تغيير لاحق، وهكذا تمنع المشكلة نفسها من العودة.

الترتيب الذي تفحص به الأمور

هناك تسلسل يجد المشكلات أسرع من التنقل العشوائي بالنقر، ويستغرق نحو عشر دقائق.

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

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

عندما تصبح جاهزًا لمشاركته

قبل أن يذهب التطبيق إلى أي مكان حقيقي، اجعل الفحوص تعمل تلقائيًا مع كل تغيير بدلًا من أن تعمل حين تتذكرها. وأمامك طريقتان لذلك:

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

كيف تتولى TestSprite الفحص نيابةً عنك

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

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

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