软件质量稳定性之殇

摘要：软件系统的稳定性，主要决定于整体的系统架构设计，然而也不可忽略编程的细节，正所谓“千里之堤，溃于蚁穴”，一旦考虑不周，看似无关紧要的代码片段可能会带来整体软件系统的崩溃。我将和大家聊一聊软件质量稳定性之殇，分多篇刊发。

1 回顾

在上一篇文章中，我们从黑天鹅事件谈到了蝴蝶效应、墨菲定律。一言以蔽之为，要把软件研发中的质量搞好并非易事。质量是一个综合的大命题，涉及到业务准确性、稳定性、可用性等方面。比如xx大促，某厂商几小时无法交易；收藏夹商品丢失；用户享受的优惠不符合预期，营销规则复杂难以解释等。

黑天鹅告诉我们要走出经验主义，不要把自己知道的东西太当回事了，而不知道的事比知道的事更有意义。蝴蝶效应告诉我们要及时感知问题，止损和熔断，避免问题范围扩大包括传染到其它相关领域。墨菲定律告诉我们，你知道的但是忽略的漏掉终会出问题，在黎明破晓前！

2 业务高速发展带来的变化

那么，我们得思考一下为什么会这样。在N年前，就有人想把软件从业者变成像制造工人一样的，不断流水线工作。但是这几乎没什么可能，因为要解决的问题域太复杂。虽然业界有很多规范、标准、套装软件，但是仍然未解决问题之万一。我们来看一下是如何复杂的。

以我们的一个team为例，7个人1年做了400多个需求。平台能力在不断发展，有人说高速公路换轮胎，有人说飞机飞行换引擎，这样的事情也没少干。大家都知道满足需求，实现业务价值是软件的天职，至于为了更好适应未来发展的平台化能力也好，新特性也好只能在业务发展的过程中做掉。

在这么多需求的过程中，除了技术以外，对于业务包括规则要有深度把握，包括上下游的一些问题。如有评估不到位，问题就大了。分析到设计阶段的缺失，到代码、测试、发布这些阶段可能一如既往的缺失了。早些年，某些系统已经复杂到只有1-2个人能搞懂部分了，幸好这些系统今天都完成了拆分和治理。

3 技术债问题

技术债务是由Ward Cunningham在1992年的 告中创造的一个比喻，被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。它和金融债务非常相似。一个人贷款了就会产生债务。如果他定期还款，那么所创建的债务是可以接受的，不会产生进一步的问题。但是，如果他不还款，就会以利息作为惩罚，并随着不还款次数的增加而增加。如果这个人很长一段时间不能支付任何款项，那么应计利息使得他更难以偿还债务。在极端情况下，该人不得不宣布自己破产。

为了快速做业务，采取简单粗暴的方案是大家表示支持的。[临时方案]的毛病不在于这2个月临时了，而在于这个临时上线之后，再无人管了，俗称[有人生、没人养]。1年如果做5个临时方案，就等于欠了5笔债务。欠债并不可怕，怕的是没有偿还计划，或者借口没有时间，或者接口等业务不那么高速发展的时候。吊诡的是好的业务一定是永远都没有时间的，而差的业务确实不用发展了，因为被下线了，或者整个公司close了。So，珍惜高速发展的业务，记得去更换引擎，偿还债务，欠的，迟早要还的。有关技术债，推荐当当史大官人在周评比中名列前茅的文章：当技术宅遇上技术债，我个人觉得是这方面有调皮调性的好文章。

ps：

• 不忘初心：严格遵守SOP（标准操作程序）

• 减少侥幸心理、增强风险意识

• 狠抓作风养成

• 严厉处罚无后果违章，既要结果，又要过程正确

文章深刻的提到，随着飞行经历的增加，许多程序显得啰嗦、许多检查显得多余、以至于越飞程序越少、多做越简化且不把规章当回事…

总之，质量问题就是达摩克利斯之剑高悬于空中。你不注意它，它就会在某一天降落。上述提到的复杂度问题、业务高速发展、技术债、对于工具的掌握能力等都可能为品质埋下了隐患。能不能破，如何破待下回分解。

ps：图片from平和多思的臧老师