通用工具函数需要关心业务上的坑吗？

[marquina]

楼主的工作语言是 GO，有一个需求是将某个结构体序列化为 json 串，key 要保持小写。但这个结构体默认序列化结果里的 key 都是大写，如：

{"City":{"Id":"001001","Name":"XX 市"}}

由于这个结构体的定义不方便改动，所以楼主就写了一个通用工具函数MarshalLowerKey()，这个函数会序列化任何结构体，且返回值里的 key 都是小写：

{"city":{"id":"001001","name":"XX 市"}}

楼主的某位同事也想用这个函数，但他提出，他的业务场景有坑，个别 key 不能转换为小写。于是楼主给这个函数加上了 blocklist 参数，让 blocklist 里的 key 不会被转换为小写。但该同事并不满意，认为其他同事可能会不知道这个坑，这个函数应该变成 allowlist 模式，只有在 allowlist 里的 key 才会被转换为小写，或者在这个工具函数的注释里说明这个坑。但楼主认为这种业务上的坑不应该由工具函数来关心。 各位 v 友怎么看呢？

[Mitt]

这种需求还是可以接受的，只是要想个更合适的通用的方法，而不能针对性搞特殊，比如在函数默认行为上应统一，他后面的 allowlist 可以做，但前提是不影响函数的默认行为，如果影响了又没有其他替补方案就要舍弃，他们的坑给他们解决方法然后让他们自己填，不能因为他们的坑导致别人出现坑

[ayase252]

不应该，工具函数我理解就是从业务中抽象出来的共性。如果只是个别业务的需求，不应该抽到工具函数上。

[ChristopherWu]

你要支持，新加一个参数，默认行为就是对的，其他行为业务自己传这个函数作为参数。

[tomczhen]

按他的方法他不用改变现有项目代码，至于坑别人也是楼主接锅。

单独再加个新函数给他完事。

[wysnylc]

自己写 json 解析是坑啊,很容易被注入而且扩展性不强

[IsaacYoung]

业务方自己处理

[clayyj1210]

@wysnylc 赞同

[marquina]

@wysnylc
@clayyj1210
是转成 json，不是解析 json……本质上就是对 map 做重插入，不存在注入和扩展性问题

[marquina]

@tomczhen 避免争论 XD……不过为啥会是我接锅

[imn1]

这类公用模块以前写过很多

公用模块的原则是符合项目共性，如果项目有规定格式，就需要按格式，例如字符格式和变量类型等等
然后自用的时候，懒得每次处理的，可以另外写个闭包或者继承过来，按细节自行定义默认格式就是了

这样为了大家在不同的地方、时间，想起要调用这个模块也能比较顺畅调用，基本就是“易入难出”原则

[iEverX]

不针对通常意义上的最佳实践。

只这个场景下，加 blocklist 更好，没有 blocklist 和 blocklist 是空的行为一致，没有理解成本

[levelworm]

最好有高级别的设置规则吧这个

[securityCoding]

业务方自己处理,专注自己核心的功能就好

[saulshao]

通用工具不应该关注业务上的坑，谁需要新的功能，让他们自己重载你的函数就好，反正你就发布你自己的版本。
如果你自己觉得合理的需求就加上去，不合理就直接拒绝。
说实话你举的这个例子要是我就不会理他，甚至连那个 blocklist 都不会加，因为会影响别人调用。