الگورتھمک ٹریڈنگ سسٹم کے لیے بہترین پروگرامنگ زبان؟

میل بیگ میں مجھے موصول ہونے والے سب سے عام سوالات میں سے ایک یہ ہے کہ الگورتھم ٹریڈنگ کے لئے بہترین پروگرامنگ زبان کیا ہے؟ مختصر جواب یہ ہے کہ کوئی بہترین زبان نہیں ہے۔ حکمت عملی کے پیرامیٹرز ، کارکردگی ، ماڈیولرٹی ، ترقی ، لچک اور لاگت پر سب کو غور کرنا ہوگا۔ یہ مضمون الگورتھم ٹریڈنگ سسٹم فن تعمیر کے ضروری اجزاء کا خاکہ پیش کرے گا اور کس طرح عمل درآمد سے متعلق فیصلے زبان کے انتخاب کو متاثر کرتے ہیں۔

سب سے پہلے ، الگورتھمک ٹریڈنگ سسٹم کے اہم اجزاء پر غور کیا جائے گا ، جیسے تحقیقی ٹولز ، پورٹ فولیو آپٹیمائزر ، رسک مینیجر اور ایگزیکشن انجن۔ اس کے بعد ، مختلف تجارتی حکمت عملیوں کا جائزہ لیا جائے گا اور وہ سسٹم کے ڈیزائن کو کس طرح متاثر کرتے ہیں۔ خاص طور پر تجارت کی تعدد اور ممکنہ تجارتی حجم دونوں پر تبادلہ خیال کیا جائے گا۔

