MQL5代码重构与技术债治理实战

从面条代码到工程化架构，10大模块系统拆解EA重构方法论，让代码可维护、可扩展、可测试

一、技术债识别——你的EA欠了多少"债"？

做EA开发的朋友，应该都有过这样的经历：自己写的EA，过了半年再打开，发现完全看不懂了。加一个新功能，要改十几个地方，改完这里Bug那里，越改越乱。客户提了一个需求变更，评估工期的时候心里直发怵——不是因为需求难，是因为代码已经乱到你不知道动哪里会出问题。

这不是你水平不行，这是几乎所有软件项目都会遇到的问题——技术债。

为了更直观地说明这个问题，我们对eafxtech.com过去承接的20个EA定制项目做了一次代码质量审计，结果有点出乎意料，也在情理之中：

这些数据来自真实的商业项目，有一定的代表性。很多独立开发者可能觉得自己的代码也没那么夸张，但只要你写EA超过半年，回头看看最早写的代码，大概率也会有"这是我写的吗"的感慨。技术债是一个渐进积累的过程，等你意识到的时候，往往已经积重难返了。

得分越高说明技术债越严重。如果得分在7分以上，说明你的代码已经进入"高负债"状态，建议认真考虑重构了。接下来的章节，我们会系统讲解如何识别、评估和治理这些技术债。

二、代码坏味道清单——MQL5中的20个"危险信号"

在开始重构之前，我们需要先建立"嗅觉"——能够识别出代码中哪些地方有问题。这些问题信号在软件工程领域有个专门的名字，叫"代码坏味道"（Code Smells）。这个概念最早由Martin Fowler在经典著作《重构：改善既有代码的设计》中提出，指的是代码中那些不是Bug、但暗示着更深层问题的"味道"。

坏味道本身不是Bug，程序照样能跑。但它是Bug的温床，是维护成本的隐形推手。识别坏味道是做好重构的第1步。下面我们结合MQL5语言特性和EA开发场景，梳理出4大类20个最常见的代码坏味道。

2.1 命名类坏味道

命名是编程中最基础也最容易被忽视的环节。好的命名能让代码自带文档属性，差的命名会让阅读者一头雾水。

2.2 函数级坏味道

函数是代码组织的基本单元。函数级别的坏味道最直观，也相对最容易修复。

函数级坏味道中，最典型的就是"超长函数"和"深层嵌套"。很多EA的OnTick函数就是这两个问题的重灾区——所有逻辑全部堆在一起，既有指标计算，又有开仓判断，还有持仓管理和风控逻辑，读起来像在走迷宫。

2.3 类/结构体级坏味道

MQL5是支持面向对象的，很多开发者也会用到类和结构体，但用得不规范同样会产生问题。

比如"全局变量泛滥"——大量input参数和全局变量散落在文件各处，变量之间的依赖关系不清晰，改一个变量可能影响到十几个地方。又比如"大类（上帝类）"——一个类有几十个成员变量和方法，什么都管，最后变成了一个什么都往里装的大杂烩。

还有一个常见的MQL5场景是"数据泥团"——几个变量总是绑在一起出现，比如开仓时总是同时传symbol、lot、sl、tp这几个参数，但从来没有被组织成一个结构体。每次开仓都要写一遍参数传递，既啰嗦又容易出错。

2.4 架构级坏味道

架构级坏味道是最深层的技术债，修复成本也最高，但收益也最大。

架构级的问题往往不是一天形成的，而是在一次次"先这么写吧，后面再优化"的妥协中逐渐积累起来的。等到你意识到问题的时候，可能已经是"不动等死，动了找死"的两难境地。本文后面的章节会专门讲解如何安全地进行架构级重构。

三、重构原则与时机——什么时候该重构，什么时候不能动？

在讲具体的重构手法之前，有必要先明确一些基本原则和时机判断。很多人对重构有误解，觉得重构就是"把代码写好看一点"，或者"没事找事瞎折腾"。其实不是的，重构是有明确目标和严格纪律的工程活动。

3.1 重构的三大原则

其一，小步快跑。不要试图一次把所有问题都解决了。每次只做一个小改动，改完就测试，确认没问题了再改下一个。这样即使出了问题，也很容易定位是哪一步改坏的，回滚成本很低。

