论软件质量的不同形态：椰子vs苹果

lsekfe

　我至今在两家公司工作过，第一家是华为，第二家是蚂蚁金服。在两家待的时间都足够长了，谈谈对两家公司软件质量控制的一点感悟。
　　用一句话来对比两家的软件质量的话，我称为“椰子型”vs“苹果型”。两家公司基本可以代表传统软件公司与互联网公司的不同的质量管理标准。
　　椰子型
　　华为擅长做“椰子型”软件，外壳坚硬无比，内部一包水。
　　华为的研发流程是很早就花大价钱从IBM引入的IPD研发流程，大致分为几个流程(参考)：
　　Charter(立项) --> TR1/2/3 --> PDCP(中期) --> TR4/5 --> EDCP(结项)
　　一个项目周期基本上是一年，PDCP之前是项目的设计和PoC阶段，可以改方案和设计，PDCP之后就不允许修改设计了，TR5要达到验收标准， 验收不过等同于项目延期，会对项目的Manager和团队的考评有重大影响，所以TR5的验收是极其重要且严肃的。
　　整个开发模型沿用了很多年，基本上是个大的软件开发瀑布模型，周期长，与现在倡导的敏捷开发模式完全背道而驰。 这套开发模式引入之后一直在使用，使得华为一直对软件质量有着极其优秀的掌控，帮助华为站稳了ICT和企业市场，但过于笨重也遭到了很多内部人员的吐槽。 所以在云BU成立以后，也做了局部的敏捷开发的尝试。
　　华为的整个研发体系和流程都是很笨重的，也很严肃。研发人员和测试人员的比例可以达到2:1左右（各个部门有不同），由于大量的测试人员的存在，对外出口的软件质量是极好的，不会出现太明显的Bug和崩溃等现象。
　　所以在我看来，对外表现的是“椰子型”的外壳。
　　但是我比较受不了的一点是，内部的人员质量参差不齐，差的真的是太差了。在我参加“三营”培训时，10个人一组做敏捷开发的培训，全组竟然只有我一个人能写程序，其他9个人给我做测试，也是很搞笑。更可笑的是我们组最后做出来的软件评分是第一名，可能是由于开发：测试达到了1:9吧。
　　大量的低水平开发造就了垃圾一般的代码质量，所以华为的软件只能黑盒来用，要是你看到了实现的代码，怕是要战战兢兢吐一口老血了。
　　“水”代码其实也不能完全怪垃圾程序员，我自己也写过很多自己不屑的垃圾代码，让我来告诉你原因。
　　在最后的突击测试阶段，管理者是要看测试的漏洞数据的，要求随时间的推进测试人员发现的代码bug数应该递减，最后趋近于0，这很合理对吧？ 还有两项要求，要看bug的解决时长，这个关乎manager的考核指标，所以要求每日的bug要日清；并且TR5时系统内的bug必须清0，我不管是多么难解或者重大的bug，一定要修复。
　　这两项要求给我造成了巨大的麻烦，设想一下下午6点的时候，测试给你提了5个bug，你挨个看了一下，有1个几乎不可能在短时间解决，于是你跟领导反馈，领导说必须严格按照质量标准，今天一定要解决。 这个情况就多次发生在了我的身上，于是在通宵都仍然无法解决的情况下，只能用大量的workaround去想办法从cmdline和api调用层面屏蔽掉这个bug，于是我亲手给这座代码屎山贡献了更多。最终这包屎山变成了“椰子”来到了用户手里。
　　内部的整套研发流程，在我看来是有好有坏的，确实严格的管理流程给了华为对产品的严密把控。华为就是有30%的一流人才带着70%的庸才做出来世界一流软件的质量，但是对我这种有点轻微代码洁癖的人来说，是无法忍受的。 我也迫切的希望能与更多优秀的人合作，而不是浪费时间教笨人做事，所以离开华为，加入了互联网公司，希望能找到更多志同道合的人。
　　苹果型
　　互联网公司就是完全的另一个极端了，我来介绍下蚂蚁的研发流程：
　　[流程加载失败...]
　　结果就是没有研发流程，质量把控流程完全没有，测试工程师也很少。 据我所知，这种模式在互联网公司比较流行，即使是Google，Facebook这种大厂也是如此，Facebook是全栈工程师，每个人开发的组件直接上线运行和实测，所以听闻Google的工程师经常嘲讽Facebook是“踩着香蕉皮滑行”，滑到哪儿算哪儿。
　　这种模式之所以并没有引起大的问题，在我看来主要是两点原因：
　　1.人员平均水平较高
　　每个人的主观能动性比较高，代码平均质量较高，会主动写单元测试和集成测试，习惯于敏捷开发，CI/CD。靠着优秀程序员的自我修养，代码质量仍然获得了一定的保证。
　　2.面向消费者业务较多，bug不敏感
　　ToC的业务对产品的质量要求并没有企业级或CT级要求高，Web形态的产品完全可以先推一个公测版的产品出去试试效果，对于Bug的存在是有一定容忍度的。本身互联网产品迭代快，对速度的要求胜过对质量的要求。
　　所以好的互联网公司的产品质量通常是“苹果型”的，外表摸起来有一点点硬，打开来看，内部代码质量也不错。 由于测试人员缺失以及快速迭代的需求，很难将外表做的像椰子一样。
　　互联网的开发流程较敏捷，留给工程师的自由发挥空间比较大，所以从我个人来说，是更喜欢互联网这种模式的。二八效应决定着一套80分的软件做到100分需要额外耗费巨大的人力，在不成正比的投入产出面前，有必要衡量下是否要继续优化下去？
　　没有流程其实造成了更大的问题，项目立项随意，周期随意，没有验收标准，为了KPI每个人都在努力的造轮子却不管重复不重复。所以我看到的是，对外我们是有无数的黑科技呈现出来，从外部看我们的软件研发能力是无比强大的，但是很多黑科技只能偏居一隅没有机会获得大规模推广，大规模推广的项目也有很多致命的缺陷导致寿命不长。
　　由此，阿里巴巴已经开始沦落为“geek的自留地”，自己内部玩的嗨，更多的却是“内卷”而不是创造实际价值。
　　选哪个？
　　二八效应对应着中国的一句成语“行百里者半九十”，所以在继续提升产品质量的时候，我们都要掂量一下是否值得如此大的投入？
　　不同的企业会有不同的选择，ToB or ToC的选择会有大的不同。在我还在华为的时候，我痛恨70%的庸才拉低了华为的档次，拉低了我对外的credit，但是华为的80分到90分恰恰需要70%的庸才作为一颗颗螺丝钉消耗自身的精力来完成，而Google，Facebook的优秀人才们只愿意做软件开发的前一部分创造性的工作做到85分，而非整天无休止的消耗自己。由此造就了“椰子型”与“苹果型”软件的不同。
　　选哪个？从政治正确的角度考虑，我们要做“石头型”的软件，从公司层面，“椰子型”是不错的选择，从工程师个人角度，还是“苹果型”更加友好。
　　我现在要承认，自己还是很怀念IPD研发流程的，它可恨却又很有用，帮助产品找到正确的方向以及一直运行在正确的轨道上。蚂蚁相比华为，还是有小作坊vs大厂的既视感的，但是我无意贬低任意一家，对前东家和现东家我内心都是喜欢的。