对软件质量的看法

作者就职于物联网行业一家行业知名公司，文章提及的 taurus 是公司内部的一个业务支持系统，CIDC 是一个软件项目

  近一年来公司一直围绕软硬质量做过很多改进措施，发起了质量月，我似乎看到了希望。首先，在这篇文章中提及对事实的评论很多是我主观方面的，如果有领导看到也请谅解。

  2021 年 10 月 taurus 灾难式上线，一直到现在都未能解决本质问题，按照常理，一个经过两年迭代的应用系统应当已经稳定了，但事实上并没有，系统每次升级都要经历一次渡劫，用户吐槽吐槽不断。 从我的视角看，taurus 不是一个成功的产品，甚至不是一个合格的产品。做为公司核心业务支撑系统，系统每天有 350 人在线、1.6 万次页面访问，理论上不应该让用户经常感觉到系统有故障，更不应该让公司客户参观是碰到系统无法使用的情况。

  我质疑过很多次，但每我人精神上说服自己：这段时间忙完应该重点解决我们的问题，领导们不急，我急个啥呢。 但是这已经过去两年了。如果这次质量月是要找正能量案例，那我可能走错片场了。我这里要说的都是问题，以及我个人提出的改进措施。

一、软件质量是什么？

  软件工程上定义软件质量为：功能性、易用性、可靠性、效率、可维护性、可移植性，后 4 项是软件需求中的非功能性需求。道理大家都懂，领导也跟我说过：软件质量是设计出来的。的确，质量是软件的一项必要属性，是软件需求规格说明书中的一个章节。但实际上，在面对繁重的开发任务时，我们可能过于重视功能性、易用性的 KPI 考核，而忽视了其他方面，一切为了版本发布、一切为了当前版本交付。被忽略的质量问题在产品被推到终端客户后才暴露出来。

  软件质量是 bug 数量吗？ 不是！ 99%的 bug 只能体现功能性、易用性等表面问题，但可靠性、稳定性等很难通过短期的测试暴露出来，至少当前公司还没不具备这样的能力。这种能力不是说测试没有技术能力，而是没有资源、没有精力、没有质量体系来支撑我们做。比如 9 月 11 日 taurus 升级前，我已经拿到了几个关键接口的测试结果，也将结果反馈给相关人员，但是没有任何应对措施，只能霸王硬上弓，系统升级后趋于崩溃才会有人来排查解决。个人觉得使用 bug 数来衡量软件质量很不合适，同样使用 bug 数来做为开发人员的 KPI 也不合适。软件质量第一指标应该是用户的最终反馈、用户口碑。其次是开发和运维人员对系统升级和运营的代价。

  软件质量也是一种制造工艺、是品控。我们一直强调软件工程概念，引入 cmmi、IPD 等流程体系，似乎引入了流程体系我们的软件就像搭积木，水到渠成。忽略了软件开发质量也是一种制造工艺，制造工艺需要工程师持续打磨迭代，提高良品率，需要师徒制的言传身教，需要大家一起学习成长，需要软件工程师投入情感、需要用心。所以改进质量不可能像强心剂一样，来一针立马生效。

  软件质量也是一种文化，应该像公司的核心价值观一样，深入人心。

二、我们当前面临的质量问题

  出与职位、工作局和自身认识的限性，看问题存在片面，请谅解。