第二，测试先行。在重构之前，先确认你有办法验证代码的行为是否正确。可以是自动化测试，可以是回测对比，也可以是手动的检查清单。总之，你得有一根"准绳"，知道改完之后功能有没有变。

第三，行为保持一致。重构的目标是优化代码结构，不是修改功能逻辑。在重构过程中，不要顺手改需求、加功能、修Bug——那些事情等重构完了再做。混在一起做，你就分不清是重构导致的问题还是需求变更导致的问题了。

3.2 什么时候该重构

3.3 什么时候不能动

不是所有时候都适合重构。有些情况下强行重构，反而会带来更大的风险。

还有一种情况要特别警惕，就是"过度设计陷阱"。有些开发者学了重构和设计模式之后，看什么都觉得可以优化，为了重构而重构，把简单的事情搞复杂。比如一个只有几十行的小脚本，非要硬套分层架构和设计模式，结果代码量翻了三倍，可读性反而更差了。

四、函数级重构——拆解千行OnTick的第1步

函数级重构是最基础也是最常用的重构手法。对于大多数EA来说，重构的第1步就是把那个动辄上千行的OnTick函数拆解开。本章我们讲解5种核心的函数级重构手法，每种都配有MQL5代码的前后对比。

4.1 提取函数（Extract Method）

提取函数是最常用的重构手法，没有之一。它的做法很简单：把一段有独立语义的代码从大函数中拿出来，放到一个新的函数里，用函数名来描述这段代码的意图。

我们来看一个MQL5中的典型例子——面条代码风格的OnTick函数片段：

// 重构前：面条代码示例（片段）
void OnTick()
{
   double ma5  = iMA(_Symbol, _Period, 5,  0, MODE_SMA, PRICE_CLOSE, 0);
   double ma20 = iMA(_Symbol, _Period, 20, 0, MODE_SMA, PRICE_CLOSE, 0);
   double ma60 = iMA(_Symbol, _Period, 60, 0, MODE_SMA, PRICE_CLOSE, 0);

   if(PositionsTotal() == 0)
   {
      if(ma5 > ma20 && ma20 > ma60)
      {
         double lot = 0.1;
         double sl  = 300 * _Point;
         double tp  = 600 * _Point;
         // ... 开仓请求构建
         OrderSend(...);
      }
      else if(ma5 < ma20 && ma20 < ma60)
      {
         // 又复制一遍差不多的代码
         double lot = 0.1;
         double sl  = 300 * _Point;
         double tp  = 600 * _Point;
         OrderSend(...);
      }
   }
   else
   {
      // 200行持仓管理逻辑...
   }
}

这段代码有几个典型问题：指标计算直接写在OnTick里、多头和空头的开仓逻辑重复、魔法数字（0.1、300、600）满天飞、OnTick里堆了太多职责。让我们用提取函数来重构它：

// 重构后：函数提取 + 命名优化 + 常量定义
input double INPUT_LOT_SIZE       = 0.1;  // 开仓手数
input int    INPUT_STOP_LOSS_PIPS  = 30;   // 止损点数
input int    INPUT_TAKE_PROFIT_PIPS = 60;  // 止盈点数

// 计算指定周期的SMA值
double CalcSMA(int period, int shift = 0)
{
   return iMA(_Symbol, _Period, period, 0, MODE_SMA, PRICE_CLOSE, shift);
}

// 判断是否为多头排列
bool IsBullishAlignment()
{
   return (CalcSMA(5) > CalcSMA(20)) && (CalcSMA(20) > CalcSMA(60));
}

// 判断是否为空头排列
bool IsBearishAlignment()
{
   return (CalcSMA(5) < CalcSMA(20)) && (CalcSMA(20) < CalcSMA(60));
}

// 开多单
void OpenBuyPosition()
{
   double lot = INPUT_LOT_SIZE;
   double sl  = INPUT_STOP_LOSS_PIPS  * _Point;
   double tp  = INPUT_TAKE_PROFIT_PIPS * _Point;
   OrderSend(...);
}

// 开空单
void OpenSellPosition()
{
   // 同样的逻辑，方向相反
   ...
}

void OnTick()
{
   if(PositionsTotal() == 0)
   {
      if(IsBullishAlignment())      OpenBuyPosition();
      else if(IsBearishAlignment()) OpenSellPosition();
   }
   else
   {
      ManageOpenPositions();
   }
}