ایک بار جب تجارتی حکمت عملی کا انتخاب ہوجائے تو ، پورے سسٹم کا فن تعمیر کرنا ضروری ہے۔ اس میں ہارڈ ویئر ، آپریٹنگ سسٹم (((s) اور نایاب ، ممکنہ طور پر تباہ کن واقعات کے خلاف سسٹم کی لچک شامل ہے۔ جبکہ فن تعمیر پر غور کیا جارہا ہے ، کارکردگی پر مناسب توجہ دی جانی چاہئے - تحقیق کے اوزار کے ساتھ ساتھ براہ راست عملدرآمد کے ماحول کو بھی۔

تجارتی نظام کیا کرنے کی کوشش کر رہا ہے؟

خودکار تجارتی نظام لکھنے کے لئے بہترین زبان پر فیصلہ کرنے سے پہلے ضروریات کی وضاحت کرنا ضروری ہے۔ کیا نظام خالصتا execution پر مبنی ہوگا؟ کیا نظام کو رسک مینجمنٹ یا پورٹ فولیو کنسٹرکشن ماڈیول کی ضرورت ہوگی؟ کیا نظام کو اعلی کارکردگی والے بیک ٹیسٹر کی ضرورت ہوگی؟ زیادہ تر حکمت عملیوں کے لئے تجارتی نظام کو دو اقسام میں تقسیم کیا جاسکتا ہے: تحقیق اور سگنل کی تخلیق۔

تحقیق تاریخی اعداد و شمار پر حکمت عملی کی کارکردگی کا اندازہ لگانے سے متعلق ہے۔ پچھلے مارکیٹ کے اعداد و شمار پر تجارتی حکمت عملی کا اندازہ لگانے کے عمل کو بیک ٹسٹنگ کہا جاتا ہے۔ ڈیٹا کا سائز اور الگورتھمک پیچیدگی کا بیک ٹیسٹر کی کمپیوٹیشنل شدت پر بہت زیادہ اثر پڑے گا۔ سی پی یو کی رفتار اور ہم وقت سازی اکثر تحقیق کے عملدرآمد کی رفتار کو بہتر بنانے میں محدود عوامل ہیں۔

سگنل جنریشن ایک الگورتھم سے تجارتی سگنلز کا ایک سیٹ تیار کرنے اور عام طور پر بروکرج کے ذریعہ مارکیٹ میں ایسے آرڈرز بھیجنے سے متعلق ہے۔ کچھ حکمت عملیوں کے لئے اعلی سطح کی کارکردگی کی ضرورت ہوتی ہے۔ نیٹ ورک بینڈوتھ اور لیٹینسی جیسے I / O کے مسائل اکثر عمل درآمد کے نظام کو بہتر بنانے میں محدود عنصر ہوتے ہیں۔ اس طرح آپ کے پورے سسٹم کے ہر جزو کے لئے زبانوں کا انتخاب بہت مختلف ہوسکتا ہے۔

حکمت عملی کی قسم، تعدد اور حجم

استعمال شدہ الگورتھم حکمت عملی کی قسم کا نظام کے ڈیزائن پر کافی اثر پڑے گا۔ اس کے لئے تجارت کی جانے والی منڈیوں ، بیرونی ڈیٹا وینڈرز سے رابطے ، حکمت عملی کی تعدد اور حجم ، ترقی کی آسانی اور کارکردگی کو بہتر بنانے کے مابین سمجھوتہ ، نیز کسی بھی کسٹم ہارڈ ویئر پر غور کرنا ضروری ہوگا ، جس میں مشترکہ کسٹم سرورز ، جی پی یو یا ایف پی اے شامل ہیں جو ضروری ہوسکتے ہیں۔

کم تعدد والی امریکی ایکویٹیز کی حکمت عملی کے لئے ٹیکنالوجی کے انتخاب فیوچر مارکیٹ میں تجارت کرنے والی اعلی تعدد والی شماریاتی ثالثی کی حکمت عملی سے بہت مختلف ہوں گے۔ زبان کے انتخاب سے پہلے بہت سارے ڈیٹا وینڈرز کا اندازہ کرنا ضروری ہے جو اس حکمت عملی سے متعلق ہیں۔

یہ ضروری ہوگا کہ وینڈر سے رابطے ، کسی بھی API کی ساخت ، ڈیٹا کی بروقت ، اسٹوریج کی ضروریات اور کسی وینڈر کے آف لائن ہونے کے چہرے میں لچک پر غور کیا جائے۔ متعدد وینڈرز تک فوری رسائی حاصل کرنا بھی سمجھدار ہے۔ مختلف آلات میں سب کی اپنی اسٹوریج کیرکس ہیں ، جن کی مثالوں میں ایکوئٹی کے لئے متعدد ٹکر علامتیں اور فیوچر کے لئے میعاد ختم ہونے کی تاریخیں (کسی مخصوص او ٹی سی ڈیٹا کا ذکر نہیں کرنا) شامل ہیں۔ اس کو پلیٹ فارم ڈیزائن میں مدنظر رکھنے کی ضرورت ہے۔

حکمت عملی کی تعدد ممکنہ طور پر ٹیکنالوجی اسٹیک کی وضاحت کرنے کے سب سے بڑے ڈرائیوروں میں سے ایک ہوگی۔ منٹ یا دوسری بار بار سے زیادہ کثرت سے ڈیٹا استعمال کرنے والی حکمت عملیوں کو کارکردگی کے سلسلے میں نمایاں غور کرنے کی ضرورت ہے۔

سیکنڈری بار (یعنی ٹِک ڈیٹا) سے تجاوز کرنے والی حکمت عملی کارکردگی پر مبنی ڈیزائن کو بنیادی ضرورت کے طور پر انجام دیتی ہے۔ اعلی تعدد کی حکمت عملیوں کے ل a کافی مقدار میں مارکیٹ کے اعداد و شمار کو ذخیرہ کرنے اور ان کا جائزہ لینے کی ضرورت ہوگی۔ ان کرداروں کے لئے عام طور پر ایچ ڈی ایف 5 یا کے ڈی بی + جیسے سافٹ ویئر کا استعمال کیا جاتا ہے۔

ایچ ایف ٹی ایپلی کیشنز کے لئے درکار اعداد و شمار کے وسیع حجم پر کارروائی کرنے کے ل extensively ، ایک وسیع پیمانے پر بہتر بیک ٹیسٹر اور عمل درآمد کا نظام استعمال کرنا ضروری ہے۔ سی / سی ++ (ممکنہ طور پر کسی اسمبلی کے ساتھ) سب سے مضبوط زبان کے امیدوار ہونے کا امکان ہے۔ انتہائی اعلی تعدد کی حکمت عملیوں میں تقریبا یقینی طور پر کسٹم ہارڈ ویئر کی ضرورت ہوگی جیسے ایف پی جی اے ، ایکسچینج کو لوکیشن اور کرنل / نیٹ ورک انٹرفیس ٹوننگ۔

تحقیقی نظام

ریسرچ سسٹم میں عام طور پر انٹرایکٹو ڈویلپمنٹ اور خودکار اسکرپٹنگ کا مرکب شامل ہوتا ہے۔ سابقہ اکثر آئی ڈی ای جیسے ویژول اسٹوڈیو ، میٹ لیب یا آر اسٹوڈیو کے اندر ہوتا ہے۔ مؤخر الذکر میں متعدد پیرامیٹرز اور ڈیٹا پوائنٹس پر وسیع عددی حساب کتاب شامل ہوتا ہے۔ اس سے زبان کا انتخاب ہوتا ہے جو کوڈ کی جانچ کے لئے ایک سیدھا ماحول فراہم کرتا ہے ، لیکن متعدد پیرامیٹر جہتوں پر حکمت عملیوں کا جائزہ لینے کے لئے کافی کارکردگی بھی فراہم کرتا ہے۔

اس جگہ میں عام آئی ڈی ایز میں مائیکروسافٹ بصری سی ++ / سی # شامل ہیں ، جس میں ڈیبگنگ کی وسیع افادیت ، کوڈ کی تکمیل کی صلاحیتیں (Intellisense) اور پورے پروجیکٹ اسٹیک کا براہ راست جائزہ (ڈیٹا بیس ORM ، LINQ کے ذریعے) شامل ہیں۔ میٹ لیب ، جو وسیع عددی لکیری الجبرا اور ویکٹرائزڈ آپریشنز کے لئے ڈیزائن کیا گیا ہے ، لیکن انٹرایکٹو کنسول انداز میں۔ آر اسٹوڈیو ، جو Rstatistical زبان کنسول کو ایک مکمل IDE میں لپیٹتا ہے۔ جاوا لینکس اور C ++ کے لئے Eclipse IDE؛ اور نیم ملکیتی آئی ڈی ای جیسے Enthought Canopy for Python ، جس میں ایک ہی انٹرایکٹو (کنسول) ماحول میں اعداد و شمار کے تجزیہ کی لائبریریاں جیسے NumPy ، SciPy ، scikit-learn اور پانڈا شامل ہیں۔

عددی بیک ٹسٹنگ کے لئے ، مذکورہ بالا تمام زبانیں موزوں ہیں ، حالانکہ GUI / IDE کا استعمال ضروری نہیں ہے کیونکہ کوڈ پس منظر میں پر عملدرآمد کیا جائے گا۔ اس مرحلے میں بنیادی غور و خوض عملدرآمد کی رفتار ہے۔ ایک مرتب شدہ زبان (جیسے C ++) اکثر مفید ہوتی ہے اگر بیک ٹسٹنگ پیرامیٹر طول و عرض بڑے ہوتے ہیں۔ یاد رکھیں کہ اگر ایسا ہوتا ہے تو ایسے نظاموں سے محتاط رہنا ضروری ہے!

ترجمانی شدہ زبانیں جیسے پائتھون اکثر بیک ٹیسٹنگ کے مرحلے کے لئے اعلی کارکردگی کی لائبریریوں جیسے نمپی / پانڈا کا استعمال کرتے ہیں ، تاکہ مرتب کردہ مساویوں کے ساتھ مسابقتی صلاحیت کی مناسب ڈگری کو برقرار رکھا جاسکے۔ بالآخر بیک ٹیسٹنگ کے لئے منتخب کردہ زبان مخصوص الگورتھم کی ضروریات کے ساتھ ساتھ زبان میں دستیاب لائبریریوں کی حد سے بھی طے کی جائے گی۔ تاہم ، بیک ٹیسٹر اور تحقیقی ماحول کے لئے استعمال ہونے والی زبان تعمیراتی پورٹ فولیو ، رسک مینجمنٹ اور عمل درآمد کے اجزاء میں استعمال ہونے والی زبان سے مکمل طور پر آزاد ہوسکتی ہے ، جیسا کہ دیکھا جائے گا۔

پورٹ فولیو کی تعمیر اور رسک مینجمنٹ

پورٹ فولیو کی تعمیر اور رسک مینجمنٹ کے اجزاء کو اکثر خوردہ الگورتھمک تاجر نظرانداز کرتے ہیں۔ یہ تقریبا always ہمیشہ ایک غلطی ہوتی ہے۔ یہ ٹولز وہ طریقہ فراہم کرتے ہیں جس کے ذریعہ سرمایہ کو محفوظ رکھا جائے گا۔ وہ نہ صرف خطرناک شرطوں کی تعداد کو کم کرنے کی کوشش کرتے ہیں ، بلکہ خود ہی تجارت کو کم سے کم کرتے ہیں ، لین دین کی لاگت کو کم کرتے ہیں۔

ان اجزاء کے نفیس ورژن کا منافع بخش کے معیار اور مستقل مزاجی پر نمایاں اثر پڑ سکتا ہے۔ حکمت عملیوں کا مستحکم بنانا آسان ہے کیونکہ پورٹ فولیو کی تعمیر کے طریقہ کار اور رسک مینیجر کو متعدد نظاموں کو سنبھالنے کے لئے آسانی سے تبدیل کیا جاسکتا ہے۔ اس طرح انہیں الگورتھم ٹریڈنگ سسٹم کے ڈیزائن کے آغاز میں ضروری اجزاء سمجھا جانا چاہئے۔

پورٹ فولیو کی تعمیر کے نظام کا کام مطلوبہ تجارتوں کا ایک سیٹ لینا اور اصل تجارتوں کا ایک سیٹ تیار کرنا ہے جو چرن کو کم سے کم کرتا ہے ، مختلف عوامل (جیسے شعبوں ، اثاثہ جات کی کلاسوں ، اتار چڑھاؤ وغیرہ) کے لئے نمائش کو برقرار رکھتا ہے اور پورٹ فولیو میں مختلف حکمت عملیوں میں سرمایہ کی تخصیص کو بہتر بناتا ہے۔

پورٹ فولیو کی تعمیر اکثر لکیری الجبرا کے مسئلے (جیسے میٹرکس فیکٹرائزیشن) تک کم ہوتی ہے اور اس وجہ سے کارکردگی دستیاب عددی لکیری الجبرا کے نفاذ کی تاثیر پر بہت زیادہ منحصر ہے۔ عام لائبریریوں میں uBLAS ، LAPACK اور NAG شامل ہیں۔ C ++ کے لئے میٹ لیب میں وسیع پیمانے پر بہتر میٹرکس آپریشنز بھی موجود ہیں۔ اس طرح کے حساب کتاب کے ل Python پیتھون NumPy / SciPy کا استعمال کرتا ہے۔ اکثر دوبارہ توازن والے پورٹ فولیو کو اس مرحلے کو انجام دینے کے لئے مرتب شدہ (اور اچھی طرح سے بہتر!)

رسک مینجمنٹ ایک الگورتھمک ٹریڈنگ سسٹم کا ایک اور انتہائی اہم حصہ ہے۔ خطرہ بہت سی شکلوں میں آسکتا ہے: بڑھتی ہوئی اتار چڑھاؤ (اگرچہ یہ کچھ حکمت عملیوں کے لئے مطلوبہ سمجھا جاسکتا ہے!) ، اثاثہ جات کی کلاسوں کے مابین بڑھتے ہوئے رابطے ، ہم منصب کی ڈیفالٹ ، سرور کی ناکامی ، بلیک سوان واقعات اور تجارتی کوڈ میں ناقابل شناخت کیڑے ، کچھ نام لینا۔

خطرہ مینجمنٹ کے اجزاء اثاثہ جات کی کلاسوں کے مابین زیادہ اتار چڑھاؤ اور ارتباط کے اثرات اور تجارتی سرمایہ پر ان کے بعد کے اثرات کا اندازہ لگانے کی کوشش کرتے ہیں۔ اکثر یہ اعدادوشمار کے حساب کتاب کے ایک سیٹ جیسے مونٹی کارلو تناؤ کے ٹیسٹ تک کم ہوتا ہے۔ یہ مشتق قیمتوں کا تعین کرنے والے انجن کی حساب کتاب کی ضروریات سے بہت ملتا جلتا ہے اور اس طرح سی پی یو سے منسلک ہوگا۔ یہ نقلیات انتہائی متوازی ہیں (نیچے دیکھیں) اور ، ایک خاص حد تک ، اس مسئلے پر ہارڈ ویئر پھینکنا ممکن ہے۔

عملدرآمد کے نظام

عملدرآمد کے نظام کا کام پورٹ فولیو کی تعمیر اور رسک مینجمنٹ کے اجزاء سے فلٹر شدہ تجارتی سگنل وصول کرنا اور انہیں بروکرج یا مارکیٹ تک رسائی کے دوسرے ذرائع پر بھیجنا ہے۔ خوردہ الگورتھمک تجارتی حکمت عملیوں کی اکثریت کے ل this اس میں انٹرایکٹو بروکرز جیسے بروکرج سے API یا FIX کنکشن شامل ہوتا ہے۔ زبان کا فیصلہ کرتے وقت بنیادی غور میں API کا معیار ، API کے لئے زبان کی لپیٹ کی دستیابی ، عملدرآمد کی تعدد اور متوقع سلائپج شامل ہیں۔

API کے معیار سے مراد یہ ہے کہ یہ کس طرح دستاویزی ہے ، یہ کس طرح کی کارکردگی فراہم کرتا ہے ، چاہے اس تک رسائی حاصل کرنے کے لئے اس کو اسٹینڈل سافٹ ویئر کی ضرورت ہو یا گیٹ وے کو بغیر کسی ہیڈ کے انداز میں قائم کیا جاسکتا ہے (یعنی کوئی GUI نہیں) ۔ انٹرایکٹو بروکرز کے معاملے میں ، ٹریڈر ورک اسٹیشن ٹول کو ان کے API تک رسائی حاصل کرنے کے لئے GUI ماحول میں چلانے کی ضرورت ہے۔ مجھے ایک بار ایمیزون کلاؤڈ سرور پر ڈیسک ٹاپ اوبنٹو ایڈیشن انسٹال کرنا پڑا تاکہ انٹرایکٹو بروکرز تک دور سے رسائی حاصل کی جاسکے ، محض اس وجہ سے!

زیادہ تر APIs C ++ اور / یا جاوا انٹرفیس فراہم کریں گے۔ عام طور پر C # ، پایتون ، R ، ایکسل اور میٹ لیب کے لئے زبان کے مخصوص لپیٹ تیار کرنا کمیونٹی پر منحصر ہوتا ہے۔ نوٹ کریں کہ ہر اضافی پلگ ان کے ساتھ استعمال کیا جاتا ہے (خاص طور پر API لپیٹنے والے) سسٹم میں خرگوشوں کی گنجائش ہوتی ہے۔ ہمیشہ اس طرح کے پلگ ان کی جانچ کریں اور اس بات کو یقینی بنائیں کہ ان کی فعال دیکھ بھال کی جائے۔ ایک قابل قدر گیج یہ دیکھنا ہے کہ حالیہ مہینوں میں کوڈ بیس میں کتنی نئی تازہ کاری کی گئی ہے۔

عملدرآمد کی تعدد عملدرآمد کے الگورتھم میں انتہائی اہمیت کا حامل ہے۔ نوٹ کریں کہ ہر منٹ میں سیکڑوں آرڈر بھیجے جاسکتے ہیں اور اس طرح کی کارکردگی اہم ہے۔ خراب کارکردگی کا مظاہرہ کرنے والے عملدرآمد کے نظام کے ذریعے سلائپج ہوگا اور اس کا منافع پر ڈرامائی اثر پڑے گا۔

جامد طور پر ٹائپ شدہ زبانیں (نیچے ملاحظہ کریں) جیسے سی ++ / جاوا عام طور پر عمل درآمد کے لئے بہترین ہیں لیکن ترقی کے وقت ، جانچ اور دیکھ بھال کی آسانی میں تجارت ہوتی ہے۔ متحرک طور پر ٹائپ شدہ زبانیں ، جیسے پائتھون اور پرل اب عام طور پر کافی تیز ہیں۔ ہمیشہ اس بات کو یقینی بنائیں کہ اجزاء کو ماڈیولر انداز میں ڈیزائن کیا گیا ہے (نیچے ملاحظہ کریں) تاکہ انہیں تبدیل کیا جاسکے جب نظام پیمانے پر ہو۔

فن تعمیراتی منصوبہ بندی اور ترقی کا عمل

تجارتی نظام کے اجزاء ، اس کی تعدد اور حجم کی ضروریات پر اوپر تبادلہ خیال کیا گیا ہے ، لیکن سسٹم انفراسٹرکچر کو ابھی تک احاطہ نہیں کیا گیا ہے۔ خوردہ تاجر کی حیثیت سے کام کرنے والے یا چھوٹے فنڈ میں کام کرنے والے لوگ ممکنہ طور پر بہت سی ٹوپیاں پہنیں گے۔ الفا ماڈل ، رسک مینجمنٹ اور عملدرآمد کے پیرامیٹرز ، اور نظام کے حتمی نفاذ کو بھی احاطہ کرنا ضروری ہوگا۔ مخصوص زبانوں میں گہرائی سے جانے سے پہلے ، ایک بہترین سسٹم فن تعمیر کے ڈیزائن پر تبادلہ خیال کیا جائے گا۔

پریشانیوں کو الگ کرنا

سب سے اہم فیصلوں میں سے ایک جو شروع میں کیا جانا چاہئے وہ یہ ہے کہ کس طرح تجارتی نظام کے خدشات کو الگ کیا جائے۔ سافٹ ویئر کی ترقی میں ، اس کا بنیادی طور پر مطلب یہ ہے کہ کس طرح تجارتی نظام کے مختلف پہلوؤں کو الگ الگ ماڈیولر اجزاء میں تقسیم کیا جائے۔

ہر جزو پر انٹرفیس کو بے نقاب کرکے نظام کے کچھ حصوں کو دوسرے ورژن کے لئے تبدیل کرنا آسان ہے جو کارکردگی ، وشوسنییتا یا دیکھ بھال میں مدد کرتے ہیں ، بغیر کسی بیرونی انحصار کوڈ میں ترمیم کیے۔ یہ ایسے نظاموں کے لئے بہترین عمل ہے۔ کم تعدد پر حکمت عملیوں کے ل such ایسے طریقوں کا مشورہ دیا جاتا ہے۔ انتہائی اعلی تعدد کی تجارت کے ل the اصول کتاب کو نظرانداز کرنا پڑ سکتا ہے تاکہ نظام کو اور بھی زیادہ کارکردگی کے ل twe twe ٹویک کیا جاسکے۔ ایک زیادہ مضبوطی سے منسلک نظام مطلوبہ ہوسکتا ہے۔

الگورتھمک ٹریڈنگ سسٹم کے اجزاء کا نقشہ بنانا خود ہی ایک مضمون کے قابل ہے۔ تاہم ، ایک بہترین نقطہ نظر یہ یقینی بنانا ہے کہ تاریخی اور حقیقی وقت کے مارکیٹ ڈیٹا ان پٹ ، ڈیٹا اسٹوریج ، ڈیٹا تک رسائی API ، بیک ٹیسٹر ، حکمت عملی کے پیرامیٹرز ، پورٹ فولیو کی تعمیر ، رسک مینجمنٹ اور خودکار عمل درآمد کے نظام کے لئے الگ الگ اجزاء موجود ہیں۔

مثال کے طور پر ، اگر استعمال ہونے والا ڈیٹا اسٹور فی الحال کارکردگی سے کم ہے ، یہاں تک کہ اصلاح کی نمایاں سطحوں پر بھی ، اسے ڈیٹا انجیکشن یا ڈیٹا تک رسائی API میں کم سے کم دوبارہ لکھنے کے ساتھ تبدیل کیا جاسکتا ہے۔ جہاں تک بیک ٹیسٹر اور بعد کے اجزاء کا تعلق ہے ، کوئی فرق نہیں ہے۔

علیحدہ اجزاء کا ایک اور فائدہ یہ ہے کہ یہ مجموعی نظام میں مختلف قسم کی پروگرامنگ زبانوں کو استعمال کرنے کی اجازت دیتا ہے۔ اگر اجزاء کا مواصلات کا طریقہ زبان سے آزاد ہے تو کسی ایک زبان تک محدود رہنے کی ضرورت نہیں ہے۔ اگر وہ ٹی سی پی / آئی پی ، زیرو ایم کیو یا کسی اور زبان سے آزاد پروٹوکول کے ذریعے بات چیت کر رہے ہیں تو ایسا ہی ہوگا۔

ایک ٹھوس مثال کے طور پر ، ایک بیک ٹیسٹنگ سسٹم کے معاملے پر غور کریں جو C ++ میں نمبر کرنچنگ کارکردگی کے لئے لکھا گیا ہے ، جبکہ پورٹ فولیو مینیجر اور عملدرآمد کے نظام پیتھون میں SciPy اور IBPy کا استعمال کرتے ہوئے لکھے گئے ہیں۔

کارکردگی پر غور

کارکردگی زیادہ تر تجارتی حکمت عملیوں کے لئے ایک اہم غور ہے۔ اعلی تعدد کی حکمت عملیوں کے ل it یہ سب سے اہم عنصر ہے۔ کارکردگی مسائل کی ایک وسیع رینج کا احاطہ کرتی ہے ، جیسے الگورتھمک عملدرآمد کی رفتار ، نیٹ ورک لیٹنس ، بینڈوڈتھ ، ڈیٹا I / O ، ہم وقت سازی / متوازی اور اسکیلنگ۔ ان علاقوں میں سے ہر ایک کو بڑی درسی کتابوں میں انفرادی طور پر احاطہ کیا گیا ہے ، لہذا یہ مضمون صرف ہر موضوع کی سطح کو کچلتا ہے۔ فن تعمیر اور زبان کے انتخاب پر اب کارکردگی پر ان کے اثرات کے لحاظ سے تبادلہ خیال کیا جائے گا۔

کمپیوٹر سائنس کے باپ دادا میں سے ایک ، ڈونلڈ نوتھ کے مطابق غالب حکمت یہ ہے کہ وقت سے پہلے اصلاح تمام برائیوں کی جڑ ہے۔ یہ تقریبا ہمیشہ ہی ہوتا ہے - سوائے اعلی تعدد ٹریڈنگ الگورتھم کی تعمیر کے! کم تعدد کی حکمت عملیوں میں دلچسپی رکھنے والوں کے لئے ، ایک عام نقطہ نظر یہ ہے کہ کسی نظام کو آسان ترین طریقے سے بنایا جائے اور صرف اس وقت ہی اصلاح کی جائے جب بوتل کی گلیاں ظاہر ہونا شروع ہوجائیں۔

پروفائلنگ ٹولز کا استعمال اس بات کا تعین کرنے کے لئے کیا جاتا ہے کہ کس جگہ بوتلیں پیدا ہوتی ہیں۔ ایم ایس ونڈوز یا لینکس ماحول میں ، مذکورہ بالا تمام عوامل کے لئے پروفائلز بنائے جاسکتے ہیں۔ ایسا کرنے کے لئے بہت سارے آپریٹنگ سسٹم اور زبان کے اوزار دستیاب ہیں ، نیز تھرڈ پارٹی یوٹیلیٹیز۔ زبان کا انتخاب اب کارکردگی کے تناظر میں زیر بحث آئے گا۔

سی ++ ، جاوا ، پطرون ، آر اور میٹ لیب میں بنیادی ڈیٹا ڈھانچے اور الگورتھم کے کام کے لئے اعلی کارکردگی کی لائبریریاں (یا تو ان کے معیار کے حصے کے طور پر یا بیرونی طور پر) شامل ہیں۔ سی ++ معیاری ٹیمپلیٹ لائبریری کے ساتھ جہاز ہے ، جبکہ پطرون میں نمپی / سائیپی شامل ہے۔ ان لائبریریوں میں عام ریاضی کے کام پائے جاتے ہیں اور نئی عمل درآمد لکھنا شاذ و نادر ہی فائدہ مند ہوتا ہے۔

ایک استثناء یہ ہے کہ اگر انتہائی اپنی مرضی کے مطابق ہارڈ ویئر فن تعمیر کی ضرورت ہو اور ایک الگورتھم ملکیتی توسیع (جیسے کسٹم کیچ) کا وسیع پیمانے پر استعمال کررہا ہو۔ تاہم ، اکثر پہیے کی دوبارہ ایجاد وقت ضائع کرتی ہے جو تجارتی بنیادی ڈھانچے کے دوسرے حصوں کی ترقی اور اصلاح کے لئے بہتر طور پر خرچ کی جاسکتی ہے۔ ترقی کا وقت انتہائی قیمتی ہے خاص طور پر واحد ڈویلپرز کے تناظر میں۔

لیٹینسی اکثر عملدرآمد کے نظام کا مسئلہ ہوتا ہے کیونکہ تحقیق کے اوزار عام طور پر ایک ہی مشین پر واقع ہوتے ہیں۔ سابقہ کے لئے ، عملدرآمد کے راستے کے ساتھ ساتھ متعدد مقامات پر لیٹینسی ہوسکتی ہے۔ ڈیٹا بیس سے مشورہ کرنا ضروری ہے (ڈسک / نیٹ ورک لیٹینسی) ، سگنل تیار کرنا ضروری ہے (آپریٹنگ سسٹم ، کرنل میسجنگ لیٹینسی) ، تجارتی سگنل بھیجے گئے (این آئی سی لیٹینسی) اور آرڈر پر کارروائی (ایکسچینج سسٹم کی داخلی لیٹینسی) ۔

اعلی تعدد کے آپریشن کے ل it یہ ضروری ہے کہ کورل کی اصلاح کے ساتھ ساتھ نیٹ ورک ٹرانسمیشن کی اصلاح سے بھی واقف ہوجائیں۔ یہ ایک گہرا علاقہ ہے اور مضمون کے دائرہ کار سے نمایاں طور پر باہر ہے لیکن اگر UHFT الگورتھم مطلوب ہے تو پھر ضرورت کی گہرائی سے آگاہ ہوں!

کیچنگ ایک مقداری تجارتی ڈویلپر کے ٹول کٹ میں بہت مفید ہے۔ کیچنگ سے مراد کثرت سے رسائی حاصل کرنے والے ڈیٹا کو اس طرح سے اسٹور کرنے کا تصور ہے جو ڈیٹا کی ممکنہ سست روی کی قیمت پر اعلی کارکردگی تک رسائی کی اجازت دیتا ہے۔ ویب ڈویلپمنٹ میں ایک عام استعمال کا معاملہ اس وقت ہوتا ہے جب کسی ڈسک سے تعاون یافتہ رشتہ دار ڈیٹا بیس سے ڈیٹا لیا جاتا ہے اور اسے میموری میں ڈال دیا جاتا ہے۔ اعداد و شمار کے لئے کسی بھی بعد کی درخواستوں کو ڈیٹا بیس کو "ہٹ" کرنے کی ضرورت نہیں ہوتی ہے اور اس طرح کارکردگی میں اضافہ اہم ہوسکتا ہے۔

تجارتی حالات کے لئے کیچنگ انتہائی فائدہ مند ثابت ہوسکتی ہے۔ مثال کے طور پر ، حکمت عملی کے پورٹ فولیو کی موجودہ حالت کو کیش میں اس وقت تک محفوظ کیا جاسکتا ہے جب تک کہ اسے دوبارہ متوازن نہ کیا جائے ، تاکہ تجارتی الگورتھم کے ہر لوپ پر فہرست کو دوبارہ پیدا کرنے کی ضرورت نہ ہو۔ اس طرح کی تخلیق کا امکان اعلی سی پی یو یا ڈسک I / O آپریشن ہے۔

تاہم ، کیچنگ اپنے مسائل کے بغیر نہیں ہے۔ کیچ اسٹوریج کی غیر مستحکم نوعیت کی وجہ سے ، کیچ ڈیٹا کی ایک ہی بار میں بحالی انفراسٹرکچر پر نمایاں مطالبہ کرسکتی ہے۔ ایک اور مسئلہ ڈاگ اسپیلنگ ہے ، جہاں ایک نئی کیش کاپی کی متعدد نسلیں انتہائی زیادہ بوجھ کے تحت کی جاتی ہیں ، جس سے آبشار کی ناکامی ہوتی ہے۔

متحرک میموری کی الاٹمنٹ سافٹ ویئر کے عمل میں ایک مہنگا آپریشن ہے۔ اس طرح اعلی کارکردگی کی تجارتی ایپلی کیشنز کے لئے یہ ضروری ہے کہ وہ پروگرام کے بہاؤ کے دوران میموری کی الاٹمنٹ اور ڈیللوکیشن کے بارے میں اچھی طرح سے آگاہ ہوں۔ جاوا ، سی # اور پائتھون جیسے جدید ترین زبان کے معیارات خود کار طریقے سے ردی کی ٹوکری کا مجموعہ انجام دیتے ہیں ، جو اشیاء کے دائرہ کار سے باہر جانے پر متحرک طور پر مختص میموری کی ڈیللوکیشن کا حوالہ دیتے ہیں۔

گاربیج کلیکشن ترقی کے دوران انتہائی مفید ہے کیونکہ یہ غلطیوں کو کم کرتا ہے اور پڑھنے میں مدد کرتا ہے۔ تاہم ، یہ بعض اعلی تعدد کی تجارتی حکمت عملیوں کے لئے اکثر غیر زیادہ سے زیادہ ہوتا ہے۔ ان معاملات کے لئے اکثر کسٹم گاربیج کلیکشن مطلوب ہوتا ہے۔ جاوا میں ، مثال کے طور پر ، گاربیج کلیکٹر اور ڈھیر کی تشکیل کو ٹوننگ کرکے ، ایچ ایف ٹی حکمت عملیوں کے لئے اعلی کارکردگی حاصل کرنا ممکن ہے۔

سی ++ میں مقامی گندگی جمع کرنے والا نہیں ہوتا ہے اور اس لئے کسی شے کے نفاذ کے حصے کے طور پر تمام میموری الاٹمنٹ / ڈی الاٹمنٹ کو سنبھالنا ضروری ہے۔ اگرچہ ممکنہ طور پر غلطی کا شکار (ممکنہ طور پر پھنسے ہوئے پوائنٹرز کا باعث بنتا ہے) یہ بہت مفید ہے کہ کچھ ایپلی کیشنز کے ل objects اشیاء کے ڈھیر پر کس طرح ظاہر ہوتے ہیں اس پر ٹھیک ٹھیک کنٹرول ہو۔ زبان کا انتخاب کرتے وقت اس بات کو یقینی بنائیں کہ گندگی جمع کرنے والا کس طرح کام کرتا ہے اور کیا اسے کسی خاص استعمال کے معاملے کے لئے بہتر بنانے کے لئے تبدیل کیا جاسکتا ہے۔

الگورتھمک ٹریڈنگ سسٹم میں بہت سے آپریشن متوازی کرنے کے قابل ہیں۔ یہ ایک ہی وقت میں متعدد پروگراماتی آپریشنز انجام دینے کے تصور سے مراد ہے ، یعنی متوازی میں۔ نام نہاد شرمناک طور پر متوازی الگورتھم میں ایسے اقدامات شامل ہیں جن کا حساب دوسرے اقدامات سے مکمل طور پر آزادانہ طور پر کیا جاسکتا ہے۔ کچھ شماریاتی آپریشنز ، جیسے مونٹی کارلو تخروپن ، شرمناک طور پر متوازی الگورتھم کی ایک اچھی مثال ہیں کیونکہ ہر بے ترتیب ڈرا اور اس کے بعد کے راستے کی کارروائی کو دوسرے راستوں کے علم کے بغیر حساب کیا جاسکتا ہے۔

دوسرے الگورتھم صرف جزوی طور پر متوازی ہیں۔ سیال ڈائنامکس تخروپن اس طرح کی ایک مثال ہیں ، جہاں حساب کتاب کے ڈومین کو تقسیم کیا جاسکتا ہے ، لیکن آخر کار ان ڈومینز کو ایک دوسرے کے ساتھ بات چیت کرنا ہوگی اور اس طرح آپریشن جزوی طور پر ترتیب سے ہوتے ہیں۔ متوازی الگورتھم امڈال کے قانون کے تابع ہیں ، جو ایک متوازی الگورتھم کی کارکردگی میں اضافے کی نظریاتی اوپری حد فراہم کرتا ہے جب NN علیحدہ عملوں (جیسے سی پی یو کور یا تھریڈ پر) کے تابع ہوتا ہے۔

موازنہ اصلاح کے ایک ذریعہ کے طور پر تیزی سے اہم ہو گیا ہے کیونکہ پروسیسر کی گھڑی کی رفتار میں رکاوٹ واقع ہوئی ہے ، کیونکہ نئے پروسیسرز میں بہت سارے کور ہوتے ہیں جن کے ساتھ متوازی حساب کتاب انجام دیا جاسکتا ہے۔ صارفین کے گرافکس ہارڈ ویئر (بنیادی طور پر ویڈیو گیمز کے لئے) کے عروج نے گرافک پروسیسنگ یونٹس (جی پی یو) کی ترقی کا باعث بنی ہے ، جس میں سینکڑوں کور انتہائی متوازی آپریشنز کے لئے ہوتے ہیں۔ ایسے جی پی یو اب بہت سستی ہیں۔ اعلی سطح کے فریم ورک ، جیسے اینویڈیا کے سی یو ڈی اے نے تعلیمی اور مالیاتی شعبے میں وسیع پیمانے پر اپنانے کا باعث بنے ہیں۔

اس طرح کے جی پی یو ہارڈ ویئر عام طور پر صرف مقداری مالیات کے تحقیقی پہلو کے لئے موزوں ہوتے ہیں ، جبکہ دیگر زیادہ خصوصی ہارڈ ویئر (بشمول فیلڈ پروگرام ایبل گیٹ آرریز - ایف پی جی اے) کا استعمال (یو) ایچ ایف ٹی کے لئے کیا جاتا ہے۔ آج کل ، زیادہ تر جدید زبانوں میں ہم آہنگی / ملٹی تھریڈنگ کی ایک ڈگری کی حمایت کی جاتی ہے۔ اس طرح بیک ٹیسٹر کو بہتر بنانا آسان ہے ، کیونکہ تمام حساب کتاب عام طور پر دوسروں سے آزاد ہیں۔

سافٹ ویئر انجینئرنگ اور آپریشنز میں اسکیلنگ سے مراد نظام کی مستقل طور پر بڑھتی ہوئی بوجھ کو بڑی درخواستوں ، اعلی پروسیسر استعمال اور زیادہ میموری الاٹمنٹ کی شکل میں سنبھالنے کی صلاحیت ہے۔ الگورتھمک ٹریڈنگ میں اگر کوئی حکمت عملی بڑی مقدار میں سرمایہ کو قبول کرسکتی ہے اور پھر بھی مستقل واپسی پیدا کرسکتی ہے۔ اگر یہ بڑی تجارتی حجم اور بڑھتی ہوئی تاخیر کو برداشت کرسکتی ہے تو تجارتی ٹیکنالوجی اسکیل ہوتی ہے۔

اگرچہ سسٹم کو پیمانے پر ڈیزائن کیا جانا چاہئے ، لیکن اکثر اس بات کی پیش گوئی کرنا مشکل ہوتا ہے کہ کس جگہ بوتل کی گلی واقع ہوگی۔ سخت لاگنگ ، ٹیسٹنگ ، پروفائلنگ اور مانیٹرنگ سے کسی سسٹم کو پیمانے کی اجازت دینے میں بہت مدد ملے گی۔ زبانوں کو خود کو اکثر غیر قابل پیمانہ کے طور پر بیان کیا جاتا ہے۔ یہ عام طور پر حقیقت کے بجائے غلط معلومات کا نتیجہ ہوتا ہے۔ یہ کل ٹیکنالوجی اسٹیک ہے جس کی توسیع کے لئے تصدیق کی جانی چاہئے ، زبان نہیں۔ واضح طور پر کچھ زبانوں میں خاص استعمال کے معاملات میں دوسروں سے زیادہ کارکردگی ہوتی ہے ، لیکن ایک زبان ہر لحاظ سے کسی دوسرے سے بہتر نہیں ہوتی ہے۔

پیمانے کا انتظام کرنے کا ایک طریقہ یہ ہے کہ خدشات کو الگ کیا جائے ، جیسا کہ اوپر بیان کیا گیا ہے۔ نظام میں spikes کو سنبھالنے کی صلاحیت کو مزید متعارف کرانے کے لئے (یعنی اچانک اتار چڑھاؤ جو تجارت کا ایک سلسلہ شروع کرتا ہے) ، message queueing architecture بنانا مفید ہے۔ اس کا مطلب صرف یہ ہے کہ اجزاء کے مابین پیغام کی قطار کا نظام رکھنا تاکہ اگر کوئی خاص جزو بہت سی درخواستوں پر کارروائی کرنے سے قاصر ہو تو آرڈر stacked up ہوں۔

درخواستوں کو ضائع ہونے کے بجائے ، انہیں صرف اس وقت تک اسٹیک میں رکھا جاتا ہے جب تک کہ پیغام سنبھالا نہ جائے۔ یہ خاص طور پر عملدرآمد کے انجن میں تجارت بھیجنے کے لئے کارآمد ہے۔ اگر انجن بھاری تاخیر کا شکار ہے تو وہ تجارت کا بیک اپ لے گا۔ تجارتی سگنل جنریٹر اور عمل درآمد API کے مابین قطار اس مسئلے کو ممکنہ تجارت کے خاتمے کی قیمت پر کم کرے گی۔ ایک قابل احترام اوپن سورس میسج قطار بروکر رابٹ ایم کیو ہے۔

ہارڈ ویئر اور آپریٹنگ سسٹم

آپ کی حکمت عملی کو چلانے والے ہارڈ ویئر کا آپ کے الگورتھم کی منافع پر نمایاں اثر پڑ سکتا ہے۔ یہ مسئلہ صرف ہائی فریکوئنسی ٹریڈرز تک ہی محدود نہیں ہے۔ ہارڈ ویئر اور آپریٹنگ سسٹم میں خراب انتخاب سے مشین کریش یا غیر مناسب لمحے میں دوبارہ اسٹارٹ ہوسکتا ہے۔ اس طرح یہ غور کرنا ضروری ہے کہ آپ کی ایپلی کیشن کہاں ہوگی۔ انتخاب عام طور پر ذاتی ڈیسک ٹاپ مشین ، ریموٹ سرور ، کلاؤڈ فراہم کنندہ یا ایکسچینج کے ساتھ واقع سرور کے درمیان ہوتا ہے۔

ڈیسک ٹاپ مشینیں انسٹال اور انتظام کرنا آسان ہیں ، خاص طور پر نئے صارف دوست آپریٹنگ سسٹم جیسے ونڈوز 7/8 ، میک OSX اور اوبنٹو کے ساتھ۔ ڈیسک ٹاپ سسٹم میں کچھ اہم نقصانات ہیں ، تاہم ، سب سے اہم بات یہ ہے کہ ڈیسک ٹاپ مشینوں کے لئے ڈیزائن کردہ آپریٹنگ سسٹم کے ورژن کو دوبارہ شروع / پیچ کرنے کی ضرورت ہوتی ہے (اور اکثر بدترین اوقات میں!) ۔ وہ گرافیکل یوزر انٹرفیس (GUI) کی ضرورت کی وجہ سے زیادہ کمپیوٹیشنل وسائل بھی استعمال کرتے ہیں۔

ہوم (یا مقامی آفس) ماحول میں ہارڈ ویئر کا استعمال انٹرنیٹ کنیکٹوٹی اور بجلی کے اپ ٹائم کے مسائل کا باعث بن سکتا ہے۔ ڈیسک ٹاپ سسٹم کا بنیادی فائدہ یہ ہے کہ قابل ذکر کمپیوٹنگ ہارس پاور کو ریموٹ سرشار سرور (یا کلاؤڈ بیسڈ سسٹم) کی لاگت کے ایک حصے کے لئے خریدا جاسکتا ہے۔

ایک سرشار سرور یا کلاؤڈ پر مبنی مشین ، اگرچہ اکثر ڈیسک ٹاپ آپشن سے زیادہ مہنگا ہوتا ہے ، زیادہ اہم ریڈونسٹی انفراسٹرکچر کی اجازت دیتا ہے ، جیسے خودکار ڈیٹا بیک اپ ، زیادہ براہ راست اپ ٹائم اور ریموٹ مانیٹرنگ کو یقینی بنانے کی صلاحیت۔ ان کا انتظام کرنا مشکل ہے کیونکہ انہیں آپریٹنگ سسٹم کی ریموٹ لاگ ان صلاحیتوں کو استعمال کرنے کی صلاحیت کی ضرورت ہوتی ہے۔

ونڈوز میں یہ عام طور پر جی یو آئی ریموٹ ڈیسک ٹاپ پروٹوکول (آر ڈی پی) کے ذریعے ہوتا ہے۔ یونیکس پر مبنی سسٹم میں کمانڈ لائن سیکور شیل (ایس ایس ایچ) کا استعمال کیا جاتا ہے۔ یونیکس پر مبنی سرور انفراسٹرکچر تقریبا always ہمیشہ کمانڈ لائن پر مبنی ہوتا ہے جو فوری طور پر جی یو آئی پر مبنی پروگرامنگ ٹولز (جیسے میٹ لیب یا ایکسل) کو ناقابل استعمال بنا دیتا ہے۔

ایک مشترکہ سرور ، جیسا کہ یہ جملہ سرمایہ بازاروں میں استعمال ہوتا ہے ، محض ایک سرشار سرور ہے جو تجارتی الگورتھم کی تاخیر کو کم کرنے کے لئے ایک تبادلے کے اندر رہتا ہے۔ یہ کچھ اعلی تعدد تجارتی حکمت عملیوں کے لئے بالکل ضروری ہے ، جو الفا پیدا کرنے کے لئے کم تاخیر پر انحصار کرتے ہیں۔

ہارڈ ویئر کے انتخاب اور پروگرامنگ زبان کے انتخاب کا آخری پہلو پلیٹ فارم کی آزادی ہے۔ کیا کوڈ کو متعدد مختلف آپریٹنگ سسٹم میں چلانے کی ضرورت ہے؟ کیا کوڈ کو کسی خاص قسم کے پروسیسر فن تعمیر پر چلانے کے لئے ڈیزائن کیا گیا ہے ، جیسے انٹیل ایکس 86 / ایکس 64 یا کیا یہ ممکن ہوگا کہ آر ایم کے تیار کردہ جیسے آر آئی ایس سی پروسیسرز پر عملدرآمد کیا جائے؟ یہ مسائل اس حکمت عملی کی تعدد اور قسم پر بہت زیادہ منحصر ہوں گے جو لاگو کی جارہی ہے۔

لچک اور آزمائش

الگورتھمک ٹریڈنگ پر بہت سارے پیسے کھونے کا ایک بہترین طریقہ یہ ہے کہ بغیر کسی لچک کے نظام کو تشکیل دیا جائے۔ اس سے مراد سسٹم کی استحکام ہے جب نایاب واقعات کا سامنا کرنا پڑتا ہے ، جیسے بروکرج دیوالیہ پن ، اچانک اضافی اتار چڑھاؤ ، کلاؤڈ سرور فراہم کنندہ کے لئے خطے بھر میں ٹائم آؤٹ ٹائم یا پورے تجارتی ڈیٹا بیس کو حادثاتی طور پر حذف کرنا۔ خراب ڈیزائن شدہ فن تعمیر کے ساتھ سیکنڈ کے اندر اندر سالوں کے منافع کو ختم کیا جاسکتا ہے۔ آپ کے سسٹم کے بنیادی اجزاء کے طور پر ڈیبگنگ ، جانچ ، لاگنگ ، بیک اپ ، اعلی دستیابی اور نگرانی جیسے امور پر غور کرنا بالکل ضروری ہے۔

یہ امکان ہے کہ کسی بھی معقول حد تک پیچیدہ کسٹم مقداری تجارتی ایپلی کیشن میں کم از کم 50٪ ترقیاتی وقت ڈیبگنگ ، ٹیسٹنگ اور دیکھ بھال پر خرچ ہوگا۔

تقریبا تمام پروگرامنگ زبانوں میں یا تو منسلک ڈیبگر کے ساتھ جہاز یا معزز تیسرے فریق کے متبادل ہوتے ہیں۔ جوہر میں ، ڈیبگر کوڈ کے راستے میں اپنی مرضی کے مطابق وقفے کے مقامات کو داخل کرنے کے ساتھ کسی پروگرام کو انجام دینے کی اجازت دیتا ہے ، جو نظام کی حالت کی تحقیقات کے لئے عارضی طور پر عملدرآمد کو روکتا ہے۔ ڈیبگنگ کا بنیادی فائدہ یہ ہے کہ کسی مشہور کریش پوائنٹ سے پہلے کوڈ کے رویے کی تحقیقات کرنا ممکن ہے۔

ڈیبگنگ پروگرامنگ کی غلطیوں کا تجزیہ کرنے کے لئے ٹول باکس میں ایک ضروری جزو ہے۔ تاہم ، وہ مرتب شدہ زبانوں جیسے سی ++ یا جاوا میں زیادہ وسیع پیمانے پر استعمال ہوتے ہیں ، کیونکہ پیتھون جیسی تشریح شدہ زبانوں میں کم LOC اور کم لفظی بیانات کی وجہ سے ڈیبگ کرنا اکثر آسان ہوتا ہے۔ اس رجحان کے باوجود ، پیتھون پی ڈی بی کے ساتھ جہاز کرتا ہے ، جو ایک نفیس ڈیبگنگ ٹول ہے۔ مائیکروسافٹ ویژول سی ++ آئی ڈی ای میں گائیڈ UI ڈیبگنگ کی وسیع افادیت موجود ہے ، جبکہ کمانڈ لائن لینکس سی ++ پروگرامر کے لئے ، جی ڈی بی ڈیبگر موجود ہے۔

سافٹ ویئر ڈویلپمنٹ میں ٹیسٹنگ سے مراد کوڈ بیس کے اندر مخصوص افعال ، طریقوں اور اشیاء پر معلوم پیرامیٹرز اور نتائج کو لاگو کرنے کا عمل ہے ، تاکہ سلوک کی نقالی کی جاسکے اور متعدد کوڈ راستوں کا اندازہ لگایا جاسکے ، جس سے یہ یقینی بنانے میں مدد ملے کہ کوئی نظام جس طرح ہونا چاہئے اس طرح برتاؤ کرے۔ ایک حالیہ نمونہ ٹیسٹ ڈرائیوڈ ڈویلپمنٹ (ٹی ڈی ڈی) کے نام سے جانا جاتا ہے ، جہاں ٹیسٹ کوڈ کو کسی مخصوص انٹرفیس کے خلاف تیار کیا جاتا ہے جس میں کوئی عمل درآمد نہیں ہوتا ہے۔ اصل کوڈ بیس کی تکمیل سے پہلے تمام ٹیسٹ ناکام ہوجائیں گے۔ چونکہ کوڈ خالی جگہوں کو بھرنے کے لئے لکھا جاتا ہے ، آخر کار ٹیسٹ سب گزر جائیں گے ، جس وقت ترقی کو روکنا چاہئے۔

ٹی ڈی ڈی کو کامیابی کے ساتھ انجام دینے کے لئے وسیع پیمانے پر پیشگی تفصیلات کے ڈیزائن کے ساتھ ساتھ ایک صحت مند ڈگری کی نظم و ضبط کی ضرورت ہوتی ہے۔ سی ++ میں ، بوسٹ یونٹ ٹیسٹنگ فریم ورک مہیا کرتا ہے۔ جاوا میں ، جونیٹ لائبریری اسی مقصد کو پورا کرنے کے لئے موجود ہے۔ پائتھون میں معیاری لائبریری کے حصے کے طور پر یونٹ ماڈیول بھی موجود ہے۔ بہت سی دوسری زبانوں میں یونٹ ٹیسٹنگ فریم ورک موجود ہیں اور اکثر متعدد اختیارات ہوتے ہیں۔

پروڈکشن ماحول میں ، نفیس لاگنگ بالکل ضروری ہے۔ لاگنگ سے مراد ایک فلیٹ فائل یا ڈیٹا بیس میں سسٹم کے عملدرآمد کے رویے کے بارے میں مختلف درجے کی شدت کے ساتھ پیغامات آؤٹ پٹ کرنے کا عمل ہے۔ لاگنگ غیر متوقع پروگرام رن ٹائم رویے کے شکار میں حملے کی پہلی لائن ہے۔ بدقسمتی سے لاگنگ سسٹم کی خامیوں کا پتہ صرف اس کے بعد ہی لگ جاتا ہے۔ ذیل میں زیر بحث بیک اپ کی طرح ، لاگنگ سسٹم کو بھی نظام ڈیزائن کرنے سے پہلے مناسب غور کیا جانا چاہئے۔

مائیکروسافٹ ونڈوز اور لینکس دونوں وسیع پیمانے پر سسٹم لاگنگ کی صلاحیت کے ساتھ آتے ہیں اور پروگرامنگ کی زبانوں کو معیاری لاگنگ لائبریریوں کے ساتھ بھیجنے کا رجحان ہوتا ہے جو زیادہ تر استعمال کے معاملات کو ڈھکتے ہیں۔ بعد میں اس کا تجزیہ کرنے کے لئے لاگنگ کی معلومات کو مرکزی بنانا اکثر سمجھدار ہوتا ہے ، کیونکہ اس سے اکثر کارکردگی کو بہتر بنانے یا غلطی کو کم کرنے کے بارے میں خیالات پیدا ہوسکتے ہیں ، جس کا تقریبا almost یقینی طور پر آپ کی تجارتی واپسی پر مثبت اثر پڑے گا۔

جب کہ کسی سسٹم کی لاگنگ ماضی میں پیش آنے والی چیزوں کے بارے میں معلومات فراہم کرے گی ، لیکن کسی ایپلی کیشن کی نگرانی اس وقت کیا ہو رہا ہے اس کے بارے میں بصیرت فراہم کرے گی۔ نگرانی کے لئے سسٹم کے تمام پہلوؤں پر غور کیا جانا چاہئے۔ سسٹم کی سطح پر میٹرکس جیسے ڈسک استعمال ، دستیاب میموری ، نیٹ ورک بینڈوتھ اور سی پی یو استعمال بنیادی بوجھ کی معلومات فراہم کرتے ہیں۔

غیر معمولی قیمتوں / حجم ، اچانک تیزی سے کھپت اور مختلف شعبوں / منڈیوں کے لئے اکاؤنٹ کی نمائش جیسے تجارتی میٹرکس کی بھی مسلسل نگرانی کی جانی چاہئے۔ مزید برآں ، ایک حد کا نظام شروع کیا جانا چاہئے جو میٹرک کی شدت کے لحاظ سے نوٹیفکیشن کے طریقہ کار (ای میل ، ایس ایم ایس ، خودکار فون کال) کو بڑھا کر ، بعض میٹرکس کی خلاف ورزی پر نوٹیفکیشن فراہم کرتا ہے۔

سسٹم مانیٹرنگ اکثر سسٹم ایڈمنسٹریٹر یا آپریشنز مینیجر کا ڈومین ہوتا ہے۔ تاہم ، بطور واحد تجارتی ڈویلپر ، یہ میٹرکس بڑے ڈیزائن کے حصے کے طور پر قائم کیے جانے چاہئیں۔ مانیٹرنگ کے لئے بہت سارے حل موجود ہیں: ملکیتی ، میزبانی شدہ اور اوپن سورس ، جو کسی خاص استعمال کے معاملے کے لئے میٹرکس کی وسیع پیمانے پر تخصیص کی اجازت دیتے ہیں۔

بیک اپ اور اعلی دستیابی ٹریڈنگ سسٹم کی بنیادی تشویشیں ہونی چاہئیں۔ مندرجہ ذیل دو سوالات پر غور کریں: 1) اگر مارکیٹ کے اعداد و شمار اور تجارتی تاریخ کا ایک پورا پروڈکشن ڈیٹا بیس حذف کردیا گیا (بغیر بیک اپ کے) تو ریسرچ اور ایگزیکشن الگورتھم پر کیا اثر پڑے گا؟ 2) اگر تجارتی نظام طویل عرصے تک بند ہوجاتا ہے (کھلی پوزیشنوں کے ساتھ) تو اکاؤنٹ ایکویٹی اور جاری منافع کو کس طرح متاثر کیا جائے گا؟ ان دونوں سوالات کے جوابات اکثر سنجیدہ ہوتے ہیں!

