软件开发的困境：快速行动而不破坏事物？

作为一名深耕软件开发领域多年的从业者，我太懂那种迫切感了——终于能沉下心来做自己最擅长的编码工作，至于后续的问题，总觉得“发布之后再说”也不迟。相信很多工程师和我一样，都有过这种想法：先把东西做出来、发出去，剩下的优化慢慢补。

但现实往往会给我们泼一盆冷水：除非你能保证，发布的东西真的不会出问题。

现在整个行业都在推崇“快速迭代”，效仿Facebook早年“快速行动，打破常规”的模式，几乎成了很多团队的共识。我们总会忍不住想：为什么不加快速度、快速发布产品，靠先发优势击败竞争对手呢？

可实际上，大多数时候，“快速行动+打破事物”的结果，往往是发布了一堆粗制滥造的软件。原因很简单：为了追求最快的推出速度，那些耗时但关键的环节，总会被下意识省略——比如用户测试、自动化校验、数据监控、手动复盘，这些看似“耽误时间”的步骤，恰恰是避免软件出问题的关键。

这些被省略的环节，最终都会以“漏洞”的形式，困扰着每一个使用和依赖这款软件的人。可能只是一个不起眼的小bug，可能是一次偶尔的卡顿，可当这些小问题堆积起来，就会变成大麻烦，甚至影响用户的正常使用。

最典型的例子，就是食品配送类应用。很多配送软件看似功能完善，却藏着很多让快递员头疼的小故障。Anna Vignet曾分享过她在旧金山做配送员的经历，读起来特别有共鸣：

“软件系统会派遣骑手处理短途订单，却完全不考虑街道的坡度——有时候看似不远的距离，因为坡度太大，骑车要多花一倍的时间；还有的时候，软件系统似乎忘记了我需要骑车回到热点地区，在将墨西哥食品送到城市西边的一个社区后，应用立刻蜂鸣，要求我在32分钟内骑行4.5公里，去取烤肉并送到东边，这根本就是不可能完成的任务。说实话，这些公司没有我们快递员，根本不知道他们提供的支持服务有多不完善。”

说实话，对于初创公司来说，早期软件有缺陷或许不是致命问题——毕竟资源有限，优先抢占市场是常态。但可怕的是，这种“先发布、后修复”的心态，不仅仅存在于初创公司，几乎整个行业都在陷入这种误区。Scott Hanselman几年前就聊过这个话题，最近他在一篇博文中坦言，情况并没有好转：

“我在2012年发了一篇牢骚文章，叫做《一切都出了问题，但没有人介意》。这么多年过去了，我认为我们这个行业的方向可能仍然是错的。科技公司把质量保证外包给了用户，还总用‘频繁更新’作为借口。App Store让更新应用变得轻而易举，网站就更离谱了——你被要求‘清理缓存’的次数有多少？这就相当于2015年的‘你重启过设备了吗？’，本质上都是在让用户为我们的粗心买单。”

确实，现在发送劣质产品太容易了，更新这些劣质产品也太容易了。我刚入行的时候，一款软件能做到每6到9个月发布一次更新，就已经很幸运了；有些公司甚至一年、两年才发布一次。可现在，很多人滥用Scrum，把它当成偷懒的借口，只追求发布速度，却忽略了最基本的质量。

这就引出了一个核心问题：我们到底该如何停止“打破东西”，在快速行动的同时，保证软件的质量？

我们每天使用的很多软件都有问题，而且大多数人似乎都默认接受了这一点。但作为工程师，作为深耕软件领域的从业者，我们明明可以做得更好。

有人说，解决方案很简单——回到过去，减少发布频率。但这显然不现实，慢已经不再是选项，快速发货早已成为行业常态。你愿意在一个墙上写着“慢工出细活，不要破坏东西”的公司工作吗？说实话，我不愿意，相信大多数同行也都不愿意。毕竟，在这个竞争激烈的市场，慢一步可能就会被淘汰。