1. 真的要同一个产品同一套代码吗？

  3 年前 CIDC 项目启动时的理念是全新设计、抛弃历史报复、面向未来，向前看，一套代码一个产品满足所有客户。青岛特钢客户要求定制报警处理流程， 一个很明确的客户定制且难度不大的需求，我们为了保持代码一统一性硬是拒绝了半年时间，最后客户不妥协才勉强满足客户需求。

  当 CIDC 衍生为 taurus 时面对不可逃避的历史问题和完全不同的应用场景，我们不得以定制很多代码，从此我们背负了违背同一套代码原则的过错。时至今日，我理解领导层的战略方针，中台战略在大厂的关环加持下，似乎已经成为软件行业的真理。 直到近期渐渐有人开始质疑中台的正确性，如同质疑微服务一样，infoq 上已经有质疑中台，远离中台。

  同一套代码，一个中台是我们追求美好的愿景，是我们努力的方向。但经过两年来的反复折腾，我觉得我们目前还不具备中台能力，或者说我们还不具备做好底层共用代码的能力。很多时候我们知道问题出在哪里，而又出于职责与权限范围，对与共用基建代码只能放任问题在生产环境上逛奔。 而基建代码没有明确的责任人，或者基建代码责任人远程业务，远离客户，不能体会面对用户和客户的痛楚，对问题不走心，不能深入解决问题。共享代码是否真的好用，infoq 上有一篇文章《代码共享的陨落：为什么说内部库是反模式》,指出理想与现实的差距。

  共享的库会造成团队间的耦合，影响工程设计的效率。应用程序可能会被间接地绑定到特定版本的依赖项中，从而导致各种令人头大的兼容性问题。不认真仔细地进行管理，破坏性改动或回归都可能会带来严重的后果。

  代码的复用与耦合之间需要权衡，手动复制粘贴代码或许是一种解耦机制，如此一来应用程序得以按不同的速度发展，代码的稳定性也能有提高，因为应用程序不用再吸收共享依赖关系中的更新。

  很多共享库的目的并不总会非常明确，尤其是项目名称中的“common”、“utility”，或者“helper”关键词。这些通用库的职责总是模糊不清的，很难长期保持清晰的界限。再加上“通用”这些术语的主观意义，工程师们往往会把这些库当作是任何可能在未来复用的功能的垃圾堆放场。

  通用库往往会重新实现语言功能或是解决已解决的问题，比如身份验证、序列化、数据的访问和加密。通用库不仅会带来不必要的维护负担，还会在代码中引入陌生的函数调用，增加新使用者的学习难度。不是说共享代码不好，想反，共享代码、不重复造轮子行业内公认的原则，设计模式、架构设计原则是软件行业几十年来大师们共识的真理。现实实践中总会遇到理论未曾提及的问题，如同法律不能覆盖所有案件，需要律师和陪审团来反复论证，得到最佳结论。CMMI 课程中老师提了一个问题，CMMI 是教我们做事的吗，是公司业务流程的规章制度吗？ 不是，CMMI 不能直接给我们制定流程，我们要深入学习 CMMI，结合公司现有的业务、流程、人员规模、市场环境，使用 CMMI 模型来改进现有流程，提高效率。

  当前软件使用的 Athena 开发框架是基于开源框架的二次开发框架， 我们的解决方案有中有各种 common、helper 类，公用组件会发各种 nuget 程序包，无形中将我们的学习成本和开发调试链路拉长。解决方案中复杂的程序引用、包引用不兼容问题时常让我们无法快速投入工作，已是天下苦秦久矣。业务抽象化、代码下沉并不是一劳永逸的事，相反要某些情况下会给我们带来额外的代价。在业务不稳定、技术能力不足时这些都动作将会是我们进度的障碍。再者，从目前看来，我们的产品只有两种形态，数据中心形态与远程终端形态，强一致性已经让我们付出了很多代价，当维护一致的代价已经远大于两个分支的代码代价时，是否应该放宽约束，使用架构设计原则中的接口隔离与依赖倒置理论，将代码强一致性放宽为接口一致性。

2. 技术与业务的冲突

“这些人是不是傻！软件怎么能这么用？搞蹦了自己负责”，“这是什么需求？谁设计出这么不合理的需求？做不了，要做你自己做去。”

