交易策略的实施与模型还是有很多区别的。很多订单执行的细节问题，比如over fill，partial fill，rejection，延迟问题，有时还要考虑避免自成交，等等。而这些情况模型一般不会考虑。 那么大家都是如何处理这些情况的，是否有一些编程范式，来分层次处理这些问题？使得顶层的代码基本上可以与模型保持一致，订单执行的细节在其他的层面处理？ 之前也提出过类似的问题，但也没有得到什么有用的结论。因为研究的过程中发现很大一部分时间是用在了代码的细节实现及DEBUG中，有时一些微小的BUG却浪费了大量的时间去发现。而当代码复杂一些的时候，甚至如何去DEBUG也无从下手（当然这个问题可以通过设计更合理的代码结构解决）。总之，在调试程序的过程中浪费了大量的时间后，我感到可能方法有点问题。因此想请问各位都是如何处理这些问题的。 谢谢！ 另外请问这个论坛如何贴图啊？？？
既然是细节问题，恐怕很难泛泛地回答如何处理，只能见招拆招。 调试程序耗费时间是正常的。不管什么系统，一旦有可靠性的要求，代价就非线性增长了。 换个角度想，也未必就是坏事：如果别人搞不定的事你能搞定，这不就是优势嘛。
vinny2009好像已经被这种细节折磨了很久了，以前我们在一个帖子里面讨论过一些， 但是正如Wenyan所说，细节的东西很难一概而论，有时候就是流程图也很难画的， 因为里面的依赖关系非常多。 就给你贴个图吧，看看通过编程，或者画流程图是否能很好地解决。 编程之所以很痛苦，就是因为很难完善的覆盖下面的这些依赖关系， 而这只是最简单的一个进场操作而已。 下面是最简单的一个建立多头仓位的操作，里面的箭头表示一个订单各种细节，各种状态之间的依赖关系，有些箭头是出去或者进来的，表示和其他交易计划（或订单）之间的关系。 如果看不了的话，原图在这里： http://www.atsxl.com/zh:ug-core-ws
感谢上面各位的回复。 我现在的想法是通过在模型层与底层接口之间增加服务层、信息层来处理。 之所以这样做的原因是我发现很多策略中复杂的代码实际上是要处理一些订单的跟踪问题，这可以通过增加信息层来处理，另外如果要自动处理撤单失败，发送订单失败等等问题，则我希望通过服务层来解决这些问题。被自动处理的消息就不再转发给模型层。由于不同的模型可能有不同的细节需求，因此服务层应该设计为可以由用户（即模型）自行设定的。 目前还在尝试实现这些想法的过程中，有新的消息我会更新的。谢谢！
我现在这个系统的代码最早有09年的，3，4年了，还是能看懂的， 主要是我的注释比代码多得多。 很多代码即使不用了，也不删除，而是变成注释保留着， 今后某个时候会用到，比如类似的代码就重用，或者知道为什么这段代码不能用。 另外我保存着详细的 change log, release note， 所有功能的改进，变化都可以找到源头。 不过不得不承认，我好几年前写得一个（或几个）使用mt4的交易系统是没法看了， 虽然也有很多注释，但是涉及到策略的部分时就开始头晕了， 因为要考虑的细节和各种情况实在太多，复杂一点的策略，代码非线性增长， 而不是我的资金曲线非线性增长。 所以才有了后面这套基于 excel，使用公式，动态依赖关系，事件驱动的系统。
不好意思，当时没看到回复。 比如把公共部分写成一个MT4的EA模版，放在mqh文件里，然后每次写新EA就引用这个头文件，这样就省去很多重复劳动，一个新EA几行就写完了。 执行细节问题，对于MT4有个比较成熟的库，LibOrderReliable，搜一下就能找到。