那些年我们一起隐藏的bug

无论何时何地，没有可以保证软件没有bug。就像世界不能失去耶路撒冷，软件不能没有bug，失去了bug的软件一定也失去了灵魂。

问题如何产生的？ 重构之后引入的一个bug，我认为我非常鼓励重构。

问题是如何隐藏的？特定场景下才会发生，当它发生的时候我没有在意。为什么没有在意，我不确定，为什么不确定？

问题是如何发现的？当进行生产回归的时候发现了存在问题。

如何避免此类问题继续产生？很难，必须有人为此负责，给他权力，给他责任。

开发人员对系统进行了重构，并进行了提测。
对重构后的系统进行了测试，但是没有完全覆盖到所有的功能，遗留在系统内的bug静静地躺在那里，说明了什么？

1、测试漏测了，测试需要背锅。这是无法辩解的。
2、没有用户反馈，说明根本没有用户使用
3、整个业务方没有人发现这个问题，说明根本没有人在意质量
4、开发未发现此问题说明开发也没有进行自测。

技术型重构引入的问题应该怎么算？慎重评估重构后的系统的测试时间和测试质量。当你发现一个问题的时候，往往背后会隐藏着更多的问题。

除此之外的一些思考，如何防止所有的压力都放到一个人身上。质量是一个团队的事情，让一个人来承担显然说不过去。
但是，当你开始承接项目的时候，问题越来越多，你会怎么想？别人会怎么想？如何能够克服这个问题？如何能够避免发生类似的问题。

没有文档的接口是一种痛苦，就像没有轮子的汽车。
没有架构师的团队几乎是没有规范的，我知道架构师和cto的巨大差异。有架构师代表整个流程的规范化，至少一定程度的规范化。