“这是啥软件，这功能为什么这么设计？怎么这么难用！”，”这软件太不稳定，没法用，问题太多，质量太差”。

  软件研发人员与软件用户（这里主要批项目交付、销售经理公司内部同事）间的口水战已经持续很久，且没有缓和的趋势。双方的立场不同，kpi 不同，汇报对象不同，产生冲突是必然的，但冲突过多甚至已经影响到正常合作。是技术主导还是业务主导，各有各的说法，没有对错。需求主导会让研发丢失对市场与业务的敏感度，响应需求不及时，软件质量不理想，迭代周期长等。研发主导会脱离业务需求，最终产品可能不是用户真正需要的，主导是研发层领导，可能会形成面向领导开发，领导说你行你就行，不行也行，说你不行就不行，行也不行。

3. 开发人员工作量超载，无心关注质量

  研发同事的工作量一直有些超载，长期超负荷工作对人的身心上肯定有影响的。尤其是心态，没有好的心态就没有好的工作状态。面对繁重的任务，我们的目标只能是完成任务，不是做好任务。目标是通过测试，只是追求减少 bug 的数量，而非做好产品并让客户满意。

  工作心态也会让内部发生很多冲突，我有过几次心态失衡，在领导与同事面前咆哮，愤怒之后没解决任何问题，最终选择妥协。是心态崩溃的体现，也是心智不成熟的表现，在此再次向大家道歉。大家各扫门前雪是在高强度工作量下的自我保护机制，自己的工作量太多，对 kpi 无关的事根本无暇顾及，给他人形成的印象是不配合、不合作。

有段时间盛传一句话：

不要提问题，我们不缺提问题的人，我要的是解决问题的人。

这句话与"解决不了问题，就解决提问题的人"的段子如出一辙。问题太多了，不让人提问题只是掩耳盗铃、一叶障目，被抑制的问题转移到客户终端只会更多更严重。通常情况下，打工仔提出的问题是自己解决不，超出能力、智力、权力等范围，希望得到领导关注与支持。当然也有部分可能故意夸大问题做为邀功的资本，但不管怎样，都不能关闭问题反馈通道，关闭了问题反馈通道，等同与扼杀了员工的工作积极性。

三、我们能做什么

1. 提高产品最终质量反馈的评价制度

  bug 数量不是产品的主要评价指标，bug 数量是软件活动过程中的一个过程指标，与质量没有直接关系。加班多少、完成了多少个需求只是苦劳不是功劳，给有苦劳的员工即时激励没有问题，但产品是否成功，质量卓越不能在过程指标中体现。当 bug 数量多少、设计文档数量、需求开发数据量、项目进度等度量值成为目标时，我们可能忘了初心，我们得到的可能是华丽的数据，而不是良好的客户反馈。要控制质量，需要多个团队目标一致，必须考虑得更长远一些。

那软件的质量到底谁来负责？《质量不好，其实是管理无能的表现》一文中提及：

- 看一位质量经理人是否懂质量，看其用什么样的质量指标与部门沟通，与老板汇报就基本把握；

- 看一家企业是否重视质量，看看质量经理人在企业里面是“几号位”就知道；

- 看一家企业老板是否真正重视质量，看其在不合格品的放行时的态度就很清楚。

所以，我认为首当其责的就是管理层，是质量是一家公司的内涵的体现。质量不好如同一场战争的失败，不会有人提及前线战士的作战不利，肯定是将领指挥决策不当，质量的提提升由高层意志决定，是向眼前的业务妥协还是坚持质量底线。

2. 提高员工素质

  素质不止是码农们的专业技能水平，职业素养、对职业对公司的热爱等。把公司发给大家德鲁克的书读几遍，相信都会收获颇丰。把做完工作转成做好工作，提高员工素质是提高软件工艺的一个重要环境，当前没有办法完全量化人的主观行为，只能通过相信与激励来改善，引用大师德鲁克的一句话：管理的本质就是激发人的善意。

3. 提高过程管理水平

  管理方面的事不懂，不妄加评论。