从软件工程诞生之初，「减少 bug」成了所有开发团队的共同目标。要减少 bug 就要知道 bug 是怎么来的:
原因
产品设计。产品逻辑存在漏洞，或者悖论。表现出来的症状是用户使用成本高，以及在非常规的操作情况下，产生了非常意外的结果。例如服务器报错，客户端闪退，严重的比如支付相关的系统带来巨大的隐患。
业务理解。对业务不熟悉，写出的代码一定程度上和业务相背。
细节把控。没有处理好代码中的边界条件。
历史数据。新的 feature 不可避免的会去读写历史数据，而历史数据可能有的是脏数据。
基础不足。例如对语言、框架不熟悉，或者理解错了。出现了主观上认为意料之外的事情
准外部原因。例如某些框架可能自身有没有修复或者没有被发现的 bug
外部原因。比如各种服务提供商出现了故障。
技术协调问题。 比如前端和服务端，服务端之间的微服务调用，一方提供的服务没有按照预期的逻辑执行
解决&避免
产品尽量做到可以顺利进行 「prd review」，部分具体的实现需要和 dev 一起讨论。大多数情况下，简化逻辑是可以优先考虑的点，对用户和开发都会比较友好。
程序员自身的理解能力和工作态度。理解能力原则上在招聘期间就需要被过滤，工作态度需要从管理者自上而下地去影响，这是一个需要长期控制调整的事情。
提高编程能力和保持 unit test 来最大程度避免遗漏掉代码中的边界条件。
数据库设计满足基础范式和现代化的设计规则。如果已存在脏数据，那么依照问题的严重性来确定短期内是否考虑加大时间成本。同时关键节点打印好日志，并完善日志收集系统。
原则上通过招聘来控制。但个人的学习积累也同样重要，需要避免个人发展速度慢于公司发展速度。
技术选型上保持谨慎的态度。如果某些技术没有经过可靠的验证，原则上不引入。除非这个技术实现方式非常清晰，并且团队成员一致认可。
编码上与第 3 点保持一致。架构设计上做到能够熔断、降级，确保不因为单独故障影响到整个系统。
给项目/API加上 change log 甚至 hook 来确保协议稳定，搭配上自动生成的文档。开发过程中保持高效的沟通。