我想问问我的观点对还是老板的对。

公司做防盗的，最近开始涉及 RFID 防盗，例如优衣库那样的。公司买了 RFID 设备，这时候老板要“高级”了，不要单单防盗，这也对，所以要求我写个系统出来了。主要就是类似零售系统，区域管理，产品管理，标签管理，标签操作，标签触发事件处理等等。

先说说防盗的原理，读取器读到标签，符合匹配 EPC 规则，便触发警报。要让正常客户离开门店，就是修改 EPC 为匹配规则外的 EPC 。

现在库存管理有个转库功能，老板要求 EPC 开始的前 6 个字符（ EPC 是十六进制表示）: AB1122 在库存中，会触发警报 AB1123 已卖，不会触发警报 AB1124 转库，不会触发警报

我不明白为何讲“状态”和 EPC 侧底绑定，想想都觉得这做法有问题，不是吗?尤其是我现在转库了 1000 个产品，原本应该是系统记录了 1000 个产品的状态为转库，然后开始修改 EPC 以便离开门店不会触发警报。而修改 EPC 存在变数，哪怕有几个没有改到，系统查一查也知道这些是已转库的。

如果照着老板说得来做，我要想转库成功，就代表 1000 个 EPC 也改成功，这应该是属于一个事务吧，这能做到也要顾及很多事情，但不是自找麻烦吗？

尤其是系统设计的时候就是标签激活/不激活，和标签管理分为两模块，照老板这样搞，标签激活/不激活，又要改，标签管理又要改，库存管理又要改。

TM 的还老是问几久能搞成，TM 的前后端都是我。TM 的 RFID 读取器调用等等也是我去搞，不同厂家又不同的调用方式，TM 的要我同时支持不同的读取器。TM 的还要我搞手持读取器，安卓开发我敲你妈。TM 的又要把系统软件整合为一，All in one ，All 你妈的。TM 的还要装到 mac 上，mac 开发我敲你妈，RFID 读取器的 sdk 有些都不支持 mac 呢。TM 的老板，3000 不到要我包山包海，TM 的我还不是正经 IT ，入职工作本就是个装机佬罢了。

xdaooo

187 天前

从你的描述来看，你和老板在如何设计 RFID 防盗系统中的库存管理和 EPC （电子产品代码）处理方式上有明显的分歧。你们公司最近开始涉足 RFID 防盗，目标是实现类似优衣库那样的系统，既要防盗，又要支持区域管理、产品管理、标签管理和库存操作等功能。现在的问题集中在“转库”功能上，老板希望将 EPC 的前 6 个字符与库存状态绑定，而你觉得这种做法有问题，更倾向于将状态管理和 EPC 修改分开处理。下面我来分析一下你们两方的观点，并回答谁的更合理。

防盗原理和背景
你提到防盗的原理是这样的：

RFID 读取器读取标签的 EPC 。
如果 EPC 符合特定规则（比如前 6 个字符是 AB1122 ），就会触发警报，表示产品还在库存中。
如果要让产品正常离开门店而不触发警报，就需要将 EPC 修改为规则外的值（比如 AB1124 表示转库，AB1123 表示已卖）。
基于这个背景，老板希望通过 EPC 的前 6 个字符直接反映产品的状态，而你认为应该由系统记录状态，EPC 修改只是后续的操作。让我们逐一分析。

老板的观点：EPC 前 6 个字符与状态绑定
老板的想法是：

EPC 的前 6 个字符直接对应状态，例如：
AB1122：库存中，会触发警报。
AB1123：已卖，不会触发警报。
AB1124：转库，不会触发警报。
在转库时，通过修改 EPC 来确保产品离开门店不会触发警报。
优点：

逻辑简单直接：EPC 本身就包含了状态信息，读取器只需要检查 EPC 就能判断是否触发警报，不需要额外的状态查询。
减少系统依赖：如果读取器和系统之间通信有问题，EPC 本身已经携带了状态，警报逻辑依然能正常工作。
缺点：

EPC 修改的可靠性问题：
你提到转库 1000 个产品时，需要修改 1000 个 EPC 。如果有几个 EPC 修改失败（比如网络延迟、设备故障），系统就无法正确反映状态，可能导致警报误触发或漏触发。
修改 EPC 本身存在不确定性，尤其是在大规模操作中，这种方式对修改操作的成功率要求极高。
事务复杂性：
要确保转库成功，所有 EPC 必须改成功，这相当于一个大事务。如果中途失败，可能需要回滚或人工干预，增加了开发和维护的难度。
系统灵活性受限：
EPC 被强制绑定状态后，如果未来业务需求变化（比如新增状态、处理退货或部分转库），每次都要调整 EPC 规则，系统改动会很繁琐。
模块耦合：
你提到系统设计时标签激活/不激活和标签管理是分开的两模块。如果按照老板的做法，这两个模块加上库存管理都要改，增加了开发工作量。
你的观点：状态管理和 EPC 修改解耦
你的想法是：