4.2 函数级重构5步法

4.3 MQL5特有的注意事项

在MQL5中做函数提取，有几个特殊的地方需要注意。

一是input参数的处理。MQL5中的input变量是全局可见的，提取函数的时候，如果你把input参数留在全局，函数可以直接访问，这看起来很方便，但也意味着函数依赖了全局状态。更推荐的做法是把需要的数据作为参数传进去，让函数成为一个纯函数，这样更容易测试和复用。

第二，全局变量的陷阱。很多EA用了大量全局变量来保存状态，提取函数的时候这些全局变量依然可以被访问，看起来什么都不用改。但这恰恰是问题所在——函数依赖了隐式的全局状态，你不知道函数会不会偷偷修改了某个全局变量，影响其他地方的逻辑。重构过程中要有意识地减少全局变量的使用。

第三，OrderSend等交易函数的副作用。交易函数会产生实际的订单操作，这是一种副作用。提取函数的时候要特别注意，不要因为提取导致执行顺序变化，或者在不该执行的时候执行了交易操作。重构前后，交易函数被调用的次数、时机和参数都应当保持一致。

五、类级重构——用面向对象思想整理混乱的状态管理

函数级重构解决了代码组织的问题，但状态管理的问题依然存在。当你的EA中有大量全局变量、且这些变量之间有明确的关联关系时，就应该考虑用类来封装了。本章我们讲解MQL5中类级重构的核心手法。

5.1 提取类（Extract Class）

提取类是类级重构中最常用的手法。它的思路是：找出一组总是一起出现的数据和操作这些数据的函数，把它们封装成一个类。

最典型的场景就是订单管理。很多EA中，订单相关的全局变量和函数散落在文件各处：

// 重构前：订单管理状态散落在全局
ulong  g_positionTicket    = 0;       // 当前持仓单号
datetime g_lastOrderTime   = 0;       // 上次下单时间
int    g_orderMagic        = 12345;   // 订单Magic号
int    g_orderRetryCount   = 0;       // 下单重试次数

bool OpenBuy(double lot, double sl, double tp)   { /* ... */ }
bool OpenSell(double lot, double sl, double tp)  { /* ... */ }
bool ClosePosition(ulong ticket)                 { /* ... */ }
void CloseAllPositions()                         { /* ... */ }
int  GetPositionCount()                          { /* ... */ }
bool ModifyStopLoss(ulong ticket, double newSl)  { /* ... */ }
// ... 还有更多全局函数

这些变量和函数明显是一组的——它们都和订单管理有关。把它们封装成一个类，逻辑就清晰多了：

// 重构后：封装为COrderManager类
class COrderManager
{
private:
   ulong    m_positionTicket;   // 当前持仓单号
   datetime m_lastOrderTime;    // 上次下单时间
   int      m_magicNumber;      // 订单Magic号
   int      m_retryCount;       // 下单重试次数

public:
   COrderManager(int magic) : m_positionTicket(0), m_lastOrderTime(0),
                              m_magicNumber(magic), m_retryCount(0) {}

   bool OpenBuy(double lot, double sl, double tp);
   bool OpenSell(double lot, double sl, double tp);
   bool ClosePosition(ulong ticket);
   void CloseAllPositions();
   int  GetPositionCount();
   bool ModifyStopLoss(ulong ticket, double newSl);

   ulong    GetPositionTicket() const { return m_positionTicket; }
   datetime GetLastOrderTime()  const { return m_lastOrderTime;  }
};

5.2 其他类级重构手法

除了提取类，还有几个常用的类级重构手法值得了解：

内联类（Inline Class）：如果一个类已经没什么职责了，里面就一两个方法，那不如把它合并到调用它的类里去。类不是越多越好，每个类都要有足够的存在价值。

搬移函数（Move Method）：一个函数用另一个类的数据比用自己类的数据还多，说明这个函数应该搬到另一个类里去。判断标准：这个方法和哪个类的数据交互最多，就应该属于哪个类。

隐藏委托关系（Hide Delegate）：客户代码通过A对象获取B对象，然后调用B对象的方法，形成了一条长链。应该在A对象上提供一个方法来直接完成这件事，把B对象隐藏起来，减少耦合。

