چگونه در MQL4 یک ربات ترید سالم و قابل اطمینان را توسعه دهیم

چگونه در MQL4 یک ربات ترید سالم و قابل

چگونه در MQL4 یک ربات ترید سالم و قابل اطمینان را توسعه دهیم

در فرآیند تولید یک برنامه، برنامه‌نویس و توسعه‌دهندگان با این واقعیت مواجه می‌شوند که برنامه‌شان ممکن است شامل تمام خطاهای ممکن و ناممکن باشد! و در مرحله‌ی توسعه، این خطاها بسیار دردسرساز هستند، که منجر به بی‌اعتمادی به روش کار شده، و اگر برنامه‌ی مدنظر، یک ربات معامله‌گر باشد، تاثیر منفی‌اَش را روی سرمایه‌تان خواهید دید! چه بد! بیایید رایج‌ترین خطاها، سرمنشأ آنها، و روش‌های شناسایی و پردازش‌ آنها را با هم آنالیز کنیم. در فرآیند توسعه و استفاده از یک اکسپرت برای نرم‌افزار متاتریدر ۴، این خطاها را ممکن است داشته باشیم:

  1. سینتکس – این خطاها ممکن است در مرحله‌ی کامپایل کردن ظاهر شوند و برنامه‌نویس به‌راحتی می‌تواند آنها را برطرف سازد؛
  2. منطقی – این خطاها با کامپایلر مشخص نمی‌شوند. برای مثال: به‌هم‌ریختگی در نام متغیرها، فراخوان‌های اشتباه تابع، بهره‌برداری از انواع مختلف داده‌ها و غیره؛
  3. الگوریتمی – این خطاها وقتی اتفاق می‌اُفتند که براکت‌ها دُرست سر جای خودشان نباشند، یا در صورت به‌هم‌ریختگی با گزاره‌های شاخه‌ها و غیره؛
  4. بُحرانی – این مدل خطاها غیرمحتمل‌تر هستند. [در صورت رخ دادن]، برای بیرون کشیدن آنها باید کمی زحمت بکشید. با این حال، وقتی با dll کار می‌کنید، کمتر این مدل خطا را دارید؛
  5. معامله‌ای – این مدل خطاها وقتی اتفاق می‌اُفتند که با معاملات سروکار دارید. این خطاها برای ربات‌های معامله‌گر، نقطه‌ی مناقصه هستند.

ابتدا اول از همه، پیشنهاد می‌کنیم، مستندات مربوط به خطاهای اجرایی را مطالعه کنید. با انجام این کار، زمان بسیار زیادی را ذخیره کرده‌اید بطوریکه بعداً نیاز نیست برای یک سری از موضوعات، وقت بگذارید. خطاهای ناشی از عملیات‌های ترید را نیز، از اینجا می‌توانید دریافت کنید.

خطاهای سینتکس

خطاهایی از این نوع، نتیجه‌ی اشتباهات چاپی عملگرها، متغیرها، و فراخوان‌های مختلف توابع است. حین کامپایل شدن، کد برنامه بررسی می‌شود و تمام خطاهای سینتکس در پنجره‌ی “Tools” در نرم‌افزار متااِدیتور، نشان داده ‌می‌شوند. در واقع، تقریباً همه‌ی خطاها شناسایی شده و برنامه‌نویس می‌تواند آنها را برطرف کند.

به‌هم‌ریختگی براکت‌ها یکی از موارد استثنا است. وقتی براکت‌هایی که بازشدن و بسته‌شدن را نشان می‌دهند، در جای اشتباهی قرار داده شوند، در مرحله‌ی کامپایل شناسایی شده، اما محل قرارگیری خطا، اشتباه نشان داده می‌شود. آنگاه مجبور هستید دوباره کد را چک کرده تا خطا را چشمی پیدا کنید که متاسفانه این کار ممکن است همیشه نتیجه ندهد. رویکرد دوم، خاموش شدن پی‌درپی بلوک‌های کد با استفاده از  comments(کامنت‌ها) است. در این شرایط، اگر بعد از کامنت‌گذاری یک بلوک جدید، خطا از بین رفت، می‌توان گفت خطا مسلماً در همان بلوک کامنت‌گذاری‌شده، بوده است. این کار به‌شکل چشمگیری محدوده‌ی جستجو را کم کرده و کمک می‌کند، قرارگیری اشتباه براکت‌ها را سریع پیدا کنیم.