ڈیٹا کا بیک اپ لینے اور اس طرح کے ڈیٹا کی بحالی کی جانچ کے لئے بھی ایک نظام قائم کرنا ضروری ہے۔ بہت سے افراد بحالی کی حکمت عملی کی جانچ نہیں کرتے ہیں۔ اگر کسی حادثے سے بحالی کا محفوظ ماحول میں تجربہ نہیں کیا گیا ہے تو ، اس بات کی کیا ضمانت ہے کہ بحالی بدترین ممکنہ لمحے میں دستیاب ہوگی؟

اسی طرح ، اعلی دستیابی کو شروع سے ہی بھونکنے کی ضرورت ہے۔ اضافی انفراسٹرکچر (یہاں تک کہ اضافی اخراجات پر بھی) پر ہمیشہ غور کیا جانا چاہئے ، کیونکہ اس طرح کے سسٹم کی مسلسل دیکھ بھال کی لاگت سے کہیں زیادہ ٹائم ٹائم کی لاگت زیادہ ہوسکتی ہے۔ میں اس موضوع میں زیادہ گہرائی میں نہیں جاؤں گا کیونکہ یہ ایک بڑا علاقہ ہے ، لیکن اس بات کو یقینی بنائیں کہ یہ آپ کے تجارتی نظام کو دیئے جانے والے پہلے غور میں سے ایک ہے۔