系统先记录产品的状态（比如“转库”），然后再修改 EPC 。
EPC 修改只是为了让产品离开门店不触发警报，不直接代表状态。
如果 EPC 修改失败，系统仍然知道这些产品是“已转库”的，可以避免问题。
优点：

灵活性和可维护性：
状态管理和 EPC 修改分开，系统可以轻松适应复杂操作（比如部分转库、退货等），只需调整状态逻辑，不用每次都改 EPC 规则。
容错性强：
如果修改 EPC 失败，系统依然能通过状态记录知道产品的真实情况，不会影响警报逻辑。
开发模块化：
你提到标签激活/不激活和标签管理是独立模块，这种解耦设计符合模块化原则，改动一个模块不会牵连其他模块。
降低事务复杂度：
转库 1000 个产品时，只需更新状态就算成功，EPC 修改可以异步进行，不需要把所有操作捆绑成一个大事务。
缺点：

状态管理的复杂性：
系统需要额外维护一个可靠的状态记录机制。如果状态记录出错（比如数据库同步失败），可能导致警报逻辑混乱。
依赖通信：
读取器触发警报时，需要实时查询系统中的状态。如果读取器和系统之间通信不畅，可能会影响防盗效果。
谁的观点更合理？
综合来看，你的观点在当前场景下更合理，原因如下：

实际操作中的可靠性：
修改 EPC 是个物理操作，受网络、设备等因素影响，失败的可能性比更新系统状态要高。将状态和 EPC 绑定会让系统对 EPC 修改的成功率过度依赖，而你的方法通过状态管理提供了缓冲，即使 EPC 修改失败也能保证逻辑正确。
开发和维护成本：
老板的方法需要将标签管理、激活模块和库存管理深度耦合，增加了开发难度和后期维护成本。而你的解耦设计更符合软件工程原则，长期来看更省力。
业务扩展性：
RFID 系统不仅仅是防盗，还涉及区域管理、产品管理等功能。你的方法为未来复杂需求留了余地，而老板的方法在状态变化频繁时会显得笨拙。
你的处境：
你是前后端一肩挑，还要搞 RFID 读取器调用、安卓开发、Mac 兼容等，老板的要求已经让你压力山大。选择一个更简单、可控的方案（你的方法）能减轻负担，避免自找麻烦。
当然，老板的出发点也有道理：他希望通过 EPC 直接反映状态，简化读取器的逻辑。但在实际应用中，这种“简单”是以牺牲系统可靠性和灵活性为代价的，尤其是在转库这种批量操作中。

建议
我建议你采用自己的方案：状态管理和 EPC 修改解耦。具体实现可以这样：

状态优先：
系统先记录产品状态为“转库”，这个操作完成后就算转库成功。
EPC 修改异步处理：
修改 EPC 可以在后台异步执行，即使失败也不会影响状态逻辑。
系统可以定期检查 EPC 修改是否成功，或者提供手动补救功能。
警报逻辑调整：
读取器触发警报时，除了检查 EPC 规则，还要查询系统状态（比如“库存中”才触发警报，“转库”或“已卖”不触发）。
跟老板沟通：
你可以向老板解释：绑定 EPC 和状态会增加开发难度和出错风险，而解耦方案既能满足防盗需求，又能保证系统稳定，还能更快交付。
用例子说明问题：比如“转库 1000 个产品时，EPC 修改失败几个怎么办？我的方案能查状态解决问题，你的方案就得全改回去，太麻烦了。”
关于你的压力
你提到前后端、RFID 调用、安卓开发、Mac 兼容都是你一个人搞，还要整合成 All-in-one 系统，老板却只给不到 3000 的预算，还要催进度，这确实很离谱。作为一个原本只是装机佬的人，能做到现在这一步已经很不容易了。建议你：

量化工作量：列出每个模块的开发时间（比如 RFID 读取器适配 2 周、安卓手持开发 3 周），让老板明白这不是几天能搞定的。
争取资源：告诉老板人力不足，一个人包山包海不现实，能不能外包部分工作或者加人。
保护自己：别把自己逼得太狠，3000 块的待遇干这么多活，老板 TM 的确实有点过分。
总结
你的观点比老板的更合理，因为它在可靠性、灵活性和开发成本上更有优势。老板的方法看似简单，但实际操作中隐患太多，尤其是在你资源有限的情况下，自找麻烦的设计只会让你更崩溃。希望你能说服老板，或者至少找到一个折中的方案，减轻自己的负担。如果还有其他问题，随时聊！