سيقدم لك محرر Downcodes BugFree، وهي أداة مبسطة لإدارة العيوب على شبكة الإنترنت. إنه يعتمد على فلسفة تطوير برامج Microsoft ويقدمها في شكل تعليمات برمجية مجانية ومفتوحة المصدر، وهو أحد البرامج المجانية القليلة التي نجحت في "استنساخ" أداة إدارة الأخطاء الداخلية من Microsoft Product Studio (المعروفة سابقًا باسم Raid). ستتناول هذه المقالة مقدمة BugFree، وعملية إكمال التعليمات البرمجية، وكيفية التعامل مع عيوب البرامج، وآمل أن تساعدك على فهم هذه الأداة واستخدامها بشكل أفضل.
BugFree هي أداة مجانية ومفتوحة المصدر ومبنية على الويب لإدارة العيوب وتعتمد على فلسفة تطوير برامج Microsoft. وهو حاليًا أحد البرامج المجانية القليلة التي "تستنسخ" أداة إدارة الأخطاء الداخلية من Microsoft Product Stuido (المعروفة سابقًا باسم Raid).
BugFree هي أداة مجانية ومفتوحة المصدر ومبنية على الويب لإدارة العيوب وتعتمد على فلسفة تطوير برامج Microsoft. وهو حاليًا أحد البرامج المجانية القليلة التي "تستنسخ" أداة إدارة الأخطاء الداخلية من Microsoft Product Stuido (المعروفة سابقًا باسم Raid).
تمت كتابة BugFree بلغة PHP+MySQL ويمكن تشغيله على منصات Linux وWindows. أفكار التصميم المضمنة في BugFree 2.0 هي:
– الكود: البرنامج عبارة عن تطبيق (تعيين) لوثيقة مواصفات تصميم المتطلبات (Spec)؛
– حالة الاختبار: وهي أيضًا تطبيق (تعيين) للمواصفات، ولكن من منظور الاختبار؛
- نتيجة الاختبار: استخدم حالة الاختبار (تعيين الاختبار) للتحقق من الكود (تعيين التطوير)؛
- خطأ: قد يكون عدم الاتساق بين التعيينين خطأً (الكود ينحرف عن المواصفات)
بهذه الطريقة، من حالات الاختبار (Test Case) إلى نتائج الاختبار (Test Result) إلى العيوب (Bugs)، يتم دمج الثلاثة عضويًا.
تمت كتابة BugFree في "الجهاز العصبي الرقمي" بلغة PHP+MySQL مفتوحة المصدر ويتم تشغيله استنادًا إلى المتصفح. لم تكن لدي أي خبرة سابقة في تطوير Linux+Apache+MySQL+PHP، لكنني كنت محظوظًا بما يكفي لتوظيف اثنين من مبرمجي الويب الممتازين الذين تمكنوا من بناء مثل هذا النظام في شهرين فقط. من بينها، تم تطوير BugFree بواسطة زميلي Wang Chunsheng، واستغرق الأمر أقل من شهر لكتابة الكود، مما فاجأني وجعلني أدرك سحر تطوير الويب استنادًا إلى Linux.
وبعد اختباره لأكثر من شهر يمكن استخدامه في العمل الفعلي. أصبح BugFree الأداة الأكثر أهمية في عملنا اليومي. كما اعتاد كل موظف على استخدام Bug لتسجيل الأشياء وتتبعها. لا يمكن التنصت على العيوب في التعليمات البرمجية فحسب، بل يمكن أيضًا استخدام المتطلبات الجديدة وتغييرات التصميم وما إلى ذلك نظام الإدارة. في الواقع، لا يمكن استخدام الأخطاء لتسجيل العيوب في البرامج فحسب، بل يمكن استخدامها أيضًا لتتبع الشؤون اليومية للشركة. على سبيل المثال، قبل إنشاء نظام السداد عبر الإنترنت للشركة، استخدمنا BugFree للتعامل مع السداد. حتى أن أحد الزملاء أعطاني هذا الخطأ: سطح المكتب الخاص بك فوضوي للغاية، يرجى ترتيبه :-)
مزيد من القراءة:
عادة عندما يجد الأشخاص عيوبًا برمجية، يقومون بتصنيف العيوب البرمجية. هناك طريقة واحدة فقط لتصنيفها، وهي مستوى الخطورة. ألا توجد طريقة أخرى لتصنيفها. على سبيل المثال، واجهنا الموقف التالي: وجد المختبر أن هناك وظيفة يجب إضافتها في هذا الوقت، وأخبر المبرمج أنه لا يوجد وقت أو أنه ليس ضروريًا. سيؤدي هذا الموقف إلى حدوث صراع بين الاثنين، إذا كنت تتهرب، فلن تكون النتيجة النهائية معروفة، وهذا سيضعف حماسة المختبرين في المرة القادمة، فلن يفكروا في مشاكل المنتج بقدر ما يستطيعون يمكن تشغيله. في الواقع، يمكن حل هذا الموقف أدناه، وسأذكر مفهومًا جديدًا لتصنيف عيوب البرامج لحل هذه المشكلة بشكل فعال.
لا تعد عيوب البرامج مجرد أخطاء خطيرة، ولكنها أيضًا وظائف لم يتم تنفيذها. في هذه المرحلة، ربما يفهم الجميع أن الاحتياجات لم تؤخذ في الاعتبار، لكن الاحتياجات لن تكون مثالية مرة واحدة، ويتطلب الأمر تضافر جهود الجميع للتحسين المستمر. إذًا كيف يمكننا تنفيذ الاقتراحات الجيدة التي قدمها المختبرون بشكل فعال؟ وهذا ما أريد أن أقوله بعد ذلك. هناك طريقة أخرى لتصنيف عيوب البرامج وفقًا لمحتوى الخلل، وهي مقسمة بشكل أساسي إلى أخطاء المتطلبات وأخطاء البرنامج. وتتمثل ميزة هذا التصنيف في تحديد الشخص المسؤول عن معالجة الأخطاء بشكل واضح. نعلم جميعًا أن أخطاء البرنامج تتم معالجتها بواسطة المطورين المعنيين. يناقش ما يلي بشكل أساسي أخطاء الطلب، انطلاقًا من الاسم، يجب معالجة أخطاء الطلب بواسطة موظفي الطلب. كيفية التعامل معها وكيف تكون فعالة في هذه العملية؟ في هذا الوقت، يقوم المختبرون لدينا بإرسال خطأ المتطلبات ليس إلى المبرمج، ولكن إلى محلل المتطلبات للمعالجة. ومع ذلك، ما أريد التأكيد عليه هنا هو تحديد موضع أخطاء المتطلبات. إذا تم ذكر هذا الخطأ بوضوح في مواصفات متطلبات البرنامج، فمن المستحيل تحديد موقعه باعتباره خطأ متطلبات، ويجب تنفيذه بواسطة المبرمجين ويسمى وظيفيًا برمجيًا العيب، يتم التعامل مع التقديم من قبل المبرمج. ولكن إذا لم تذكرها مواصفات المتطلبات بوضوح، فيمكننا تحديد موقعها كخطأ في المتطلبات.
ما ورد أعلاه هو المحتوى المتعلق بـ bugfree وآمل أن يكون مفيدًا للجميع.
أتمنى أن تكون هذه المقدمة عن BugFree مفيدة للجميع، وسيستمر محرر Downcodes في تقديم المزيد من المقالات التقنية العملية. إذا كان لديك أي أسئلة أو اقتراحات، يرجى ترك رسالة!