زبان کا انتخاب

اب متعدد عوامل پر کافی تفصیل فراہم کی گئی ہے جو کسٹم ہائی پرفارمنس الگورتھمک ٹریڈنگ سسٹم تیار کرتے وقت پیدا ہوتے ہیں۔ اگلا مرحلہ یہ بحث کرنا ہے کہ پروگرامنگ زبانوں کو عام طور پر کس طرح درجہ بندی کیا جاتا ہے۔

ٹائپ سسٹم

ٹریڈنگ اسٹیک کے لئے زبان کا انتخاب کرتے وقت ٹائپ سسٹم پر غور کرنا ضروری ہے۔ وہ زبانیں جو الگورتھمک ٹریڈنگ کے لئے دلچسپی رکھتی ہیں وہ یا تو جامد یا متحرک طور پر ٹائپ کی جاتی ہیں۔ جامد طور پر ٹائپ شدہ زبان مرتب کرنے کے عمل کے دوران اقسام (جیسے عددی ، فلوٹ ، کسٹم کلاس وغیرہ) کی جانچ پڑتال کرتی ہے۔ ایسی زبانوں میں سی ++ اور جاوا شامل ہیں۔ متحرک طور پر ٹائپ شدہ زبان رن ٹائم پر اس کی زیادہ تر قسم کی جانچ پڑتال کرتی ہے۔ ایسی زبانوں میں پائتھون ، پرل اور جاوا اسکرپٹ شامل ہیں۔