خطاهای منطقی، الگوریتمی، و بُحرانی

رایج‌ترین خطاها از این نوع را می‌توان در به‌هم‌ریختگی نام‌ها و نوع متغیرها، و نیز خطاهای الگوریتمی را در شاخه‌های اکسپرت، پیدا کرد. برای مثال، بیایید این کد را بررسی کنیم:

چه چیزی می‌توانیم ببینیم؟ متغیر منطقی “Some”، که در تمام برنامه رایج است و شاخص مهمی برای بازشدن پوزیشن به‌حساب می‌آید، به‌طور تصادفی، کمتر از آنچه باید باشد، تعیین شده‌است. نتیجه، اشتباه بازشدن معامله و ضرر، خواهد بود. می‌‌توانید اسامی بسیاری را برای متغیرها انتخاب کنید، اما بنا بر دلایلی، این اسامی در برنامه‌های بزرگ، به‌طور تصادفی تکرار می‌شوند. و در نهایت می‌شود آن مشکلی که به آن اشاره کردیم.

این خطا وقتی اتفاق می‌اُفتد که متغیرها به‌نوعی با هم مخلوط شده، یا بیان یک نوع، به بیان نوع دیگری اختصاص یافته است. برای مثال، در این خط

سعی می‌کنیم که بیان مقدارِ نوعِ “double” را به متغیر نوع “int”، اختصاص دهیم، که نتیجه می‌شود: مقدار صفر. و ما هم خوش‌خیال در حال محاسبه‌ی حد سود هستیم! این نوع خطا منجر به معامله‌ی اشتباه می‌شود.

خطای الگوریتمی در شاخه‌های یک اکسپرت یعنی براکت‌ها طبق الگوریتم قرار نگرفته‌اند، یا پوشش اشتباه عملگرهای “if” توسط عملگرهای “else” اتفاق اُفتاده است. در نتیجه اکسپرتی داریم که مطابق با نیاز فنی کار نمی‌کند.

برخی خطاها غیرقابل تصور هستند، بطوریکه ساعت‌ها روی کد وقت می‌گذارید، و “به حالت مراقبه” می‌رسید تا خطا را پیدا کنید. متاسفانه امکان ردگیری مقادیر متغیرها در متااِدیتور وجود ندارد، که البته در محیط‌هایی مانند زبان‌های خانواده‌ی C++ چنین محدودیتی را نداریم. بنابراین، تنها راهی که می‌ماند، پیگیری خطاها از طریق پیام‌های (صادر شده توسط) تابع ()Print است.

تابع ()GetLastError، کد خطا را برمی‌گرداند. توصیه می‌شود که آخرین مقدار را بعد از هر یک از بخش‌های آسیب‌پذیر و حساس برنامه، بررسی کنید. با استفاده از کد خطا به‌سادگی می‌توانید توضیحات مربوط به خطا را در بخش مستندات پیدا کرده، و برای برخی از خطاها حتی روش‌های برطرف کردن هم موجود است.

باید این نکته را بگوییم که خطاهای مذکور، به احتمال خیلی زیاد، در مرحله‌ی تست گرفتن، قبل از رفتن روی حساب دمو، شناسایی می‌شوند، بنابراین ضررهای همراه این خطاها، غیرمحتمل هستند.

