هذه خاتمة سلسلة قصيرة عن بناء Freya Finance. بدلاً من تكرار المقالات، إليك ما كنت سأقوله فعلاً لنفسي في البداية، مرتّباً بحسب كم كلّفني تعلّم كل درس منها.
الخيط المشترك بينها مزعج: لم يُعلن أيٌّ من هذه الأعطال عن نفسه تقريباً. لقد أنتجت أرقاماً معقولة، وأوامر تبدو صحيحة، وشاشات تبدو سليمة. في نظام يتصرّف بأموال شخص ما، فإن العطل الذي يرمي استثناءً هو النوع الودود.
أهم النقاط
- واجهات API الخارجية تفشل بصمت. استجابة HTTP 200 تحمل بيانات أقل مما طلبت هي نمط العطل الذي يجب أن تصمّم حمايتك ضده، وليس الخطأ 500.
- اختبر المحاكي قبل أن تختبر أي شيء يحاكيه. المحاكي المعطوب يعيد أرقاماً تبدو تماماً مثل الأرقام الصحيحة.
- بلّغ عمّا لم تستطع محاكاته. نتيجة تذكر ثغرتها بوضوح أثمن من نتيجة نظيفة المظهر أسقطت شرطاً بصمت.
- الدقة مجال قائم بذاته، لا دالة مساعدة. أحجام الخطوة وأحجام النقطة والحدود الدنيا تختلف لكل زوج، ولكل منصة، ولكل نوع سوق.
- اختر قيودك مبكراً. قرار عدم الاحتفاظ بأموال المستخدمين إطلاقاً حذف فئة كاملة من المشكلات بدل أن يحلّها.
- في واجهة تتعامل مع المال، دقّق في الإيماءات التي تعاملها المنصة كتعديلات. تمرير عجلة الفأرة فوق حقل رقمي مُركَّز عليه واحدة منها.
1. افترض أن كل واجهة API تنجح بشكل خاطئ أحياناً
أغلى افتراض ارتكبته هو أن الطلب الفاشل سيبدو كفشل.
المنصات تحت الضغط تعيد HTTP 200 مع عدد شموع أقل من المطلوب، بلا حقل خطأ، بلا تحذير. أحد اختباراتنا الرجعية العميقة طلب نحو 536,000 شمعة فتلقّى 58,000. الطلب نفسه بعد ساعة أعاد المجموعة كاملة. لم يكن في الاستجابة ما يميّز بين الحالتين.
إن لم تكن تتحقق، فسيحاكي المحرّك استراتيجيةً على جزء ضئيل من التاريخ المقصود ويبلّغ عن رقم واثق. هذا أسوأ من الانهيار، لأن الانهيار صادق.
خرجنا من هذا بقاعدتين: تحقّق من بنية الاستجابة الناجحة، لا من رمز حالتها فحسب، وميّز بين الأعطال العابرة والأعطال الدائمة قبل أن تقرر ما تفعل. تبدوان متطابقتين لحظة حدوثهما لكنهما تستحقان استجابتين متعاكستين.
2. اختبر المحاكي، لا الاستراتيجية
كل غريزة تدفعك لاختبار منطق الاستراتيجية، لأنه الجزء المثير. الفخ هو أن المحاكي المعطوب ينتج مخرجات لا يمكن تمييزها عن مخرجات المحاكي السليم. التشغيل الذي عالج بصمت عُشر البيانات لا يزال يعيد رقماً. والتشغيل الذي لم تُقيَّم فيه المخارج أبداً يعيد رقماً مسطّحاً على نحو مريب.
النقلة التي أصلحت هذا كانت التحقّق من أشياء لا تستطيع الاستراتيجية تغييرها: أن الشموع المعالَجة تطابق الشموع المجلوبة، وأن التشغيل على مدة معلومة يغطّيها فعلاً، وأن إعداداً مضموناً أنه سيُطلق الأوامر يُنتج صفقات.
حين تصمد هذه الثوابت، تصبح النتيجة الغريبة اكتشافاً حقيقياً. وحين لا تصمد، تكون النتيجة ضجيجاً يرتدي بذلة.
3. بلّغ عمّا لم تستطع محاكاته
هذا قرار تصميمي أكثر منه عطل، وأظنه الأكثر بخساً في التقدير.
بعض الظروف لا يمكن إعادة تشغيلها. إشارة webhook خارجية ليس لها سجل تاريخي. الخطوة المغرية هي تخطّيها وتقييم الباقي، ما يجعل المخرجات تبدو كاملة.
انظر ماذا يفعل ذلك باستراتيجية تتطلب A و B معاً. إن تعذّرت محاكاة B، يقرر A وحده، فيدخل الروبوت المُحاكى حيث كان الروبوت الحقيقي سيبقى خارجاً. الخطأ ليس عشوائياً: إسقاط شرط ضمن منطق «و» لا يمكن إلا أن يُنتج صفقات أكثر من الواقع، فالانحياز يشير إلى نتيجة أجمل مظهراً في كل مرة دون استثناء.
أبقينا المحاكاة تعمل، لكن النتيجة تحمل تحذيراً صريحاً يسمّي ما جرى تخطّيه. المحاكي الذي لا يستطيع الفشل بصخب سيفشل بصمت، والفشل الصامت في شيء يُنتج أرقاماً هو أسوأ أنماط الفشل على الإطلاق.
القصة كاملة: لماذا تكذب الاختبارات الرجعية
4. منحنى الأسهم الأملس سؤال، لا جواب
مرتبط بما سبق، ويستحق الفصل لأنه يخدع البشر لا الشيفرة.
شبكة DCA بلا إيقاف خسارة لا تحقق خسارة فعلية إلا نادراً جداً. إنها تحتفظ وتضيف. لذا تكون الصفقات المغلقة كلها رابحة تقريباً، ويبدو معدل الربح ممتازاً، ويكون منحنى الأسهم درجاً مرتباً.
المخاطرة لم تذهب إلى أي مكان. لقد أُجّلت، وللتأجيل حدّ صارم: رأس المال المتبقي لأوامر أمان إضافية. السؤال المفيد ليس «كم بلغ الـ Drawdown» بل «إن استمر السعر يتحرك ضد هذا، فعند أي نقطة تنفد الاستراتيجية من المساحة؟»
الـ Drawdown نفسه يحتاج القدر ذاته من الشك. يُقاس مقابل رأس المال المخصص عند ذروته، لذا الخسارة نفسها البالغة 200 USDT تظهر كـ 40% على تخصيص قدره 500 USDT وكـ 4% على 5,000. روبوتان يتداولان بشكل متطابق قد يعرضان أرقاماً متباينة تماماً.
5. الدقة مجال قائم بذاته، لا دالة مساعِدة
صنّفت «تقريب الكميات إلى خطوات صحيحة» كدالة مساعدة واحدة. إنه صنف كامل من العمل، ويختبئ في مكان تكلّف فيه الأخطاء مالاً.
الفاصلة العائمة تبدأ الأمر: ضرب 0.29 بخطوة قدرها 0.01 يعطي 28.999999999999996، ما يجعله يُقرَّب للأسفل بخطوة كاملة أقل من اللازم، بصمت، باتجاه أمر أصغر.
ثم تختلف المنصات على القواعد نفسها. واحدة تفحص قيمة الأمر بالـ USDT، وأخرى تفحص عدد العقود دون أي فحص للقيمة إطلاقاً، وثالثة تفحص الاثنين. أسوأ عطل لنا في هذا المجال جاء من اختراع حدّ أدنى لا وجود له في إحدى المنصات، ثم رفض أوامر صحيحة استناداً إليه. العلامة الدالة، في الاستعادة، كانت أن نسختنا من القيد تعتمد على السعر بينما القيد الحقيقي لا يعتمد عليه.
في أي مكان تكتب فيه ثابتاً واحداً لشيء تعرّفه المنصة لكل زوج، أنت تكتب عطلاً بفتيل مؤجّل.
القصة كاملة: الفاصلة العائمة ستكلّفك مالاً
6. اختر قيودك مبكراً
الدرس الأخير ليس خطأً. إنه قرار استهنت بعواقبه على نحو حسن.
Freya لا تحتفظ أبداً بأموال تداول المستخدمين. المفاتيح تحمل صلاحية القراءة والتداول، لا صلاحية السحب أبداً، والمفتاح الذي يصل ومعه صلاحية سحب يُرفض بدل أن يُقبَل ويُتجاهل. هذا التمييز أهم مما يبدو: «لن نسحب» ادعاء عن سلوكنا لا يستطيع المستخدم التحقق منه، بينما «المفتاح لا يستطيع السحب» يفرضه فرضاً على المنصة ويمكن للمستخدم التحقق منه في إعداداته الخاصة.
توقعت أن يكون هذا نقطة تسويقية. تبيّن أنه معماري، وقد جعل النظام أصغر: لا دفتر حفظ أمانات، لا مطابقة، لا طابور سحب، لا سياسة تخزين بارد لرأس مال التداول. صنف كامل من أصعب المشكلات في البرمجيات المالية غائب لأننا لم نتحمّل قط الشيء الذي يخلقها.
ما يحل محله أضيق وأحدّ: على النظام أن يكون صحيحاً في الزمن الحقيقي، لأنه لا يستطيع أبداً التراجع عن أي شيء. الأمر المنفَّذ على حساب منصة شخص آخر نهائي.
القصة كاملة: تصميم تداول غير احتجازي
الدرس الذي لم أتوقع أن أحتاجه
درس إضافي، لأنه فاجأني أكثر من غيره: في واجهة تتعامل مع المال، تحتاج الواجهة الأمامية القدر نفسه من الحذر الذي يحتاجه المحرّك.
حقل <input type="number"> مُركَّز عليه يغيّر قيمته حين تمرّر العجلة فوقه. على منتقي كمية، هذا إزعاج. على الرافعة المالية وحجم الأمر والسعر، يعيد كتابة ما اختاره المستخدم بصمت، ويظل النموذج يُصادِق على المدخلات. لا شيء من هذا العطل ظاهر في لقطة شاشة.
القصة كاملة: عجلة الفأرة تعدّل حقولك الرقمية
لو ضغطت كل ذلك في سطر واحد
ابنِ للأعطال التي لا تُعلن عن نفسها. أما تلك التي ترمي استثناءً فستجدك من تلقاء نفسها.