没犯错的人受批评-代码亦如此

Posted 2022-04-26 wmalloc

忘记是高中哪个老师讲的一个道理, 可能是政治老师

"挨骂的都是没犯错的人"

原因很简单: 有一天, 班级上有几个同学逃课了. 这个老师在课堂上大发雷霆, 说了很多狠话, 最后冷静了下, 淡淡的说了上面那个极具哲理的话, 还说, 你们这些没有逃课的同学在这里挨骂, 真正逃课的人却没有挨骂. 从此印象极深.

虽然当时就知道这句话半对半错吧, 但是有很多事情总是掺杂了这个道理在里面

比如 假如最初, 大家都自觉买票乘车, 有一天,有个人故意逃票被发现了, 于是管理部门增加了一个检票的流程. 将所有人的出行成本增加了, 还不算增加的人力和设备开销

甚至可能还不能抵消逃票带来的损失, 但是你不得不这样做, 因为有人破坏规则了, 不受到惩罚的话, 情况会恶化, 当然最好的方式是各种技术保障手段, 增加流程只是最差的措施

这就是一个明显的, 没犯错的人承担了犯错人带来的后果.

 

当然,这是个技术博客, 自然要把话题绕到技术上来

 

有些接口的设计就充分的体现了这个 没犯错的人会受罪 的道理

比如有个接口, 需要判断角色是不是队伍的队长, 

设计接口的时候,如果光想着通用, 就会设计成这样:     Player.isTeamLeader(playerId) 

这个接口很奇怪. 我属于一个队伍, 但是判断队长的接口在我身上. 而不是在队伍逻辑上.(不是重点) 其次, 你搜索下整个项目,  发现绝大部分的代码是这样写的: mainPlayer.isTeamPlayer(mainPlayer.id)

一般来说. 绝大部分的逻辑都是判断主角自己是不是队长, 很少有逻辑是判断别人是不是队长. 即很少有这种逻辑: mainPlayer:isTeamLeader(otherPlayer.id)

所以, 大家会为这个"通用"的设计思路买单, 每个人都会在调用时, 多写一个看起来很蠢的参数, 这样反过来说明了, 这个接口, 根本不应该在玩家身上, 而是应该在一个TeamManager里面.

例子不是特别恰当, 接口的位置是更大的问题, 但是结合上面的例子, 应该明白, 这样的接口设计在代码中比比皆是,

没有考虑用户使用习惯, 没有拆分接口, 希望一个接口处理所有事情, 导致这个接口的使用必然是五花八门的, 参数链会因此变长, 变的难看, 你用几个, 我用几个, 不同组合不同花样, 反正加一个,设置好默认值不会影响其他人

但是你敢动一个试试?

 

所以, 路过这种接口, 请保重