الگورتھمک ٹریڈنگ انجن جیسے انتہائی عددی نظام کے ل type ، مرتب کرنے کے وقت ٹائپ چیک کرنا انتہائی فائدہ مند ہوسکتا ہے ، کیونکہ یہ بہت سارے کیڑے کو ختم کرسکتا ہے جو دوسری صورت میں عددی غلطیوں کا باعث بنتے ہیں۔ تاہم ، ٹائپ چیک ہر چیز کو نہیں پکڑتا ہے ، اور یہ وہ جگہ ہے جہاں غیر متوقع کارروائیوں کو سنبھالنے کی ضرورت کی وجہ سے استثناء سے نمٹنے کا کام آتا ہے۔ متحرک زبانیں (یعنی متحرک طور پر ٹائپ شدہ) اکثر رن ٹائم غلطیوں کا باعث بن سکتی ہیں جو دوسری صورت میں مرتب کرنے کے وقت ٹائپ چیک کے ساتھ پکڑی جائیں گی۔ اس وجہ سے ، TDD (اوپر دیکھیں) اور یونٹ ٹیسٹنگ کا تصور پیدا ہوا جو ، جب صحیح طریقے سے انجام دیا جاتا ہے تو ، اکثر صرف مرتب کرنے کے وقت چیک کرنے سے زیادہ حفاظت فراہم کرتا ہے۔

