【精品APP建设】之 如何保障产品质量

物竞天择 适者生存

于生物界，竞争之激烈，以至于落后者只有灭亡一途。
至于移动互联网产品，又何尝不是如此？优质的产品蒸蒸日上，落后的产品苟延残喘。
APP的建设越来注重「精品」二字，质量是产品的核心竞争力，是精品APP建设的重中之重，保障质量则是技术团队的核心任务。

那么今天，我们就来谈一谈“如何保障产品质量”？

一、什么是「产品质量」

正所谓“名不正则言不顺，言不顺则事不成”，在我们进入正题之前，有必要对于“产品质量”有一个统一的、清晰的认识。

产品质量是否指的是我的代码没有Bug呢？是否指的是我的功能已经完全符合PD需求呢？是否指的是我的界面与视觉稿一样一样呢？是，又不全是。

产品的质量，我认为应该放到更大的、更高的尺度下去观察、衡量，至少可以包括以下3个视角。

视角一：产品视角

• 功能是否完备，该有的功能点一个都不能少
• 细节是否到位，见微知著，小细节有大世界
• 视觉是否保真，作为一名客户端开发“一个像素都不能差”是基本的职业素养

视角二：研发视角

• 架构合理
• 代码简洁
• 扩展性好
• 可测性好
• 代码质量分高

视角三：用户视角

• 好用：满足需求
• 易用：交互合理
• 体验：运行流畅
• 耐用：功耗低、流量少

以上，特别要强调的是第三点：用户视角。必须时刻记住，无论我们身处什么角色，PD、开发、测试、运营，用户，只有用户才是我们一切工作的唯一出发点和终点，提升用户价值的工作才是有意义的工作

OK，入门结束，诸位是否已经了解了我的质量观了呢：）接下去，我们就来聊一聊如何保证产品质量。

二、如何保证产品质量

是不是要讲怎么做自测呢？有同学可能会问，是，又不全是；是不是要讲一些减少Bug的编程技巧呢？又有同学在嘀咕，是，又不全是；呵呵，是不是被楼主搞晕了呢？

自测的法门，多多益善，编程的技巧，亦是数不胜数，如此多的内容，楼主又能力有限，无法一一道来，今日楼主却另辟蹊径，从「务虚」和「务实」两方面来从粗浅讲一下自己对于如何保证产品质量的理解。

2.1 所谓「务虚」

「虚」并不是空无一物、忽悠骗人，恰恰相反，「虚」是指导思想、是大政方针，用时髦一点的话语说，就是“顶层设计”，是“实”的基础。

对于“虚”，可以分为以下几个角度来考虑：

• 道
• 术
• 势
• 心

「道」

“道”讲的是这件事的意义所在，远远的有一盏灯（产品质量）在指引着我们前进，我们呢，则要选择一条合适的路线（技术手段、流程手段，等），朝这个方向坚持不懈的前行。
产品质量是我们坚持的baseline，是我们做精品APP的基石。

「术」

“术”就是方法论，就是怎么具体可以从哪几个角度入手去做好质量工作，这里我简单提几个角度

• 基础
• 博学
• 跨界

基础，就是指要基础扎实。我们的日常工作中时时刻刻考验着基本功，举个栗子，经常会用的数字的各种处理，那么，BigDecimal的各种用法，例如：四舍五入、科学记数、去除尾零、精度控制，你是否可以随手拈来？又如时间的处理，各种时区的设置，例如：UTC与GMT之间的关系，你又是否已经了然于胸？又如静态类的使用你是否完全懂得其中的奥妙？如此种种，你又是否经常停下来求助于股沟君或者百度君呢？

可以这么说，日常工作中，对于编码效率影响最大的就是基本功，Bug中也有一大部分来自基础不扎实。那种似懂非懂或者只知其然而不知其所以然，是最要不得的，往往错了，还不知道是哪里错了。

如何提升基础，三大法宝：读书+阅读源码+多实践。读书泛指读纸质书和电子文档（如Android同学必修要读的Google官方文档，最好是看英文的，很多中文翻译的太差）；源码的阅读，看别的高手是如何写的，为什么这样写，学习其思想，学习其设计。人至“践”则无敌，多实战，在实战中获取经验，稳扎稳打。

