读了1000行老代码我发现最好的设计是“简单”摘要运维多年第一次用AI深读WMS库位管理模块。1000多行代码AI几分钟就扫完了但真正让我震撼的是一个跑了10多年的蛇形算法——奇数排从左到右偶数排从右到左同列共享动线号。简单到几十行代码却让拣货效率提升了40%。AI能告诉我代码“是什么”但说不清“为什么”。那些看似重复的代码背后是不同开发者在不同时期为业务稳定做出的选择。读懂前人设计意图比写新代码更难。好的设计不是用复杂的技术解决问题而是用简单的规则解决复杂的问题。技术选型的本质是tradeoff没有完美方案只有适合场景的方案。文章目录读了1000行老代码我发现最好的设计是“简单”摘要一、先说背景一套跑了10多年的WMS系统二、用AI扫了一遍代码发现什么了三、从迭代历程看每个设计都有它的时代背景四、什么是动线号为什么它很重要五、蛇形走位一个简单但有效的算法问题拣货员的行走路径双列通道两排一起拣为什么双列通道是核心效率提升多少核心逻辑的Java实现为什么这个设计在当时是最优的六、架构思考10多年积累的设计智慧为什么说简单才是最难的设计静态预计算的设计权衡数据库设计的一个原则七、未来可能的演进方向1. 动态动线调整2. 智能路径推荐3. 状态管理演进给同行的几个提醒八、AI辅助开发的体会AI做得到的AI做不到的最佳实践九、总结下一篇预告这套WMS系统在我们行业跑了10多年我运维了好几年最近开始介入开发。说实话之前我对库位管理模块的理解停留在能用就行的层面。直到最近用AI辅助做代码审计把1000多行的库位管理核心代码逐行扫了一遍我才真正理解了这套系统的设计智慧——它不是一蹴而就的先进而是10多年业务迭代中沉淀下来的实用。其中有一个算法让我印象深刻——蛇形走位。好的设计不是用复杂的技术解决问题而是用简单的规则解决复杂的问题。这是我从这套系统中学到的最重要的一课。今天聊聊这个算法以及它背后的架构思考。一、先说背景一套跑了10多年的WMS系统几年前我开始运维公司这套WMS仓储管理系统。这套系统在我们行业跑了10多年支撑着电商仓库的日常作业收货、上架、存储、拣货、发货。作为运维人员我每天和这套系统打交道处理线上问题、协调业务需求、对接开发团队。但说实话对代码层面的设计我关注不多。库位管理是WMS的基础模块。什么是库位就是仓库里货架上的一个个格子每个格子有一个编码比如A-01-02-003-04代表A库区、1区、2排、3列、4层。拣货员每天的任务就是根据订单去对应的库位把货物取出来。关键问题是去哪个库位、按什么顺序走决定了拣货效率。这套系统从早期就考虑了路径优化经过10多年的迭代形成了现在的方案。二、用AI扫了一遍代码发现什么了最近我开始介入这套系统的开发工作。开发过程中我用AI辅助工具对库位管理模块做了一次深度分析。1000多行代码逐行扫了一遍。AI帮我做了几件事识别代码结构多个方法分属多个功能模块发现自动创建库位逻辑有多处代码实现了自动创建库位的功能分布在不同的业务场景中梳理调用关系多个业务模块依赖这个库位管理器追溯迭代历程从早期到近年经历了多次功能迭代AI的分析很快几分钟就完成了。但AI只能告诉你是什么不能告诉你为什么。比如那些自动创建库位的代码AI会说这是重复代码。但当我深入分析后才发现每处代码背后都是一个独立的业务场景是不同开发者在不同时期为了保证业务稳定而做出的选择。真正让我关注到的是其中一个算法——动线号生成。三、从迭代历程看每个设计都有它的时代背景我翻了一下这套系统的提交记录梳理了库位管理模块的演进脉络早期 → 基础库位管理和动线号生成 中期 → 支持阁楼货架等特殊场景 近年来 → 电商打包台、库存精细化管理等新功能每一次修改都是为了响应当时的业务需求业务需要支持阁楼货架于是有了阁楼动线号的特殊处理业务扩展到新的仓库类型于是有了新的动线号逻辑电商打包台上线于是有了打包台相关的库位配置库存管理精细化于是有了库位锁定功能每一次设计在当时都是最优解。前人面对的是当时的业务场景、技术条件、团队能力。他们做出了最适合当时的选择。作为后来者我的职责不是评判前人的设计是否完美而是理解他们的设计意图在此基础上继续演进。四、什么是动线号为什么它很重要每个库位都有一个叫动线号的属性表示拣货员应该按什么顺序访问这个库位。动线号越小越先被拣货。打个比方你去超市购物如果超市货架是按蔬菜区→水果区→肉类区→日用品区排列的你按这个顺序走一遍就买完了。但如果超市货架是乱排的你可能要来回跑好几趟。动线号就是给库位排顺序。我扫了一遍代码发现了5种不同的动线号生成算法蛇形遍历归并交叉权重编码递归分治编码解析最让我感兴趣的是第一种——蛇形遍历。五、蛇形走位一个简单但有效的算法问题拣货员的行走路径假设仓库是一个网格有5排、10列。拣货员需要拣10个SKU分布在不同位置。如果没有路径优化拣货员可能这样走排1: 走到最右 → 回头走到中间 → 再走到右边 排2: 走到最左 → 回头走到右边 排3: ...来回折返浪费大量时间。如果用蛇形路径拣货员这样走排1: 从左走到右 排2: 从右走到左 排3: 从左走到右 排4: 从右走到左像蛇一样S形穿行几乎没有折返。双列通道两排一起拣上面是单列通道的情况。但实际仓库中绝大多数货架都是双列通道——通道两侧都有库位。无论是横梁式货架、阁楼货架还是驶入式货架拣货员走进一个通道左右两侧都能取货。如果只拣一侧就退出通道再进另一个通道拣另一侧会浪费大量时间。双列通道的核心思想在同一个通道内同时完成前后两排的拣货减少通道间的折返。这是路径优化中最关键的场景。场景正序拣选从左到右前排: [列1-A, 列2-B, 列3-C] 后排: [列1-D, 列2-E, 列3-F] 拣选路径: A→D→B→E→C→F ↓ ↓ ↓ 同列连续完成前后排拣货员从左走到右每到一列就完成该列的前后排拣货。场景倒序拣选从右到左前排: [列3-C, 列2-B, 列1-A] 反转后 后排: [列3-F, 列2-E, 列1-D] 反转后 拣选路径: C→F→B→E→A→D ↓ ↓ ↓ 同列连续完成前后排拣货员从右走到左每到一列就完成该列的前后排拣货。两种场景的共同点无论哪个方向同一列的前后排库位都是连续拣选的。这样拣货员在同一个通道内就能完成两排的拣货效率最大化。为什么双列通道是核心因为几乎所有仓库的货架都是双列布局货架类型通道结构双列拣选适用性横梁式货架通道两侧各有1-2排★★★★★阁楼货架通道两侧各有库位★★★★★驶入式货架通道深处多排两侧取货★★★★☆后推式货架通道两侧各有库位★★★★★流利式货架通道一侧进货一侧出货★★★☆☆可以说双列通道的路径优化覆盖了90%以上的仓库场景。单列蛇形只是基础双列交叉合并才是真正的效率提升点。效率提升多少我算了一笔账普通路径行走距离 ≈ 排数 × 列数 × 2蛇形路径行走距离 ≈ 排数 × 列数 × 1.1效率提升约40-50%。这意味着如果拣货员原来每天走2万步优化后只需要走1万步左右。核心逻辑的Java实现蛇形算法的核心逻辑并不复杂用Java实现大概这样的思路单列蛇形intdirectionFlag1;// 1正序, -1倒序introuteNo0;for(ListLocationlineLocations:byLine.values()){// 偶数排反转列表if(directionFlag-1){Collections.reverse(lineLocations);}SetIntegercolsnewHashSet();for(Locationloc:lineLocations){if(cols.contains(loc.getColumn())){loc.setRouteNo(routeNo);// 同列共享动线号}else{routeNo;loc.setRouteNo(routeNo);cols.add(loc.getColumn());}}directionFlag*-1;// 切换方向}双列交叉合并// 前排和后排按列交叉合并ListLocationmergeInterleave(ListLocationfrontRow,ListLocationbackRow){ListLocationresultnewArrayList();// 按列分组MapInteger,ListLocationfrontByColgroupByColumn(frontRow);MapInteger,ListLocationbackByColgroupByColumn(backRow);// 交叉合并前排列1 → 后排列1 → 前排列2 → 后排列2for(Integercol:allColumns){result.addAll(frontByCol.getOrDefault(col,emptyList()));result.addAll(backByCol.getOrDefault(col,emptyList()));}returnresult;}关键点Collections.reverse实现偶数排倒序HashSet记录已分配动线号的列实现同列共享directionFlag * -1每排切换方向双列通道时两排同向处理后交叉合并这就是全部核心逻辑。简单到只有几十行代码但它解决了拣货效率的核心问题。为什么这个设计在当时是最优的早期前人设计这个算法时面临几个约束硬件条件早期的RF手持终端性能有限不支持复杂的实时计算业务特点库位相对固定不需要频繁调整团队能力简单算法更容易维护和交接在这些约束下静态预计算的蛇形算法是最优选择算法简单容易理解和维护计算一次长期有效不依赖实时计算对硬件要求低六、架构思考10多年积累的设计智慧我了解了一些行业内的WMS系统发现路径优化这块大家的做法各不相同维度一些WMS我们这套系统路径算法无优化蛇形走位 权重编码动线管理无独立管理拣货动线 盘点动线独立管理特殊场景不支持阁楼货架、越库区、待报废区生成方式手动配置自动计算 手动微调这套系统从早期就开始实现蛇形走位算法经过10多年的迭代不断优化和完善。这种持续积累是我们这个团队的优势。为什么说简单才是最难的设计蛇形算法的核心逻辑只有几行代码奇数排从左到右 偶数排从右到左但就是这几行代码解决了拣货效率的核心问题。复杂的技术不难难的是用简单的技术解决复杂的问题。这套系统的设计智慧在于它没有追求高大上的技术方案而是用最简单、最可靠的方式解决了业务问题。这种简单不是一开始就有的而是10多年迭代中不断打磨出来的。静态预计算的设计权衡我分析这套系统的动线号生成发现一个设计特点动线号是静态预计算的不是实时计算的。也就是说库位创建时就确定了动线号拣货时直接读取使用。这个设计有它的智慧1. 简单可靠— 算法在后台运行不影响拣货性能2. 易于维护— 动线号存储在数据库可以查看、修改3. 支持离线— 即使网络不好RF终端也能读取动线号4. 业务适配— 库位相对固定的企业预计算完全满足需求5. 性能优异— 拣货员扫描库位时系统直接返回动线号响应速度极快这套设计是10多年业务积累的产物。它不是最先进的技术方案但它是最适合我们业务场景的方案。数据库设计的一个原则这次分析让我想到一个数据库设计原则能离线计算的不要在线计算能预计算的不要实时计算。动线号就是一个典型例子。它在库位创建时计算一次存储在数据库中拣货时直接读取。这个设计减少了拣货时的计算开销简化了RF终端的实现支持离线场景下的路径推荐如果当初选择实时计算每次拣货都要重新排序性能和复杂度都会成倍增加。七、未来可能的演进方向随着业务发展这套系统可能会有新的演进方向。我梳理了几个可能的方向1. 动态动线调整场景如果未来仓库布局频繁调整静态预计算可能不够灵活。可能的方向增加动线号版本概念支持多版本共存库位调整时自动触发动线号重新计算支持按区域、按类型独立计算2. 智能路径推荐场景如果业务需要更精细的路径优化。可能的方向结合订单波次动态生成拣货路径考虑库位之间的距离权重支持多拣货员协同作业3. 状态管理演进场景库位有多个状态字段管理锁定状态。可能的方向用位运算合并状态字段减少数据库字段数量简化状态查询逻辑但这些演进是否需要做取决于业务需求。当前系统运行稳定演进应该是业务驱动的而不是技术驱动的。给同行的几个提醒基于这次分析我总结了几点经验给同样在做WMS系统的朋友参考1. 动线号必须有重新计算的入口库位调整后动线号会错乱。系统必须提供重新计算动线号的功能否则拣货路径会出问题。2. 蛇形算法适合库位固定的场景如果库位每天都在变静态预计算可能不够灵活。这时候要考虑实时计算方案或者支持动线号版本管理。3. 权重系数要根据实际场景调整阁楼货架的权重编码比如1层列号×5这个系数要根据实际楼层间距调整不能照搬。不同仓库的物理结构不同系数也要不同。4. 拣货动线和盘点动线要分开管理拣货是选择性遍历只拣需要的SKU盘点是全量遍历所有库位都要扫。两者的优化目标不同动线号应该独立管理。八、AI辅助开发的体会这次用AI分析代码我有几点体会AI做得到的快速扫描1000多行代码几分钟就扫完了模式识别自动发现代码结构、调用关系结构梳理生成依赖分析、演进历程历史追溯快速查看提交记录理解迭代过程AI做不到的理解业务意图AI知道代码是什么不知道为什么判断设计合理性AI能指出代码特征不能判断这个设计是否合理评估全局影响AI只看局部不知道改动会影响什么理解历史背景AI不知道这个设计是在什么约束下做出的最佳实践AI做分析人做决策。AI帮我识别了代码结构但为什么要这样设计需要我深入业务去理解。AI帮我梳理了调用关系但要不要调整取决于业务优先级。作为架构师我的价值不是发现代码特征——AI比我做得更快更好。我的价值是理解业务、权衡取舍、做出决策。九、总结这次用AI分析WMS系统让我重新审视了一些理所当然的设计10多年积累的价值这套系统能稳定运行10多年不是因为某个天才设计而是因为10多年的持续积累简单算法的价值蛇形走位不复杂但效果明显静态 vs 动态的权衡预计算简单可靠适合库位固定的场景AI辅助的边界AI是分析工具不是决策者技术选型的本质是tradeoff。没有完美的方案只有适合场景的方案。对于这套WMS系统蛇形走位是一个务实的选择简单、有效、可维护。它经过10多年的业务验证至今仍在发挥作用。作为20年的老兵我越来越觉得我的价值不是写代码——AI比我写得更快。我的价值是读懂前人的设计、理解业务的本质、做出正确的权衡。好的架构不是一蹴而就的而是在业务迭代中不断演进的。我们要做的是在理解前人设计意图的基础上继续向前走。这才是架构至善之路的真正含义。下一篇预告下一篇聊聊WMS库位管理的另一个话题库位编码设计。一个编码如何承载一个仓库的空间信息为什么编码即坐标是一个好的设计欢迎关注持续更新。