جامد طور پر ٹائپ شدہ زبانوں کا ایک اور فائدہ یہ ہے کہ کمپائلر بہت ساری اصلاحات کرنے کے قابل ہے جو دوسری صورت میں متحرک طور پر ٹائپ شدہ زبان کے لئے دستیاب نہیں ہیں ، صرف اس وجہ سے کہ ٹائپ (اور اس طرح میموری کی ضروریات) مرتب کرنے کے وقت معلوم ہیں۔ در حقیقت ، بہت سی متحرک طور پر ٹائپ شدہ زبانوں کی ناکامی کا ایک حصہ اس حقیقت سے پیدا ہوتا ہے کہ کچھ اشیاء کو رن ٹائم پر ٹائپ معائنہ کرنا پڑتا ہے اور اس سے کارکردگی کی ہٹ ہوتی ہے۔ متحرک زبانوں کی لائبریریاں ، جیسے NumPy / SciPy ، صفوں کے اندر ایک قسم کو نافذ کرنے کی وجہ سے اس مسئلے کو کم کرتی ہیں۔

اوپن سورس یا پرائیویٹ؟

الگورتھمک ٹریڈنگ ڈویلپر کے لئے دستیاب سب سے بڑے انتخاب میں سے ایک یہ ہے کہ آیا ملکیتی (تجارتی) یا اوپن سورس ٹیکنالوجیز کا استعمال کریں۔ دونوں طریقوں کے فوائد اور نقصانات ہیں۔ اس بات پر غور کرنا ضروری ہے کہ کسی زبان کی کتنی اچھی طرح سے حمایت کی جاتی ہے ، کسی زبان کے آس پاس کی کمیونٹی کی سرگرمی ، تنصیب اور دیکھ بھال میں آسانی ، دستاویزات کا معیار اور کسی بھی لائسنسنگ / دیکھ بھال کے اخراجات۔