博学，就是指要在自己的本职之外，适当了解上下游岗位的技能。全栈工程师现在非常时髦，并不是说一定要每个地方都非常精通，但是适当的理解，在做设计，架构的时候，能够旁征博引，做出来的东西会健壮，全面很多。
作为一名客户端开发，适当了解服务端同学的技术，例如：性能、并发、数据库，有助于在沟通时站在对方的角度考虑问题，做到相向而行，既提高了沟通效率又可以把接口、数据结构、幂等性这些涉及双方的内容定义得更合理完善，尤其是可以减少盲区、减少误解；作为一名测试，适当掌握开发技能，那么做Code Review也就可以自然而然成为了一种测试手段，尤其是线上出现Bug须要做紧急修复的时候，这时候我是强烈建议测试同学对Hot Fix的内容做一下Code Review的。

跨界，就是要可以而且应该充分利用兄弟岗位的专业技能。做开发的，可以看一看测试同学是否提供了测试工具可以做接口测试或者造数据，尤其是造数据，可以算是开发自测的一个极大痛点，如果可以愉快方便地造数据，那真是善莫大焉！还可以看一看PD同学写得市场调研和竞品分析，看一看我们的用户在哪里、想一想我们的对手在做什么，知己知彼，百战不殆。

闻道有先后，术业有专攻，充分利用大家的技能，对于我们优质、高效得做好工作很有帮助。

「势」

“势”就是时机、就是环境、就是氛围。一个产品、一个团队不是孤立存在的、不是一成不变的，不同的阶段、不同的时机会有不同的策略、不同的手段。对于一个初创的APP，我想毫无疑问，试错、快速迭代是第一位的、是生死存亡的，这个时候质量可以适当放一放；对于一个市场明确、用户明确、有远大理想和前程的APP，那么打磨产品质量就是极端重要的，这里有个典型，大家看一看微信，微信的前面几个版本都是在试错、摸索，后面才稳扎稳打地逐步推出了几个重量级功能：公众号、朋友圈、微信支付，每一个功能都是精工细作，坊间传闻朋友圈出了二十几个内部版本连作为版本号的26个字母都耗尽了！

时机是纵向的，环境则是横向的。团队是否有精益求精的气质、是否有鼓励创新的氛围、是否有你好我好大家好的分享精神，这些都很重要。产品质量不是一个人做很多，而是很多人都做一点点。团队是一个整体，整个团队都重视质量，才可以把质量保障这件事情更好地贯彻下去、坚持下去；作为个人，则要积极主动地去坚持质量理念、去分享好的实践、去扩散好的理念

心

“心”就是心态，可以用3个词语概括下：

• 心怀用户，这一点很明确，用户是一切工作的出发点和检验标准。
• 心存敬畏，每一点的工作都要认认真真完成，哪怕很小的改动点。
  比如，刚开始工作的时候，有时接到的需求可能会很简单，无非就是改一下文案、或者加一个硬编码的特殊处理，很easy是不是？很快就搞定了是不是？要不要自测呢？要不要自测呢？要不要自测呢？自测就要重新编译、部署、打包、安装，好麻烦诶，而我的改动实在是很easy，完全看不出会有bug的样子。要！自！测！一！定！要！自！测！没有简单的任务，只有粗心的开发，如果测试同学可以帮忙统计下，我们必定可以发现相当大的一部分bug绝对是自测可以发现的，因为这些bug就像“光头上的虱子”一样，明摆着的，出了这种bug只能证明你没！有！自！测！这些没有自测造成的bug，造成的重复劳动，造成的对其他同学的困扰，实在是可惜、可叹、可恨！如果造成了线上异常、Crash、乃至资损，那真是悔之莫及了。
• 回归初心。
  工作多年了，拖家带口的，是不是心累了？是不是疲劳了？不再精益求精了？不再求知欲旺盛了？工作真的只是糊口度日了？午夜梦回，几多惆怅，想一想自己初入社会、初入公司的那一年，想一想当年的豪情与雄心，勿忘初心！

讲完了“务虚”，下面讲一下“务实”

2.2 所谓「务实」

如果说，“务虚”是在上的、抽象的，那么“务实”就是落地的、实例化的，针对不同的岗位、行业会有所不同，而针对“产品质量”的问题，我们可以因时制宜地制定一些军规或者说CheckList，在每一次提交代码、提测功能、发布版本之前，再回顾一下这些军规，看是否都满足了。

同样的，我们可以从三个层面来制定军规（这些军规是从我的经验和视角抽象的，不一定是最合适的，不同的产品、团队可以自定义）：

• 功能层面
• 代码层面
• 用户层面

功能层面