اصلی‌ترین ویژگی‌ خطاهای بحرانی این است که وقتی اتفاق می‌اُفتند، اجرای برنامه بلافاصله متوقف می‌شود. با این حال، کد خطا در متغیر از پیش تعیین‌شده‌ی “last_error”، دست‌نخورده باقی می‌ماند. این کار به ما این امکان را می‌دهد، کد خطایی که تابع ()GetLastError را فرامی‌خواند، یاد بگیریم.

خطاهای معامله‌ای

این خطاها اغلب منجر به ضرر و کار نکردن اکسپرت روی حساب دمو، و علاوه بر آن، روی حساب‌های واقعی، می‌شوند. این خطاها وقتی رخ می‌دهند که دارید معاملات را ارسال یا اصلاح می‌کنید، و به بیان دیگر، حین تعامل با سرور ترید، این خطاها را خواهید داشت.

پردازش ساده مثل این:

کمکی نخواهد کرد. مطمئن شدیم که معامله به سرور ارسال نشده، و کد خطا را یاد گرفتیم. پس چه چیزی؟ یک ورود مهم به بازار را از دست دادیم، البته، اگر اکسپرتی سودده می‌داشتیم.

حالتی با حلقه‌ی بی‌پایان:

کمی کمک می‌کند. معامله احتمالاً به سرور می‌رسد. اما برخی مشکلات ممکن است در سر راه باشند:

  1. بروکر درخواست‌های مکرر را دوست نخواهد داشت؛
  2. خطا ممکن است مهلک باشد، در اینجا درخواست به هیچ عنوان به سرور نخواهد رسید؛
  3. اکسپرت برای مدتی طولانی پاسخگو نخواهد بود؛
  4. سرور ممکن است درخواست‌های ترید را اصلاً نپذیرد – ممکن است آخر هفته باشد، تعطیلات باشد، کارهای تعمیر و نگهداری در دست انجام باشند و غیره.

تقریباً هر خطایی منحصربه‌فرد است و نیاز به برطرف شدن به سبک خودش را دارد. بیایید درباره‌ی حالتی با عملگر Switch صحبت کنیم و هر خطا را کم و بیش به‌صورت جداگانه رواج دهیم. خطای استاندارد #۱۴۶ –”Trade flow is busy”، با استفاده از سِمافور محقق‌شده در کتابخانه‌ی TradeContext.mqh، پردازش شده‌است. این کتابخانه و توضیحات دقیق آن را می‌توانید در این مقاله پیدا کنید.

این نسخه از ربات معامله‌گر در یک حلقه‌ی بی‌پایان کار می‌کند. و تقاضای آن زمانی است که اکسپرت چنداَرزی اِسکلپینگ، ایجاد شده باشد. الگوریتم عملکرد این اکسپرت، اینگونه است:

  1. سیگنال را از بلوک تحلیلی ()GetAction بگیر؛
  2. تراکنش لازم را در توابع ()Deal و ()CloseOrder انجام بده؛
  3. به نقطه‌ی ۱ بعد از یک توقف کوتاه time_for_action برگرد، در شرایطی که مشکل جدی مانند عدم موفقیت نبوده است.

بعد از دریافت سیگنال (خرید، فروش، بستن) از بلوک تحلیلی، اکسپرت جریان معاملاتی را مسدود کرده (این مقاله را بخوانید) و سعی می‌کند تراکنش را انجام دهد، و بعد از آن برای چند ثانیه توقف کرده و جریان معاملاتی را برای دیگر اکسپرت‌ها آزاد می‌کند. اکسپرت سعی می‌کند فرستادن معامله بیشتر از دفعات “شمارش” نباشد و همین برای عبور معامله در بازار ناپایداری که ممکن است ریکوت دریافت کنید، کافیست. اگر هنگام فرستادن معامله، خطایی جدی رخ دهد، اکسپرت کار را متوقف می‌کند. اگر هرگونه مشکلی پیش بیاید، پیام خطا در پوشه‌ی “Expert Advisors” ظاهر می‌شود. اگر خطا بحرانی نباشد، اکسپرت به کار خود ادامه می‌دهد.