مائیکروسافٹ.NET اسٹیک (بشمول بصری سی ++ ، بصری سی #) اور ریاضی ورکس میٹ لیب اپنی مرضی کے مطابق الگورتھمک ٹریڈنگ سافٹ ویئر تیار کرنے کے لئے دو بڑے ملکیتی انتخاب ہیں۔ دونوں ٹولز میں مالیاتی جگہ میں اہم بٹل ٹیسٹنگ ہوئی ہے ، سابقہ سرمایہ کاری بینکنگ ٹریڈنگ انفراسٹرکچر کے لئے غالب سافٹ ویئر اسٹیک تشکیل دے رہا ہے اور مؤخر الذکر سرمایہ کاری فنڈز کے اندر مقداری تجارتی تحقیق کے لئے بڑے پیمانے پر استعمال ہوتا ہے۔

مائیکروسافٹ اور میتھ ورکس دونوں اپنی مصنوعات کے ل extensive وسیع پیمانے پر اعلی معیار کی دستاویزات فراہم کرتے ہیں۔ مزید برآں ، ہر ٹول کے آس پاس کی کمیونٹیز بہت بڑی ہیں جن میں دونوں کے لئے فعال ویب فورم موجود ہیں۔.NET سافٹ ویئر متعدد زبانوں جیسے سی ++ ، سی # اور وی بی کے ساتھ ہم آہنگ انضمام کی اجازت دیتا ہے ، نیز دیگر مائیکرو سافٹ مصنوعات جیسے SQL سرور ڈیٹا بیس سے LINQ کے ذریعے آسان لنک۔ میٹ لیب میں تقریبا کسی بھی مقداری تحقیقی ڈومین کے لئے بہت سارے پلگ ان / لائبریری (کچھ مفت ، کچھ تجارتی) بھی ہیں۔

اس کے نقصانات بھی ہیں۔ سافٹ ویئر کے کسی بھی ٹکڑے کے ساتھ تنہا تاجر کے لئے لاگت غیر اہم نہیں ہے (حالانکہ مائیکروسافٹ مفت میں بصری اسٹوڈیو کا انٹری لیول ورژن مہیا کرتا ہے۔ مائیکروسافٹ ٹولز ایک دوسرے کے ساتھ اچھی طرح سے کھیلتے ہیں ، لیکن بیرونی کوڈ کے ساتھ کم مربوط ہوتے ہیں۔ بصری اسٹوڈیو کو مائیکروسافٹ ونڈوز پر بھی چلایا جانا چاہئے ، جو مبینہ طور پر ایک مساوی لینکس سرور سے کہیں کم کارکردگی کا مظاہرہ کرتا ہے جو زیادہ سے زیادہ بہتر ہے۔

میٹ لیب میں کچھ اہم پلگ انز بھی نہیں ہیں جیسے انٹرایکٹو بروکرز API کے ارد گرد ایک اچھا لفافہ ، جو چند بروکرز میں سے ایک ہے جو اعلی کارکردگی کی الگورتھم ٹریڈنگ کے قابل ہے۔ ملکیتی مصنوعات کے ساتھ بنیادی مسئلہ سورس کوڈ کی عدم دستیابی ہے۔ اس کا مطلب یہ ہے کہ اگر واقعی انتہائی کارکردگی کی ضرورت ہے تو ، یہ دونوں ٹولز بہت کم پرکشش ہوں گے۔

اوپن سورس ٹولز کچھ عرصے سے انڈسٹری گریڈ رہے ہیں۔ متبادل اثاثہ کی زیادہ تر جگہ اوپن سورس لینکس ، ایس کیو ایل / پوسٹگری ایس کیو ایل ، پطرون ، آر ، سی ++ اور جاوا کو اعلی کارکردگی والے پروڈکشن رولز میں وسیع پیمانے پر استعمال کرتی ہے۔ تاہم ، وہ اس ڈومین تک محدود نہیں ہیں۔ خاص طور پر پطرون اور آر میں تقریبا کسی بھی قسم کے اعداد و شمار کے تجزیے کے لئے وسیع تعداد میں عددی لائبریریاں موجود ہیں جن کا تصور کیا جاسکتا ہے ، اکثر مرتب شدہ زبانوں کے مقابلے میں عملدرآمد کی رفتار پر ، کچھ انتباہات کے ساتھ۔

تشریح شدہ زبانوں کا استعمال کرنے کا بنیادی فائدہ ترقی کے وقت کی رفتار ہے۔ پائتھون اور آر کو اسی طرح کی فعالیت حاصل کرنے کے لئے بہت کم کوڈ لائنوں (LOC) کی ضرورت ہوتی ہے ، بنیادی طور پر وسیع لائبریریوں کی وجہ سے۔ مزید برآں ، وہ اکثر انٹرایکٹو کنسول پر مبنی ترقی کی اجازت دیتے ہیں ، جس سے تکراراتی ترقی کے عمل کو تیزی سے کم کیا جاتا ہے۔

یہ دیکھتے ہوئے کہ ڈویلپر کے طور پر وقت انتہائی قیمتی ہے ، اور عملدرآمد کی رفتار اکثر کم ہوتی ہے (جب تک کہ ایچ ایف ٹی کی جگہ میں نہیں) ، اوپن سورس ٹکنالوجی اسٹیک پر وسیع پیمانے پر غور کرنے کے قابل ہے۔ پائتھون اور آر کے پاس نمایاں ترقیاتی برادری ہے اور ان کی مقبولیت کی وجہ سے ان کی انتہائی اچھی طرح سے حمایت کی جاتی ہے۔ دستاویزات بہترین ہیں اور کیڑے (کم از کم بنیادی لائبریریوں کے لئے) نایاب ہیں۔

اوپن سورس ٹولز اکثر خصوصی تجارتی معاون معاہدے کی کمی کا شکار ہوتے ہیں اور کم معاف کرنے والے صارف انٹرفیس والے سسٹم پر زیادہ سے زیادہ چلتے ہیں۔ ایک عام لینکس سرور (جیسے اوبنٹو) اکثر مکمل طور پر کمانڈ لائن پر مبنی ہوتا ہے۔ اس کے علاوہ ، پائتھون اور آر کچھ عمل درآمد کے کاموں کے لئے سست ہوسکتے ہیں۔ عمل درآمد کی رفتار کو بہتر بنانے کے لئے سی ++ کے ساتھ انضمام کے لئے میکانزم موجود ہیں ، لیکن اس کے لئے کثیر زبان کی پروگرامنگ میں کچھ تجربہ درکار ہوتا ہے۔

اگرچہ ملکیتی سافٹ ویئر انحصار / ورژننگ کے مسائل سے محفوظ نہیں ہے ، لیکن اس طرح کے ماحول میں لائبریری کے غلط ورژن سے نمٹنے کے لئے بہت کم عام ہے۔ اوپن سورس آپریٹنگ سسٹم جیسے لینکس کا انتظام کرنا مشکل ہوسکتا ہے۔

میں یہاں اپنی ذاتی رائے کا خطرہ مول لوں گا اور یہ کہوں گا کہ میں اپنے تمام تجارتی ٹولز کو اوپن سورس ٹیکنالوجیز کے ساتھ بناتا ہوں۔ خاص طور پر میں استعمال کرتا ہوں: اوبنٹو ، ایس کیو ایل ، پائتھون ، سی ++ اور آر۔ پختگی ، کمیونٹی کا سائز ، اگر مسائل پیدا ہوجاتے ہیں تو گہری کھودنے کی صلاحیت اور کم کل لاگت ملکیت (ٹی سی او) ملکیتی جی یو آئی کی سادگی اور آسان تنصیبات سے کہیں زیادہ ہے۔ یہ کہتے ہوئے ، مائیکروسافٹ بصری اسٹوڈیو (خاص طور پر سی ++ کے لئے) ایک لاجواب انٹیگریٹڈ ڈویلپمنٹ ماحول (IDE) ہے جس کی میں بھی انتہائی سفارش کروں گا۔

بیٹریاں شامل ہیں؟

اس سیکشن کے ہیڈر میں زبان کی باکس سے باہر صلاحیتوں کا حوالہ دیا گیا ہے - اس میں کون سی لائبریریاں موجود ہیں اور وہ کتنی اچھی ہیں؟ یہ وہ جگہ ہے جہاں بالغ زبانوں کو نئے متغیرات سے زیادہ فائدہ ہوتا ہے۔ سی + + ، جاوا اور پائتھون اب نیٹ ورک پروگرامنگ ، ایچ ٹی ٹی پی ، آپریٹنگ سسٹم کے تعامل ، جی یو آئی ، باقاعدہ اظہار (ریجیکس) ، تکرار اور بنیادی الگورتھم کے لئے وسیع لائبریریوں کے مالک ہیں۔

سی ++ اپنی معیاری ٹیمپلیٹ لائبریری (ایس ٹی ایل) کے لئے مشہور ہے جس میں اعلی کارکردگی کے اعداد و شمار کے ڈھانچے اور الگورتھم مفت کی دولت شامل ہے۔ پائیتون تقریبا کسی بھی دوسرے قسم کے سسٹم / پروٹوکول (خاص طور پر ویب) کے ساتھ بات چیت کرنے کے قابل ہونے کے لئے جانا جاتا ہے ، زیادہ تر اپنی معیاری لائبریری کے ذریعے۔ آر میں اعدادوشمار اور اقتصادیات کے بہت سارے اوزار شامل ہیں ، جبکہ میٹ لیب کسی بھی عددی لکیری الجبرا کوڈ کے لئے انتہائی بہتر ہے (جو مثال کے طور پر پورٹ فولیو کی اصلاح اور مشتق قیمتوں میں پایا جاسکتا ہے) ۔

معیاری لائبریریوں کے باہر ، سی ++ بوسٹ لائبریری کا استعمال کرتا ہے ، جو معیاری لائبریری کے لاپتہ حصوں کو پُر کرتا ہے۔ در حقیقت ، بوسٹ کے بہت سے حصے اسے TR1 معیار میں بنا چکے ہیں اور بعد میں C ++ 11 کی تفصیلات میں دستیاب ہیں ، بشمول لیمبڈا اظہار اور ہم وقت سازی کے لئے مقامی معاونت۔

پائیتھون میں اعلی کارکردگی کا حامل نمبر پی / سائی پی / پانڈا ڈیٹا تجزیہ لائبریری کا مجموعہ ہے ، جس نے الگورتھمک ٹریڈنگ ریسرچ کے لئے وسیع پیمانے پر قبولیت حاصل کی ہے۔ مزید برآں ، اہم رشتہ دار ڈیٹا بیس تک رسائی کے ل high اعلی کارکردگی کے پلگ ان موجود ہیں ، جیسے ایس کیو ایل ++ (ایس کیو ایل / سی ++) ، جے ڈی بی سی (جاوا / میٹ لیب) ، ایس کیو ایل ڈی بی (ایس کیو ایل / پائیتھون) اور نفسیات 2 (پوسٹگری ایس کیو ایل / پائیتھون) ۔ پائیتھون آر پی پائی پلگ ان کے ذریعے بھی آر کے ساتھ بات چیت کرسکتا ہے!

ابتدائی تحقیق اور ڈیزائن کے مرحلے میں ٹریڈنگ سسٹم کا ایک اکثر نظرانداز ہونے والا پہلو بروکر API سے رابطے ہے۔ زیادہ تر API مقامی طور پر C ++ اور جاوا کی حمایت کرتے ہیں ، لیکن کچھ C # اور پائتھون کی بھی حمایت کرتے ہیں ، یا تو براہ راست یا C ++ API کے لئے کمیونٹی کے ذریعہ فراہم کردہ لفافہ کوڈ کے ساتھ۔ خاص طور پر ، انٹرایکٹو بروکرز کو IBPy پلگ ان کے ذریعے منسلک کیا جاسکتا ہے۔ اگر اعلی کارکردگی کی ضرورت ہو تو ، بروکرز FIX پروٹوکول کی حمایت کریں گے۔

نتیجہ

جیسا کہ اب واضح ہے ، الگورتھمک ٹریڈنگ سسٹم کے لئے پروگرامنگ زبانوں کا انتخاب آسان نہیں ہے اور اس میں گہری سوچ کی ضرورت ہے۔ اہم غور و فکر کارکردگی ، ترقی کی آسانی ، لچک اور جانچ ، خدشات کو الگ کرنا ، واقفیت ، دیکھ بھال ، سورس کوڈ کی دستیابی ، لائسنسنگ لاگت اور لائبریریوں کی پختگی ہیں۔

علیحدہ فن تعمیر کا فائدہ یہ ہے کہ جب ضروریات میں تبدیلی آتی ہے تو ، یہ زبانوں کو ٹریڈنگ اسٹیک کے مختلف پہلوؤں کے لئے پلگ ان کرنے کی اجازت دیتا ہے۔ تجارتی نظام ایک تیار ہوتا ہوا آلہ ہے اور اس کا امکان ہے کہ کسی بھی زبان کے انتخاب اس کے ساتھ ساتھ تیار ہوں گے۔

مزید