引入空对象（Introduce Null Object）：代码中到处都是判断对象是否为空的语句。可以创建一个"空对象"子类，实现默认的空行为，这样调用方就不用每次都判空了。在MQL5中，这个手法可以用来处理"没有持仓"的情况。

六、架构级重构——从单文件到分层架构的演进

当你完成了函数级和类级的重构之后，代码质量会有明显的提升。但如果你的EA还是所有东西都塞在一个文件里，那架构层面的技术债依然存在。本章我们从架构视角出发，讲解如何将一个单文件EA逐步演进为分层架构。

6.1 MQL5 EA的经典分层架构

一个工程化的EA，通常可以分为四层，从上层策略到底层数据，各司其职，边界清晰：

6.2 Include文件的组织规范

架构级重构的落地形式，就是把代码拆分到多个Include文件中。MQL5的Include机制和C语言的#include类似，本质上是文本替换，但用好它可以让你的项目结构非常清晰。

6.3 循环依赖的避免方法

拆分Include文件的时候，最容易遇到的问题就是循环依赖——A文件#include B，B文件又#include A，导致编译报错或者包含顺序敏感。

架构级重构完成后，你会发现一个意想不到的好处：代码非常适合接入CI/CD流水线。每个模块独立、职责单一、可独立测试，这正是自动化构建和自动化测试的理想状态。这也是为什么我们把"重构 + CI/CD + 自动化测试"称为MQL5工程化铁三角——三者相辅相成，缺一不可。（关于CI/CD的详细内容，可以阅读本站9月29日发布的《MT5 EA CI/CD构建自动化实战》一文）

七、重构安全网——测试保障让你放心改代码

很多人不敢重构，最大的顾虑就是"改完出Bug怎么办"。这个顾虑非常合理。没有测试保障的重构就是在裸奔，你不知道改完是对是错，全凭运气。所以在大规模重构之前，一定要先搭建好测试安全网。

7.1 MQL5单元测试方案

MQL5生态中有一些单元测试框架，比如MQL5Unit。也可以自己实现一个简单的断言宏，满足基本的单元测试需求。下面是一个可直接复用的MQL5单元测试模板：

