这是一个创建于 1545 天前的主题，其中的信息可能已经有所发展或是发生改变。
楼主的工作语言是 GO，有一个需求是将某个结构体序列化为 json 串，key 要保持小写。但这个结构体默认序列化结果里的 key 都是大写，如：
{"City":{"Id":"001001","Name":"XX 市"}}
由于这个结构体的定义不方便改动，所以楼主就写了一个通用工具函数MarshalLowerKey()，这个函数会序列化任何结构体，且返回值里的 key 都是小写：
{"city":{"id":"001001","name":"XX 市"}}
楼主的某位同事也想用这个函数，但他提出，他的业务场景有坑，个别 key 不能转换为小写。于是楼主给这个函数加上了 blocklist 参数，让 blocklist 里的 key 不会被转换为小写。但该同事并不满意，认为其他同事可能会不知道这个坑，这个函数应该变成 allowlist 模式，只有在 allowlist 里的 key 才会被转换为小写，或者在这个工具函数的注释里说明这个坑。但楼主认为这种业务上的坑不应该由工具函数来关心。 各位 v 友怎么看呢？
 |
1
Mitt 2020-08-29 17:49:13 +08:00 via iPhone
这种需求还是可以接受的，只是要想个更合适的通用的方法，而不能针对性搞特殊，比如在函数默认行为上应统一，他后面的 allowlist 可以做，但前提是不影响函数的默认行为，如果影响了又没有其他替补方案就要舍弃，他们的坑给他们解决方法然后让他们自己填，不能因为他们的坑导致别人出现坑
|
 |
2
ayase252 2020-08-29 17:49:31 +08:00 via iPhone  1
不应该，工具函数我理解就是从业务中抽象出来的共性。如果只是个别业务的需求，不应该抽到工具函数上。
|
 |
3
ChristopherWu 2020-08-29 17:52:03 +08:00
你要支持，新加一个参数，默认行为就是对的，其他行为业务自己传这个函数作为参数。
|
 |
4
tomczhen 2020-08-29 18:03:40 +08:00 via Android
按他的方法他不用改变现有项目代码，至于坑别人也是楼主接锅。
单独再加个新函数给他完事。 |
 |
5
wysnylc 2020-08-29 18:06:03 +08:00
自己写 json 解析是坑啊,很容易被注入而且扩展性不强
|
 |
6
IsaacYoung 2020-08-29 18:10:26 +08:00 via iPhone
业务方自己处理
|
 |
7
clayyj1210 2020-08-29 18:28:47 +08:00
@wysnylc 赞同
|
 |
8
marquina OP |
 |
10
imn1 2020-08-29 22:14:04 +08:00
这类公用模块以前写过很多
公用模块的原则是符合项目共性，如果项目有规定格式，就需要按格式，例如字符格式和变量类型等等 然后自用的时候，懒得每次处理的，可以另外写个闭包或者继承过来，按细节自行定义默认格式就是了 这样为了大家在不同的地方、时间，想起要调用这个模块也能比较顺畅调用，基本就是“易入难出”原则 |
 |
11
iEverX 2020-08-30 00:17:55 +08:00
不针对通常意义上的最佳实践。
只这个场景下，加 blocklist 更好，没有 blocklist 和 blocklist 是空的行为一致，没有理解成本 |
 |
12
levelworm 2020-08-30 05:03:35 +08:00 via Android
最好有高级别的设置规则吧这个
|
 |
13
securityCoding 2020-08-30 11:11:30 +08:00
业务方自己处理,专注自己核心的功能就好
|
 |
14
saulshao 2020-08-31 06:13:05 +08:00
通用工具不应该关注业务上的坑，谁需要新的功能，让他们自己重载你的函数就好，反正你就发布你自己的版本。
如果你自己觉得合理的需求就加上去，不合理就直接拒绝。 说实话你举的这个例子要是我就不会理他，甚至连那个 blocklist 都不会加，因为会影响别人调用。 |
Select Language