当前情况
SDK之殇
目前ABC客户端有大量的功能是通过接入sdk的方式实现的, 同时可以预见的是, 在未来, 接入sdk的数量还会跟业务一样增长, 会让我们的ABC客户端变得更加臃肿. 这些sdk中, 存在了大量我们客户端不适合也不会用到的功能.
同时, 这些sdk中, 存在了错综复杂的依赖关系, 这些关系是很强的版本依赖关系. 每次SDK升级, 往往伴随着连带的sdk升级, 接入方每次都需要投入人力成本进行维护, 从而造成了大量的人力浪费.性能之惑
ABC客户端无论是CPU/内存/流量使用都是购物类app中最大的. 弱网体验也不好, 甚至不如手淘. 随之而来的就是响应慢, 卡顿, 易崩溃等问题. 我们的安装包也随着不断的接入各种SDK而慢慢变大, 可以跟一款主流游戏一较高下了.研发之困
流程冗长. 无论大小, 无论业务是否稳定, 我们都采用了需求-交互-开发-测试-灰度-发布 这统一的流程. 面对多变的产品, 我们灵活度不够, 面对小的需求, 我们的流程又显的过长.
关于SDK
SDK中有大量的代码我们不会用.
SDK是一个很好的提升总体研发效率的手段. 但是滥用SDK, 就会造成目前我们遇到的种种问题. 在我们接入的SDK中, 有很大一部分功能是我们用不到的, 里面有很大一部分的代码是我们的业务不会走到的. 但是这些功能依然占据了我们的安装包, 慢慢的让ABC变得臃肿和缓慢.让人头痛的依赖关系.
我们接入的SDK并非独立的存在, 很多时候, SDK之间有着千丝万缕的依赖关系. 比如我们因为某个视频业务需要接入视频模块, 发现其依赖于底层的webview模块, 如果接入了webview模块, 所有依赖于webview的模块都存在回归风险.
接入了一个sdk就意味着打开了一个潘多拉盒子.不胜其扰的测试需求.
场景一:
"今天我们更新了一个版本, 修正了一个bug, 影响很大. 你们回归一下"
"重点是什么?"
"都看一下, 影响很大"
"上次也是这么说的啊..."
"你就回归吧, 反正很大..."
场景二:
"亲, 在吗? 今天我们发现了一个sdk的bug, 你看看?"
"你们用的sdk版本是多少?"
"1.1.0"
"我们都1.1.2了, 你们先升上去看看吧"
"亲, 你确定升级就能解决?"
"恩, 你这个bug我怀疑跟我们之前的那个是同一个问题, 你先升上去看看."
如有雷同, 不胜荣幸
关于性能
从当前收集到的数据来看, ABC在几个购物类应用的横向比较中属于资源使用非常重的.
一个主要的原因是无线方面的性能的关注点不够, 针对业务的解决方案偏中重资源消耗. 比如: 对于外部库的引入不节制, 使用部分, 或小部分功能也引入. 对于图片大小, 清晰度没有实验意识, 为了满足产品希望无条件的使用大图.
现在的App就像是一个房间, 每个人都想把自己的东西装进入, 但是不关心这个房间还能有多少空间.
同时, 翻看我们启动过程, 其中, 特殊的业务逻辑, 配置拉取, 预加载等等. 使得我们的启动愈发缓慢.
执着于加法, 忘记了减法
关于开发流程
每个月的移动端发版都是一个痛苦的过程. 问题的实质就在于反馈过长. 我们绝大多数的业务, 使用了瀑布式的开发模式
需求 -> 交互 -> 开发 -> 测试.
如果每个流程一周, 需要一个月
一个再小的业务需求, 都需要4个以上的人参与, 每一个环节进入到下游都需要巨大的沟通成本
为了应对沟通问题, 我们有我们的项目室. 不过, 仍然有很多人倾向于在自己的工位上免打扰的完成工作.
确保这个流程正常运转的, 是我们的评审制度.
需求(需求评审) -> 交互(交互评审) -> 开发(开发Review) -> 测试(用例评审 + 灰度)
所有这些流程, 大多会在一个月甚至更短的时间完成. 而且还不可避免的涉及到了返工:
- 如果开发过程中发现交互不完备, 需要改交互
- 如果开发过程中发现需求有纰漏, 需要改需求
- 如果需求点无法实现, 需要改开发方案
同时, 当以上情况发生时, 很难保证对应的评审会有效的召开, 为质量埋下了隐患.
几点思考
- 明确SDK的接入标准, 构建缓冲层.
作为SDK的接入方, 直接介入某一个SDK是非常危险的事情. 评估工作量, 依赖关系, SDK的成熟度, 以及对于应用整体性能影响是必要的第一步. 而且, 在实施接入的过程中, 构建一个wrapper来封装接入的SDK. 使得SDK和接入应用之间有一个"缓冲层", 这样可以有效减少SDK升级, 变动, 功能不完善等造成的影响.
- SDK的设计尽量单一化, 尽量减少SDK之间的依赖
如果SDK中有针对接入方的逻辑, 那么这部分必然是浪费的. 同是, SDK间依赖关系也为今后的质量买下了隐患. 这就需要在SDK设计上, 做到单一化. 应该 __严格禁止 __业务逻辑和基础功能混合在一起的SDK.
- SDK的测试全面化
以某一接入方为样本进行测试, 就存在了其他接入方的风险. 而修改内容不是每个接入方都清楚, 这就造成了测试实施中沟通成本大, 无谓测试增多. 理想方式, 是SDK升级的测试, 覆盖所有接入方. 同时, 如果做到了SDK单一化, 那么SDK的测试成本也会大大降低.
- 定期的性能专项测试
相比很多互联网公司/团队都有无线方面的专项测试团队, 我们在这方面的投入真的不多. 无论是流程还是投入人员都无法保证. 性能体验需要一定的专注和坚持, 在保证人员投入的同时, 更加频繁的定期进行性能专项测试活动尤为必要.
- 完善现有的评审制度.
需求评审, 交互评审, 开发方案的评审, 测试用力的评审, 都需要有明确的CheckList和准入标准, 能够明确的帮助团队识别出来当前处于哪个阶段. 尽力避免一句话需求, 不完整的交互, 不完善的开发方案, 有疏漏的测试.
- 发版计划中, 只包含"成熟度高" 的需求.
我们完整的一个流程既然很长, 而且还涉及到了反复的修改. 那么在制定发版计划的时候(也就是PM收集需求的时候), 只采用已经经过交互评审的需求, 这样会大大减少反复修改需求造成的问题.
- 采取更轻的项目室制度.
在规定时间内, 产品, 交互, 开发, 测试都在一个地方办公. 在项目起初就制度化.
- 尝试跨职能的小团队
减少沟通成本, 有效的控制产品的开发过程. 职能团队在控制单品的质量方面更加突出, 不过我们目前的团队个人无论经验还是能力, 都属于行业中上, 所以有效的沟通, 培养团队默契对于提升效率更加重要. 同时, 针对新业务, 尚且处于摸索阶段的新功能, 跨职能团队能给出更快的响应速度和更独立的品质控制.
