المثال التطبيقي الذي اختلف مع حاسبته الخاصة
أدير موقعاً إلكترونياً يحتوي على حاسبات لتكاليف تحسين المنازل.
تعرض كل صفحة نفس التكلفة في أربعة أماكن مختلفة:
- أداة تفاعلية (widget).
- جدول مرجعي ثابت.
- أمثلة نصية مكتوبة.
- قسم الأسئلة الشائعة.
اكتشفتُ خطأً برمجياً. ذكر أحد الأمثلة المكتوبة أن تكلفة المشروع بلغت 62,300 دولاراً، بينما ذكرت أداة الحاسبة أن تكلفة المشروع نفسه بلغت 56,779 دولاراً.
كان الفارق 5,500 دولار.
حدث الخطأ لأنني كتبت الأرقام يدوياً. لقد استخدمتُ افتراضات للنص تختلف عن تلك التي استخدمتها في الكود. افترض النص وجود وحدة تكييف (HVAC) جديدة، بينما افترض الكود وجود نظام حالي. كان كلاهما صحيحاً، لكنهما لم يتطابقا.
هذا فشل شائع. عندما تخزن الحقيقة نفسها في مكانين، فإنهما سيبتعدان عن بعضهما البعض.
لقد أصلحتُ هذا باستخدام قاعدتين.
القاعدة 1: منطق "المصدر أولاً".
دالة الحاسبة هي المكان الوحيد الذي يولد فيه الرقم. لم أعد أكتب الأرقام يدوياً في الجداول أو الفقرات، بل أستخدم الدالة لإنشاء الجداول والأمثلة أثناء عملية البناء (build time).
إذا تغيرت الدالة، تتغير الصفحة بأكملها. سيظل الجدول والأداة متفقين دائماً لأنهما يستخدمان المنطق نفسه.
القاعدة 2: إضافة المصدر (Provenance).
الرقم يكون مفيداً فقط إذا كنت تعرف مصدره. تتضمن كل عملية حسابية الآن ما يلي:
- السيناريو المحدد المستخدم.
- مصدر البيانات.
- تاريخ الوصول إلى البيانات.
- تاريخ انتهاء صلاحية البيانات.
بيانات التكلفة ليست حقيقة دائمة، بل هي حقيقة قابلة للتغير. إن إضافة تاريخ للمراجعة يذكرني بتحديث البيانات قبل أن تصبح خاطئة.
وجود مصدر واحد للحقيقة يجعلك متسقاً. وإضافة المصدر تجعلك صادقاً.
إذا كنت تعرض الرقم نفسه في مكانين، فلا تعد كتابته، بل قم باستيراده. اترك عملية البناء (build process) تتعامل مع التكرار.
المصدر: https://dev.to/mark_b5f4ffdd8e7cd58/the-worked-example-that-disagreed-with-its-own-calculator-4cp9