这段逻辑要不要单独拆成一个功能块？
做PLC程序，经常遇到一个纠结：这段逻辑要不要单独拆成一个功能块？
拆了怕过度设计，增加调用层级，看起来反而复杂；不拆怕程序越写越长，后面的人看不懂。
与其纠结，不如用三个维度来判断：可复用、可扩展、可独立。 满足其中任何一个，就值得拆。
(本文受2026 TCC大会启发，由龙虾辅助撰写，请谨慎食用)
---
维度一：可复用
这段逻辑在别的地方还能用吗？
这是最直接的判断标准。如果你发现同样的代码出现了两次以上，或者在不同项目里反复出现，那它就该独立出来。
比如机器里的安全连锁逻辑——急停、门锁、防护罩……几乎每台机器都要写。如果不拆，每台机器复制粘贴一遍，某天发现一个bug，要改十几个项目。拆成标准FB，一处修改，处处生效。
再比如放卷收卷控制，卫星式柔印机用，机组式柔印机也用，将来换一种印刷工艺可能还用。这种逻辑天然适合做标准模块。
反之，如果一段逻辑只在当前程序里出现一次，而且逻辑简单、不会在其他项目复用，那就没必要拆。 比如某个客户特有的操作流程，只在这台机器上有，写成一个带注释的代码段就够了。
判断要点：这段逻辑是否会在多个项目、多个设备上反复出现？是 → 拆。
---
维度二：可扩展
这台设备将来会不会增加更多功能模块？
这是很多工程师容易忽略的一个维度。一台印刷机今天可能是6色，明年客户可能要扩到8色；今天只有一组收卷，将来可能要加双收卷。
如果设备有扩展的可能，那么当前的程序结构就必须为未来的扩展预留标准接口。
举个实际的例子：
不考虑扩展的做法：主程序里直接调用 ColorUnit_1 到 ColorUnit_6 六个色组，所有逻辑硬编码。将来加色组？到处改代码。
考虑扩展的做法：定义一个标准的色组功能块（FB）接口，用数组管理色组实例。加色组？新建一个DB，改一下数组长度，完事。主程序一行都不用动。
可扩展的本质是：当你往系统里加新模块时，老模块的代码不需要改动。
这意味着：
接口要标准化——每个同类功能块的输入输出管脚定义要一致
管理要参数化——具体数量、配置通过参数或数据块设定，不硬编码
扩展要低成本——加一个功能模块，不应该牵动整个程序的架构 判断要点：这台设备有没有扩展更多同类功能模块的可能？有 → 提前拆分，做好标准接口。
---
维度三：可独立
关掉这段逻辑，机器的其他部分还能正常工作吗？
这是测试模块边界最直接的方法。如果一段逻辑关掉后，机器的其他功能不受影响，说明它是相对独立的，值得单独成模块。
再拿印刷机举例：
关掉套准控制，机器还能正常走纸，只是印不准 → 独立，应该拆
关掉张力控制，纸都走不了了 → 张力和走纸逻辑耦合很深，不适合硬拆 独立性的好处：调试时可以单独测试。 一个独立的模块，可以给它模拟输入，看输出是否正确，不用每次都启动整台机器。这在现场调试时能省大量时间。
这里有个微妙之处：不是所有耦合都需要消除。 物理上天然耦合的功能（比如电机驱动器和编码器反馈），强拆反而增加数据传递的复杂度。独立性的目标不是零耦合，而是可控的耦合——模块之间通过明确的接口通讯，而不是互相访问对方的内部变量。
判断要点：这段逻辑能否在不影响其他功能的前提下独立运行和调试？能 → 拆。
---
三个维度都满足怎么办？
如果三个维度都满足——这段逻辑既会复用，设备也有扩展需求，而且可以独立运行——那它就是最应该拆成标准模块的候选。
如果三个维度都不满足呢？那就别折腾。过度设计和不设计一样，都是坑。
大多数实际情况下，满足一两个维度就值得考虑拆分了。不需要追求完美，够用就好。
---
一句话总结
模块拆分不是目的，降低维护成本才是。
用可复用、可扩展、可独立三个维度来衡量，满足越多越该拆，全不满足就不拆。
好的PLC程序，不是模块拆得越多越好，而是每个模块都有存在的理由。
下一主题
