海外子公司的采购订单已经创建，供应商也收到了通知，财务却发现订单上的付款条件与合同不符。开发人员接到的需求看似简单，在保存采购订单时查一下供应商，再决定能否继续。真正动手才会发现，事情远没有一条IF语句那么轻巧。付款条件可能来自主数据，也可能被人工修改；订单可能通过界面创建，也可能由接口批量导入；总部和海外公司还有不同的审批规则。检查放得太早，信息不全；放得太晚，错误数据已经落库；直接修改标准程序，眼前的问题解决了，后续升级又可能受影响。这样的场景让我想到洪七公的打狗棒法。它吸引人的地方，并非拿着一根棒子猛打，而是看清对手的来路，借位置、节奏和变化作出恰当回应。放进ABAP开发，最接近它的并不是某条神奇语句，而是一套围绕业务对象建立的能力，识别输入、判断状态、选择入口、施加规则，并在事务边界内收住动作。这个类比有用，但必须守住分寸。打狗棒法是文学中的武学体系，ABAP没有同名技术，也没有一招能通吃所有业务。我们能借的是它的思考方式。面对一个复杂需求，我会先问，真正需要改变的是哪一个业务动作，规则应由谁执行，哪些数据足以支持判断，失败时系统该停在哪里。这几件事弄清楚，代码往往反而短了。老系统里最容易出现的冲动，是哪里有数据就在哪里改。报表查出异常，在报表里补一段更新；接口传来订单，在接口类里塞一段校验；用户抱怨保存失败，又在增强里写另一套判断。几个入口各有一根棒子，挥起来很热闹，规则却开始分叉。界面创建的订单被拦住，批量导入的订单照样通过，往往就是这种分散实现造成的。打狗棒法的第一个启发，是认清攻击从哪里来。对应到企业开发，我们要找的是业务操作真正经过的路径。读取订单列表、改变订单状态、提交审批和保存订单，不属于