• 在需求评审阶段
  从用户的角度，从产品的整体规划，和产品经理一起明确靠谱，合理的需求。
  避免需求功能上的不明确，避免后期因需求不明确导致的反复改写代码。

  栗子：
  做项目过程中，很多时候，我们经常在需求评审阶段，草草了事，评审过程中一团和气，到了实际项目开发过程的时候，由于事先未沟通到位，经常会发现，有些功能点在预计范围内满足不了，有些功能点涉及多方，有些需求点各人理解不一致，有些需求模棱两口，不明确等。
  这种时候是最容易出现质量问题：赶进度，草率了事；需求不明确，做成自己的功能等等。

• 开发阶段
  明确自己开发范围，整理开发涉及的点，评估测试范围等。
  每次小迭代，完成一个小功能，都需要进行功能check，是否完整完成了需求。
  进行功能自测，对自己开发的范围有个明确的评估，整理开发涉及的点，测试范围等。

  栗子：
  做需求过程中，开发阶段，我会习惯将我开发涉及到的点记录下来，所谓的自测list，这里并不是TC的复制，而是从开发者自身的角度，认知写的list。一是为了记录自己的开发点，以便自测；二来是可以给测试提供一个参考纲要。我始终相信，只有开发的那个人才是最清楚测试范围的。测试的介入，是对于自测的一个补充，而不是替代。

• 冒烟前期
  打包进行功能预演，冒烟自测。
  不仅按照TC来自测，也要审视TC是否有遗漏点。

  栗子：
  打包自测，尽可能高仿真的自测。比如客户端的同学会有这样的经历，自测就在本地跑跑算是ok了。但是冒烟测试不通过， 原因是自测的是本地debug包，而非打出来的包。因为pojo代码混淆的问题，直接导致打出来的包不能达到预期的功能效果等。

• 测试阶段
  要针对需求逐点自我验收。

  栗子：
  测试阶段并不是说，把任务甩给测试，万事大吉了。
  不用很多时间投入，可以利用碎片化时间自测，在测试发现问题前，修掉问题。

代码层面

几个自问：

• 我的接口是否语义清晰，是否遵循统一规范，有没有存在误解的风险、有没有存在盲区
  栗子：
  举个翻页接口的例子，通常客户端与服务端的约定是从第0页开始，每页一定的数量，返回结果是总的个数，和当前请求页的量。客户端通过总数来判断是否需要上拉加载等，这些是约定俗成的。
  但如果你的接口定义为从第一页开始，返回的结果个数是当前页面的个数，客户端必须额外请求一次，才知道是否有下一页。这种做法不能算错，只能说是违反了我们的规范，违反了约定。不但增加了理解成本，同时也增加了出错几率。

• 我的数据结构是否具备扩展性

• 我是否是模模糊糊得修改了老的代码

  对老的代码需要有一定的敬畏之心，当然，这并不是说，不能动老的代码，并不是畏手畏脚，但要涉及修改，或者重构，必须是完全弄清楚老的逻辑，不清楚就要找清楚的同学弄明白之后再改。
  每个技术人员都是有情怀的，看到“恶心”的代码，总是手痒想把他重构或者重写，但动手之前，一定要弄明白老逻辑。对于需求的迭代也是如此，前期和后期不同人的投入，两者之间必须交接好，沟通到位，码代码切忌模模糊糊，大约摸改。

• 我是否已经消灭了所有(或者重要)的静态代码检查Issue

  栗子：
  不错的静态扫描工具lint，sonar，findbug等，一开始扫出来可能会比较多，并且很多可能不需要改，但长久坚持下来，会是比较大的收获的。

• 我有没有写冗余代码，有没有copy代码

  栗子：
  copy代码很爽，但也很容易出错。
  特别是新手，因为经验不足，经常到处拷代码，copy代码最忌讳的一点就是拷过来没有改完全，因为长的类似，有些时候真要花上好大的力气，才能找到出错点。copy代码可以，但真的得很仔细，现在很多时候，我宁愿自己敲，也不太愿意去copy代码。

• 我的代码是否存在性能问题，是否有页面重绘问题，是否有内存泄漏问题等

• 我的代码是否有模块化，是否能够重用，是否可以支撑不同APP的共用

  栗子:
  我们现在支持的多个APP，后面可能更多，功能需要抽象出来，在开发一个功能前，先想想，这块是否可以共用，是否可以模块化，方便后期共用。

• 我的代码是否还可以再打磨打磨

  栗子:
  这里插入一个趣闻，前段时间在阅读一个开源代码，发现其commit log里面经常出现一个词：polish。初时不解其意，后来逐个点进去看了，有些是补充单元测试、有些是修复错别字、有些是修改变量名、函数名、有些是重构，思之再三，觉得polish这个词用得真是精当：polish者，抛光也，打磨也

网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者韩坤芳授权发布。