خطاها در روند ()ErrorBlock، مطابق با چنین طرحی پردازش می‌شوند: روند، کد خطا را می‌گیرد و یک الگوریتم کوتاه برای پردازش آن ارائه می‌دهد. برای بیشتر خطاها، فقط یک پیام در گزارش است. اگر خطا جدی باشد، آنگاه شاخص‌های معاملاتی Trade و NoOpen تغییر می‌کنند. اگر مشکل قطع ارتباط باشد، پردازش شرایط کمی سخت‌تر می‌شود. ربات شصت بار، همراه با توالی دوره‌ای از پیش تعریف‌شده، تلاش می‌کند به سرور برسد. اگر به سرور دسترسی ایجاد نشد، احتمال زیاد مشکل جدی وجود دارد، و باید برای مدتی معاملات خود را متوقف کنید. بسته به تاثیر خطا روی ترید، الگوریتم پردازشی، معانی متفاوتی را برمی‌گرداند:

  • ۰ – بدون خطا؛
  • ۱ – خطا مربوط به نوسانات بازار است، می‌توانید بار دیگر تلاش کنید و معامله را بفرستید؛
  • ۲ – هنگام ارسال این معامله، خطای جدی رخ داد، برای مدتی پوزیشن جدید باز نکنید؛
  • ۳ – خطای جدی در اکسپرت، قطع ارتباط، تا زمان شفاف شدن موضوع، ترید را متوقف کنید.

نتیجه‌گیری

خطاهای سینتکس، الگوریتمی، و منطقی، زمانی رخ می‌دهند که توجه کافی به کدنویسی الگوریتم ندارید. این خطاها با بررسی و اصلاح مقادیر متغیرها در گزارش، برطرف می‌شوند. همچنین، این خطاها را می‌توان هنگام کامپایل کردن و تست گرفتن از اکسپرت نیز شناسایی کرد. این مدل از خطاها برای مدتی طولانی ماندگار نیستند، و قبل از رفتن به حساب دمو، برطرف می‌شوند.

خطاهای معامله‌ای زمانی رخ می‌دهند که معامله‌ای را به سرور می‌فرستیم. این خطاها با معامله‌ی واقعی سروکار دارند و ممکن است ریکوت، اُفت، نبرد معامله‌گرها با اِسکلپینگ، و مشکل در تجهیزات را، داشته باشید. چنین خطاهایی را نمی‌توان پیش‌بینی کرد. اما می‌توان و باید آن‌ها را پردازش کرد. بسته به منطق اکسپرت، تکرار تراکنش‌ها و اصلاح معاملات، می‌توانید هر هفته خطاها را به‌صورت جداگانه، بررسی و پردازش کنید.

خطاهایی که حین کار کردن اکسپرت رخ می‌دهند، باید پردازش شوند. کار کوچکی نیست و به پیچیدگی اکسپرت و ویژگی‌های آن بستگی دارد. در این مقاله می‌توانید الگوی نمونه‌ی اکسپرتی را پیدا کنید که این کار را انجام می‌دهد. ایجاد یک سیستم ترید با امنیت و سلامت بالا، زمان زیادی می‌طلبد. اما زمانی که صرف توسعه‌ی یک سیستم خودکار بدون مشکل می‌شود، صدها برابر با ایمن ماندن سرمایه و کار خوب و خواب راحت شما، جبران خواهد شد.

این مقاله دارای فایل پیوست است.

فایل پیوست مقاله را میتوانید از اینجا دانلود کنید .

 

مقالات پیشنهادی :

جواهری

→ خواندن مطلب قبلی

یک قالب جهانی برای اکسپرت متاتریدر

خواندن مطلب بعدی ←

مدل‌سازی ریکوت‌ها در تستر و تحلیل ثبات اکسپرت

نوشتن نظر شما

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

بیست − هشت =