搬砖方法论:关于添加全局性API的思考

在开发中会遇到这种情况

  • 功能模块负责人,会有些经常使用的功能,封装一下放到公共库
  • 发现一个不错的功能组件,放到项目公共库中
  • 感觉原来的API不好(命名,参数太多等等),自己封装一个放入公共库
  • 现有的API只能满足自己80%的需求,自己封装一个能满足100%需求的API放入公共库中。

如果你是整个系统的维护者并且遇到了这种或者类似的情形,那么就要注意了,这是一种 Code Smell。你所维护的系统可能将要变的腐败或者已经腐败。

出现以上情况的操作者,他们的初衷是为了使用更方便,但操作者很难从全局的角度或者有精力来考虑这么做所带来的其他影响。

添加全局性API(组件或者其他全局性功能)会有如下方面的考虑

  • 是否足够抽象,满足需求但不局限于需求
  • API命名及参数的合理性
  • 是否考虑兼容旧版本
  • 是否有迭代API的计划(需要专人负责)

再说说游戏开发中,系统开发的现状:

游戏开发中的系统主要以UI的形式展现,使用语言方面以Lua为主导(2021年)。UI以上手快,要求低等特点,常常是入行第一个接触到的技能。人员比例新人居多,慢慢变成供新人练手或者选拔人员的地方。也就是说,写系统的人员变动会相对较大,代码质量常常差距很大,再加上系统在游戏中的占比,基于以上的原因,系统的维护难度相对于其他会更加困难。

所以,在模块负责人准备提交API时,多数不会考虑后续的迭代维护问题,因为可能在后面的工作安排中,模块负责人已经更换。目前提交API仅仅是满足自己的需求而非全局性。还有就是能够封装不代表它足够抽象,或者说不一定能够达到提升到全局API的抽象级别。

反之如果模块负责人不变,后续真的会有人力来维护迭代这个API吗?我表示怀疑。
第一,经过QA测过的功能,为了迭代API要重新测试涉及的模块,能否有足够的优先级来做这些事。
第二,以Lua语言为主的环境下,谁又能确保删除陈旧的API不会有其他问题,这显然是一个非常担责任的事情,对应手游这种要求快速产出的环境,这种费力不讨好的事又会有几个人会去做呢?

浮躁的年代里,代码品质是不重要的,重要的是功能的实现。比如TA做个炫酷的效果,战斗展示富有节奏的打斗过程,不管从个人积累还是获得薪水上都好于这个。而且还有一点是,如果你写的代码,足够清晰简单,扩展性好,bug少,那么你就是一个闲人,并且还是一个可以随意被代替的人。
基于以上种种,切切实实能够去考虑并且去实施那些注意事项的人会有多少呢,我想不会很多,或者没有。

所以笔者是非常反对未经审核,就向公共库中提交API的这种行为。为解决某个问题需要带来全局性变更的同时,一定要考虑会带来哪些其他的影响,当然这需要时间,所以更改一定是经过评估协商后的结果,因为提交后,可能在很长一段时间就不会有人或者能够去更改它了。


更多文章详见主页:www.aihailan.com

发表评论