// 单元测试断言宏定义
#define ASSERT_TRUE(condition)  \
   if(!(condition)) { Print("FAIL: ", __FUNCTION__, " - Assertion failed: ", #condition); return false; }

#define ASSERT_EQ(expected, actual)  \
   if((expected) != (actual)) { Print("FAIL: ", __FUNCTION__, " - Expected: ", (expected), ", Got: ", (actual)); return false; }

// 示例：测试CalcSMA函数
bool Test_CalcSMA_Basic()
{
   double ma5 = CalcSMA(5, 0);
   ASSERT_TRUE(ma5 > 0);          // MA值应该大于0
   return true;
}

// 示例：测试IsBullishAlignment函数
bool Test_IsBullishAlignment_KnownData()
{
   // 准备测试数据...
   // 调用函数...
   // 断言结果...
   return true;
}

// 运行所有测试
bool RunAllTests()
{
   bool allPassed = true;
   allPassed &= Test_CalcSMA_Basic();
   allPassed &= Test_IsBullishAlignment_KnownData();
   // ... 更多测试

   if(allPassed)
      Print("All tests PASSED!");
   else
      Print("Some tests FAILED! See log for details.");

   return allPassed;
}

对于有明确输入输出的纯函数（比如指标计算类、参数校验类函数），单元测试非常有效。对于有副作用的交易函数，单元测试的难度会大一些，可以用模拟对象（Mock）来隔离真实的交易调用，不过在MQL5中实现起来相对复杂，可以先用回归测试来覆盖。

7.2 回测曲线对比法

对于EA来说，最实用的验证方法莫过于回测曲线对比了。做法非常简单：

八、重构度量指标——用数据衡量重构效果

重构不能只凭感觉。你说"代码质量提升了"，有什么证据？说"维护效率提高了"，提高了多少？这些问题都需要用数据来回答。本章我们介绍几个常用的重构度量指标，以及如何在MQL5项目中应用它们。

8.1 圈复杂度（Cyclomatic Complexity）

圈复杂度是衡量代码逻辑复杂度的经典指标，由Thomas McCabe于1976年提出。它衡量的是代码中独立路径的数量，数值越高说明代码越复杂，越容易出Bug，也越难测试。

8.2 其他常用度量指标

代码重复率：代码中重复片段占总代码量的比例。重复率越高，维护成本越高，因为改一个Bug要同步改好几处。EA开发中最常见的重复就是开仓/平仓逻辑的重复。

函数平均行数：项目中所有函数的平均行数。这个指标反映了代码的粒度是否合理。平均行数太大说明函数拆分不够，太小又可能导致过度拆分。建议的函数平均行数在15-30行左右比较合适。

类耦合度：一个类依赖了多少其他的类。耦合度越高，说明类之间的依赖关系越复杂，修改一个类可能影响很多其他类，牵一发而动全身。降低耦合是架构设计的核心目标之一。

测试覆盖率：有多少比例的代码被测试覆盖到了。覆盖率越高，重构的安全感越强。当然，覆盖率不是越高越好，关键是核心路径的覆盖。对于EA来说，至少开仓、平仓、风控这几个核心路径要有测试覆盖。

8.3 重构前后的性能对比

很多人担心重构会不会影响EA的运行速度。毕竟EA是实时运行的，OnTick里每多一个函数调用是不是都会变慢？答案是：几乎不会。现代编译器的优化能力非常强，函数调用的开销可以忽略不计。而且重构后的代码，因为结构更清晰，反而更容易做针对性的性能优化。

我们做过一个实测对比：同一个策略，重构前和重构后，在策略测试器中的运行表现如下：

如果你也想测量自己的EA重构前后的性能变化，可以用下面这个简单的性能测试函数，在OnTick末尾统计执行时间：

// 性能测试辅助函数
ulong g_tickStartTime = 0;
int   g_tickCount     = 0;
long  g_totalTimeUs   = 0;

void OnTick()
{
   g_tickStartTime = GetMicrosecondCount();

   // --- 你的EA核心逻辑 ---
   ...
   // -----------------------

   // 统计耗时
   ulong elapsed = GetMicrosecondCount() - g_tickStartTime;
   g_totalTimeUs += elapsed;
   g_tickCount++;

   // 每1000个Tick输出一次平均耗时
   if(g_tickCount % 1000 == 0)
   {
      double avgUs = (double)g_totalTimeUs / g_tickCount;
      Print(StringFormat("Tick统计: 次数=%d, 平均耗时=%.2fμs", g_tickCount, avgUs));
   }
}

九、完整实战案例——一个"面条EA"的重构全记录

前面八章讲了理论和方法，这一章我们通过一个完整的实战案例，把所有知识点串联起来。我们以一个真实的"单文件千行级"均线交叉EA为起点，完整演示从技术债评估到制定计划、再到各级重构和测试验证的全过程。

9.1 案例背景与技术债评估

我们的案例是一个基于三均线交叉策略的EA，主要逻辑是：MA5上穿MA20且MA20在MA60上方时开多，MA5下穿MA20且MA20在MA60下方时开空，带固定止损止盈。代码是一个单文件，总共800多行，OnTick函数就占了400多行。

按照第1章的技术债自查清单评估，这个EA的得分是8分（满分10分），属于"高负债"状态。主要问题包括：OnTick超长（400+行）、多空开仓逻辑重复、魔法数字满天飞、全局变量超过15个、if嵌套最深达5层、没有任何测试。

根据评估结果，我们制定了一个分阶段的重构计划：

9.2 第1阶段：函数级重构

第1阶段的目标是把大函数拆成小函数。我们从OnTick入手，逐段识别可以提取的逻辑块：

首先，把指标计算的部分提取为CalcSMA函数，把三均线排列判断提取为IsBullishAlignment和IsBearishAlignment函数。这一步很简单，就是把计算逻辑从OnTick里搬出来，封装成有语义的函数。

然后，把开仓逻辑提取为OpenBuy和OpenSell两个函数。原来的代码中，多头开仓和空头开仓的逻辑几乎一样，只是方向相反，重复代码很多。提取之后，两个函数各自负责一个方向，逻辑清晰，而且以后修改开仓逻辑只需要改这两个地方。

接着，把持仓管理的逻辑也拆成几个函数：CheckStopLoss、CheckTakeProfit、CheckTrailingStop、CloseAllPositions。每个函数只做一件事，命名清晰。

完成第1阶段后，OnTick函数从400多行精简到了40多行，读起来像读一首诗——每一行都是一个清晰的动作，不需要再钻到细节里去。

这一步完成后，我们跑了回测对比，净利润、最大回撤、交易次数和基线完全一致。✓ 第1阶段通过。

9.3 第二阶段：类级重构

函数级重构完成后，代码结构好了很多，但全局变量还是太多——订单状态、指标句柄、风控参数，总共十几个全局变量散落在文件里，看着还是不舒服。

于是我们开始第二阶段：类级重构。

首先封装COrderManager类。把所有和订单操作相关的变量和函数都放进去：持仓Ticket、上次下单时间、Magic号、重试计数，以及OpenBuy、OpenSell、ClosePosition、CloseAll、GetPositionCount、ModifySL等方法。封装完成后，订单管理这一块就从全局作用域中"消失"了，变成了一个对象的内部状态。

然后封装CIndicatorCalculator类。把指标句柄、缓存数据、计算方法都放进去。这个类的职责是提供指标数据的查询接口，上层不需要知道指标是怎么计算的，只需要调用"给我MA5的值"、"给我RSI的值"这样的接口就行。

最后封装CRiskManager风控类。把仓位计算、止损止盈计算、最大持仓限制这些风控逻辑都放进去。风控逻辑是EA的核心，单独拎出来封装成类，既清晰又安全——以后修改风控规则的时候，只需要动这一个类，不会影响其他模块。

这一步完成后，全局变量从15个减少到了3个（三个类的实例对象）。代码的模块化程度大大提高。回测对比通过，交易结果和基线一致。✓ 第二阶段通过。

9.4 第三阶段：架构级重构

类级重构完成后，所有逻辑都封装在类里了，但所有的类定义还都在同一个文件里。800行的代码虽然组织得不错，但一个文件还是太长了。

第三阶段就是把这些类拆分到不同的Include文件中，建立分层架构。

我们建立了一个MyStrategy目录，里面按照分层结构放了四个子目录：Data、Execution、Risk、Strategy。然后把CIndicatorCalculator放到Data目录，COrderManager放到Execution目录，CRiskManager放到Risk目录，信号生成的逻辑单独抽出来放到Strategy目录的SignalGenerator里。

主文件只剩下OnInit、OnDeinit、OnTick三个函数，总长度不到50行。OnInit里初始化各个模块，OnTick里按照"数据→信号→风控→执行"的顺序依次调用，流程一目了然。

架构级重构的过程中，我们遇到了一个小坑：IndicatorCalculator和RiskManager都用到了价格数据，一开始两边各算各的，导致了一些重复计算。后来我们把价格数据的获取统一放到Data层，RiskManager通过Data层来获取数据，既消除了重复，又明确了依赖方向。

回测对比通过，交易结果和基线完全一致。✓ 第三阶段通过。

十、工具与SOP——建立团队级重构规范

讲到这里，重构的理论和方法就差不多讲完了。最后一章，我们来聊一些落地的东西——用什么工具、遵循什么流程、怎么把重构变成团队的日常习惯。

10.1 推荐的重构工具链

10.2 标准重构SOP流程

10.3 重构+CI/CD的集成实践

当你的代码完成了架构级重构，变成了模块化的分层结构之后，就具备了接入CI/CD流水线的条件。反过来，CI/CD也能让重构更安全、更高效——每次改动都自动编译、自动测试、自动跑回测，有问题能及时发现。

最后，想说的是：技术债治理是一场持久战，不是一劳永逸的。你不可能通过一次重构就把所有问题都解决了，然后永远不用再管了。代码在不断迭代，技术债也会不断产生。关键是建立起持续重构的习惯和机制，把技术债控制在可接受的范围内，而不是让它积累到积重难返的程度。

希望这篇文章能帮你建立起对MQL5代码重构和技术债治理的系统性认识。如果你也在被烂代码困扰，不妨从今天开始，从小处着手，先把你最看不顺眼的那个函数提取出来。重构这件事，什么时候开始都不晚，但越早开始，成本越低。

微信公众号
晓辉编程

视频号
晓辉说EA