【บันทึกการพัฒนา】จะออกแบบการตัดสินใจไม่สร้างอย่างไร? จาก 40 ไอเด/tool MT4 ยกเลิก 7 ไอเดีย, 4 เกณฑ์ประเมินก่อนการใช้งาน
1. วัตถุประสงค์และสมมติฐานของบทความนี้
Semura Lab. วางแผนเครื่องมือ visualize สิ่งแวดล้อมสำหรับ MT4 จำนวน 40 ไอเดีย โดยเริ่มต้นที่ 27 ไอเดีย เพิ่ม 13 ไอเดีย ภายใต้โครงสร้างปัจจุบัน แยกรายการเป็น สำเร็จ 29 รายการ ยกเลิก 7 รายการ และรอ 4 รายการ
บทความนี้นำเสนอ 7 ไอเดียที่ถูกยกเลิกเป็นตัวอย่าง เพื่อเรียบเรียงเหตุผลที่ตัดสินใจ “ไม่สร้าง” โดยพยายามอ่านในแนวคิดการประเมินก่อนการพัฒนาที่ใช้ร่วมกับ EA หรือเครื่องมืออื่นๆ
2. บันทึก 7 ไอเดียที่ถูกยกเลิก
ชื่อไอเดีย 7 ไอเดียและเหตุผลการยกเลิกมีดังต่อไปนี้ในตาราง
เหตุผลดูเป็นอิสระ แต่เมื่อเรียงลำดับแล้วมี 4 ประเภท ได้แก่ ไอเดียที่พยายามเติมข้อมูลที่ไม่สามารถได้มาด้วยการประมาณ ไอเดียที่มีขั้นตอนก่อนใช้งานมาก ไอเดียที่ยังไม่เห็นสถานการณ์ใช้งานจริงเมื่อเสร็จ ไอเดียที่เป็นชนิดทั่วไปที่คำนวณจากอินพุตเท่านั้น และในตอนต่อไปจะพิจารณาเป็นลำดับ
3. การวิเคราะห์เหตุผลการยกเลิก
3-1. การออกแบบที่เติมข้อมูลที่ไม่สามารถได้โดยตรงด้วยการประมาณ (ไอเดียที่ 18)
ไอเดียที่ 18 “อินดิเคเตอร์สเปรดราคาจริง” มีแนวคิดเชื่อมราคาสั่งซื้อและราคาจองบนกราฟด้วยเส้น อย่างไรก็ตาม MQL4 ไม่มีวิธีเรียกขอราคาคำสั่งซื้อหลังจากที่ส่งคำสั่งไปแล้วได้ ราคาจริงยังคงอยู่ แต่ฝั่งเปรียบเทียบจะไม่เหลืออยู่
ทางเลือกคือใช้ราคาน้ำค่าว่าเปิดของแท่งนาทีที่สั่งซื้อเป็นการประมาณ แต่ในกรณีนี้ สิ่งที่描かคือการล้อเลียนสเปรด ไม่ใช่สเปรดจริง เครื่องมือที่ visualizes สเปรดจะมาแทนที่การประมาณสเปรด การวัดวัตถุประสงค์และวิธีการจึงขัดแย้งกัน จึงยกเลิก
การแทนที่ข้อมูลที่ต้องวัดด้วยการประมาณ ทำให้ไม่สามารถอธิบายความหมายของตัวเลขแก่ผู้ใช้งานได้ นี่คือจุดสำคัญของปัญหาหลักของไอเดียนี้
3-2. ค่าใช้จ่ายในการติดตั้งและสิ่งแวดล้อม (ไอเดีย 16, 26)
ไอเดียที่ 16 “แฟ้มบันทึกขยายใหญ่และการเตือน” เนื่องจากข้อจำกัดการเข้าถึงไฟล์ของ MQL4 ทำให้ไม่สามารถเข้าถึงโฟลเดอร์ล็อกอินได้อย่างแน่นอน เครื่องมือที่เฝ้าดูสถานที่ที่ไม่สามารถส่งถึงได้จึงไม่สมเหตุสมผล แม้จะพยายามหลบหลีกข้อจำกัดก็ไม่คุ้มค่า
ไอเดียที่ 26 “Meters เวลา Ping จราจรเครือข่าย” ไม่สามารถรับค่า Ping จริงด้วย MQL4 เพียงอย่างเดียว ตามนโยบายไม่ใช้ DLL จึงตรวจสอบการวัดโดย WebRequest() แบบจำลอง แต่ผู้ใช้งานต้องอนุญาต URL ที่จุดปลายทางใน MT4 ด้วย
สิ่งที่ได้รับความสำคัญคือ ขั้นตอนที่ผู้สร้างต้องรับภาระจะกลายเป็นภาระของผู้ใช้งานด้วย เครื่องมือที่มีประโยชน์มากกว่าจะเสริมความยุ่งยากในการเริ่มใช้งาน จึงไม่ถูกนำมาใช้
3-3. ไม่ช่วยในการตัดสินใจ (ไอเดีย 22)
ไอเดียที่ 22 “เวลาเซิร์ฟเวอร์และนับแท่งเทียน” แสดงเวลาของเซิร์ฟเวอร์และเวลาที่เหลือจนกว่าจะยืนยันแท่งถัดไป หลังจากทำการออกแบบและคอมไพล์เสร็จ แล้วตรวจสอบว่า “มีประโยชน์อะไรบ้าง”
การใช้งานที่คาดไว้คือ ป้องกันการเข้าเปิดออเดอร์โดยเร็วขณะรอการยืนยันแท่ง และการแก้ปัญหาความคลาดเคลื่อนระหว่างเวลาของเซิร์ฟเวอร์กับ PC อย่างไรก็ตาม เมื่อเห็นตัวเลข ผู้ใช้งานจะตัดสินใจอะไรได้บ้าง ไม่สามารถ描くได้อย่างชัดเจน จึงยกเลิกในสถานะที่พัฒนาแล้ว
3-4. รูปแบบการคำนวณทั่วไปกับการรวบรวมข้อมูลจริง (B2〜B4 และ B1)
ไอเดียเพิ่มเติม B2 (ค่าเฉลี่ยถ่วงน้ำหนักของราคาตั้งต้น), B3 (จำลองแพ้ต่อเนื่อง), B4 (การคำนวณล็อตตามเปอร์เซ็นต์ความเสี่ยง) เป็นชนิดที่คำนวณจากอินพุตเท่านั้น B4 ถูกปฏิเสธก่อนการพัฒนา B2 และ B3 ก็ถูกไม่รับใช้อย่างเดียวกัน ฟังก์ชันที่คำนวณจากตัวเลขที่ป้อนไปยังไม่พบเหตุผลที่นำเสนอเป็นเครื่องมือของตนเอง
ในทางตรงกันข้าม ไอเดียเสริม B1 (ตรวจสอบการสัมผัสสกุลเงินที่ทับซ้อน) ได้รับการนำมาใช้และเสร็จสมบูรณ์ ซึ่งเป็นการรวบรวมข้อมูลจริงของตำแหน่งคงที่แสดงให้เห็นการเบี่ยงเบนในสกุลเงินเดียว กันใช้งานข้อมูลจริงในบัญชีหรือให้ป้อนจากภายนอกก็ได้ ซึ่งเป็นสิ่งที่แยกการรับใช้งวกับไม่รับใช้ออก
4. สี่เกณฑ์ในการประเมินก่อนการพัฒนา
จากกรณีดังกล่าว จัดย่อคำถามที่ควรตรวจสอบก่อนการพัฒนาทั้งสี่ข้อ
(1) สิ่งที่อยากวัด สามารถได้มาโดยตรงหรือไม่ หากไม่ สามารถวัดผลด้วยการประมาณได้หรือไม่
(2) ผู้ใช้งานไม่ต้องการตั้งค่าล่วงหน้าหรือเปลี่ยนแปลงสภาพแวดล้อมก่อนใช้งานหรือไม่
(3) เมื่อเห็นตัวเลขนั้น ผู้ใช้งานจะตัดสินใจอะไร
(4) ใช้ข้อมูลจริงของบัญชีหรือเครื่องมืออื่นๆ ได้หรือไม่
(1) ไอเดีย 18, (2) ไอเดีย 16 และ 26, (3) ไอเดีย 22, (4) เปรียบเทียบระหว่าง B2–B4 และ B1
แนวทางคือ ก่อนเริ่มเขียนโค้ด ควรตอบคำถามทั้งสี่ข้อให้ได้
5. คำตัดสินเพื่อหยุดหลังการพัฒนา
ไอเดียที่ 22 ถูกหยุดหลังการพัฒนาจบลงแล้ว แม้ว่าจะเสียช่วงคนและเวลามาก แต่การเผยแพร่เครื่องมือที่ผู้ใช้งานไม่เห็นโอกาสใช้งานจริง ย่อมทำให้ความน่าเชื่อถือของผลิตภัณฑ์ลดลง
อย่างไรก็ตาม คำถามข้อ (3) ควรถูกตรวจสอบก่อนการพัฒนา ควรสามารถระบุออกมาเป็นข้อความได้ตั้งแต่ในขั้นตอนแนวคิด เพื่อให้กระบวนการประเมินมีคุณค่า
6. ความสำคัญต่อการตรวจสอบ EA
ไอเดียที่ 18 ที่ใช้ “แทนด้วยราคาต้นฉบับนาทีแรก” สอดคล้องกับโครงสร้างที่ EA ใช้ในการ backtest Backtest ก็สร้างขึ้นโดยการประมาณสภาพแวดล้อมในอุดมคติ
มีปัญหาที่เหมาะสมกับการประมาณและปัญหาที่ไม่เหมาะสม หากแทนค่าตัวเลขหลักที่ใช้วัดด้วยการประมาณ ความหมายของผลลัพท์จะเปลี่ยนไป ห้องปฏิบัติการที่ยืนอยู่บนพื้นฐานของ “4 ข้อบกพร่องในการออกแบบ” โดยข้อที่ 4 คือ ความแตกต่างระหว่างสภาพแวดล้อมการทดสอบกับความจริง ตรงกับโครงสร้างนี้ เครื่องมือและการตรวจสอบ EA มีรากฐานร่วมกัน
7. บทสรุป
Semura Lab. ได้พัฒนา 29 ใน 40 ไอเดีย พร้อมทั้งตัดสินใจไม่สร้าง 7 ไอเดีย การบันทึกเหตุผลที่ไม่สร้างช่วยให้การออกแบบมาตรฐานของสิ่งที่เหลืออยู่ชัดเจนขึ้น
ไม่ใช้การประมาณแทนที่ ไม่เรียกร้องให้ผู้ใช้งานต้องทำภาระล่วงหน้า สามารถมองเห็นการตัดสินใจที่อยู่เบื้องหน้าของตัวเลข ใช้ข้อมูลจริงของบัญชี เพื่อคุณสมบัติ 4 ประการนี้เท่านั้นที่ห้องแล็บจะเปิดเผย
หากต้องการคำปรึกษาเกี่ยวกับการออกแบบ EA หรือเครื่องมือและการตรวจสอบ สามารถติดต่อได้ที่ศูนย์ปรึกษา