软件开发中“做完”和“做好”之间的那条线

功能上线了，但用户不用

一个功能从需求到上线，经历了需求评审、设计、开发、测试、验收，所有流程都走完了。上线一周后，开发人员问业务部门的用户：“功能用得怎么样？”用户说：“还行。”又过了一个月，开发人员发现这个功能的使用量远低于预期。去问用户，用户才说实话：“操作太麻烦了，要点好几下才能到我要的界面，后来就不用了。”

功能做完了，验收也通过了，但用户不用。这在软件开发中并不少见。“做完”指的是功能按需求文档实现了，该有的按钮都有，该走的流程都走得通。“做好”指的是用户愿意用、用得顺手、能解决实际问题。两者的差距，往往不在代码质量上，而在对用户真实使用场景的理解上。

需求文档写不出来的东西

需求文档能写清楚的是功能逻辑：点击这个按钮，弹出那个页面，输入这些字段，保存后更新那个状态。但需求文档写不出来的是用户在使用那一刻的心理状态：他是在什么情况下打开这个功能的？是忙的时候还是闲的时候？是每天用还是偶尔用？他更关心速度还是更关心准确性？他会不会因为操作步骤多一步就放弃？

这些东西，不是业务部门故意不写，是写不出来。它们存在于用户的日常工作中，需要开发人员去看、去问、去体验。开发人员坐在工位上对着需求文档写代码，和到业务现场看用户怎么工作，写出来的东西是不一样的。

异常情况才是真正的工作量

正常流程的代码量通常只占一小部分。大部分代码是在处理异常：网络超时怎么办？数据格式不对怎么办？用户中途退出怎么办？并发请求怎么处理？权限不够怎么提示？这些异常情况在需求文档里往往一笔带过，甚至根本不提。开发人员如果只按“正常流程”写代码，上线后就会发现各种边界条件下系统崩溃、数据错乱、用户茫然。

异常处理的工作量取决于系统的使用场景。内部管理系统，用户少、环境可控，异常处理可以相对简化。面向公众的系统，用户多、环境复杂，异常处理可能要占到开发工作量的六七成。这个比例如果估算不准，项目就会延期。

技术债不是“以后再说”就能解决的

项目赶进度，先实现功能再说。代码写得不优雅，测试覆盖不充分，架构设计临时凑合。所有人都知道有问题，但都说“以后再来优化”。以后真的会来吗？通常不会。下一个项目已经开始，没有人会回头优化一个“已经能用”的系统。技术债就这样一天天累积，直到系统改不动、跑不动、没人敢动。

技术债可以欠，但要记账。哪些地方的代码是临时方案？计划什么时候重构？预期投入多少人天？这笔账如果不记，临时方案就变成了永久方案。

开发人员需要懂业务，业务人员需要懂逻辑

开发人员不懂业务，做出来的东西逻辑对不上实际工作。业务人员不懂技术逻辑，提的需求在技术上不可行或者成本极高。双方都不愿意跨出一步，项目就卡在中间。

比较有效的做法是：开发人员定期去业务部门跟岗，看用户每天在做什么、烦什么。业务人员在提需求时，同步说明“这个需求解决什么问题”“现在的临时方案是什么”。双方有了共同语言，沟通成本才能降下来。

测试不只是找bug

传统观念里，测试就是“看功能有没有按需求实现”。但需求本身可能有漏洞，用户的使用方式可能超出需求范围。好的测试应该在验证功能之外，还能发现需求的盲区、设计的缺陷、用户体验的问题。

这要求测试人员不仅懂测试方法，还要懂业务场景。他们能在测试过程中问出开发人员和业务人员都没想过的问题：“如果用户在这里输入了一个特殊字符会怎样？”“如果这个页面加载很慢用户会怎么操作？”

新易编码在开发流程中的位置

新易编码不是开发工具，它解决的是开发过程中一个具体的问题：编码规则的频繁变更对业务系统的影响。

传统模式下，物料编码规则变了，需要改ERP代码、改接口、改报表，开发排期、测试、上线，周期长、成本高。新易编码把编码规则从业务系统中抽离出来，独立配置、独立维护。规则变了，不需要改业务系统代码，不需要走完整的上线流程。开发人员不用再为编码规则的变更反复改代码、反复测试。

这意味着开发团队可以把精力放在核心业务逻辑上，编码规则的维护交给业务人员自己。

几个容易被忽略的实践

写代码之前先写测试用例。 不是“写完代码再补测试”，而是先想清楚“怎么证明这个功能是对的”，把测试用例写出来，再写代码。这样写出来的代码可测性更高，边界条件也更容易想清楚。

代码审查不是为了找茬。 代码审查的目的是发现潜在问题、分享知识、保持代码风格一致。审查时提出的问题，应该是“这个地方可能有风险”，而不是“你怎么这么写”。

日志不是为了调试，是为了定位问题。 系统上线后，开发人员看不到运行时的状态。日志是唯一的窗口。日志应该记录关键操作、异常信息、耗时数据。日志不全，出了问题就只能靠猜。

文档要写“为什么”，不只是“是什么”。 代码本身已经说明了“是什么”，文档应该说明“为什么这么做”。当初有哪些方案可选？为什么选了现在这个？有哪些限制条件？这些信息代码表达不了，但后人维护时最需要。

结语

软件开发不只是写代码。理解用户需求、处理异常情况、管理技术债务、跨部门沟通，这些工作加在一起，才构成一个完整的开发过程。代码写完了，不叫做完；用户用得顺，才叫做好。

新易编码在这个流程中解决的是一个具体的重复性问题：编码规则变更对开发工作的干扰。把编码规则抽离出去，开发团队就能少一些“改编码规则、测编码规则、上线编码规则”的重复劳动，把精力放在真正需要开发的地方。

 

如果您有物料编码相关的问题，欢迎咨询新易物料编码