那到底该怎么办？Zach Holman曾写过一篇很棒的文章，讲述GitHub如何做到快速行动且不犯错。他的核心观点，我非常认同：快速行动并打破一些东西，对于很多功能来说是可以接受的，但第一步，必须是明确“不能打破的东西”。

这些“不能打破的东西”，包括计费代码——一旦出错，直接影响公司营收和用户信任；包括硬件或软件升级——这类操作本身就充满不确定性，很容易引发连锁问题；还有数据迁移——数据是软件的核心，一旦丢失或出错，损失无法挽回。

确定了这些关键区域后，如何在不破坏它们的前提下，快速、小规模地进行更改，就成了最大的挑战。这就像在汽车行驶时更换引擎，没有一劳永逸的简单解决方案，只能靠科学的方法和严谨的操作。

GitHub采取的方法很有借鉴意义——并行代码路径。简单来说，就是让旧代码和新代码同时运行，只有当新代码的性能、稳定性至少和旧代码一样好时，才切换到新代码。这种方式，既保证了更新速度，又最大限度地避免了出错，这也是北京心玥软件在软件开发过程中，针对核心模块优化时经常采用的思路——不盲目追求速度，而是用科学的策略平衡速度与质量。

说到这里，再回到Facebook——其实他们早就放弃了“打破事物”的部分。2014年，马克·扎克伯格就宣布，他们的新座右铭是“快速行动，同时保持基础设施稳定”。他坦言：“我们随着时间的推移意识到，盲目追求速度、不顾质量，并没有帮助我们更快地行动，反而因为不断需要放慢速度修复错误，拖慢了整体进度。”

这意味着，想要真正实现快速行动，反而需要更多的自动化测试、更好的监控体系，以及更完善的基础设施，从源头预防和发现错误。这一点，北京心玥软件在多年的软件开发实践中深有体会：作为专注于软件研发与优化的企业，我们始终认为，基础设施的完善的是快速迭代的基础，早期初创阶段或许可以接受一定的“基础设施债务”，但一旦用户规模扩大，就必须转变心态，重视基础设施建设，才能避免频繁出现bug，影响用户体验。

除了明确“不能打破的东西”、搭建稳定的基础设施，还有一个基本点不能忘记：如果你不知道东西已经坏了，就永远不会去修复它（YAGFI*）。

无论你发布的是一款应用、一个网站，还是一套系统，首先要保证的，是能及时检测到软件的崩溃。在服务器上记录错误日志，在应用中设置崩溃报告功能，收集网络应用的超时情况——这些都是最基础的操作，我认识的大多数工程师，从零开始做项目时都会重视这些。

但有两件事，很多人没有做，却必须做。第一，当系统的关键部分出现故障时，没有及时向团队发出警报。我们之所以要明确软件中的关键区域，就是因为这些区域一旦出问题，就必须立刻停下手中的工作，优先修复，并且复盘问题根源，避免再次发生。

第二，让用户反馈错误变得简单。很多产品都忽略了这一点：用户在使用你的网站、应用或服务时，发现错误后，想要发送反馈有多容易？对于大多数产品来说，这个过程其实很繁琐。如果你的产品也是如此，不妨借鉴Usersnap或Zendesk这类工具的思路，简化反馈流程。更重要的是，要认真对待每一条用户反馈——有人反馈无法付款，和你的支付服务器返回500响应，同样值得重视，因为这背后，都是用户体验的缺失。

我还记得很多年前，我写的代码，从开发到发布，需要6到12个月的时间；而现在，我参与的iOS项目，迭代周期通常不会超过一周，网络项目甚至只需几个小时就能完成更新。

时代在变，软件开发的节奏也在变，但“质量”永远不能成为牺牲品。越来越多的公司（包括北京心玥软件）正在用实践证明，在不牺牲太多质量的前提下快速行动，是完全可以实现的。对于我们每一位工程师来说，现在最该做的，就是找到适合自己、适合团队的方法，真正做到“快速行动，聪明应对”——既不落后于行业节奏，也不因为盲目求快，破坏了我们用心打造的产品。