软件汤

作为两个孩子的父亲，其中一个还是新添的，我很难像往常一样抽出时间来写博客。要想挤出时间而不偷工减料，真的很难。但有趣的是，为人父母和孩子成长这两件事，或许会以一些意想不到的方式交织在一起，而这往往出乎人们的意料。

几天前的一个晚上，我和儿子一起读安·英格尔斯写的睡前故事《冰淇淋汤》，故事就发生在我身上。这本书讲的是一个小男孩想做冰淇淋蛋糕。一开始他做得很简单，后来不断添加配料，最后却弄得一团糟：变成了一碗冰淇淋汤。

这对于软件行业来说是一个完美的类比。任何经历过真实项目完整生命周期的人都亲眼目睹过这种情况。

配料

我们的故事始于一个想做冰淇淋蛋糕的男孩。于是他拿了一些配料、一个大蓝烤盘和一些冰淇淋，就开始动手了。他心中有数，知道自己想要什么，所以就放手去做。这太简单了，怎么可能出错呢？

我们都希望最新的全新项目能够完美无瑕，或者尽可能完美。所有代码都是全新的，需求也很简单。我们可以编写单元测试，搭建完善的构建流程，遵循最佳实践，并充分利用最先进的技术。

团队对每个拉取请求都进行仔细审查，确保所有规范都得到遵循，测试都已编写完毕，等等。首发版本即将发布，整个团队目前都感觉很棒……至少现在是这样。

轻拍

当我们的小男孩继续制作他美味的冰淇淋蛋糕时，他的思绪开始游离。他注意到有很多配料想要添加，这些配料完全不在他最初的计划之内，所以他不得不调整策略，重新安排，把它们塞进去：

我把它拍平。

我轻轻拍打。

现在我可以添加一些内容了。

需求总是在变化，范围也在不断扩大，这是常态。作为软件工程师，我们的职责就是灵活应对这些变化，确保我们的产品能够提供客户期望的价值和功能。即使是精心设计的完美全新项目，也未必能够很好地应对这些变化。我们很少有时间重新架构，必须按时交付，必须确保一切顺利进行。

所以，我们“草草了事”，偷偷地把一个可能不符合最佳实践的功能加进去。我们会加一些注释，也许还会创建一个工单来重构它，但目前这个权宜之计就先这样吧。

或者它可能根本算不上什么功能，而只是你想加在蛋糕上的一些闪亮装饰，但这些装饰可能与其他部分不太协调。比如，自己编写搜索引擎、消息总线，或者把你的前端重写成你在 Hacker News 上看到的某个时髦的前端，总之就是这样。

关键在于：任何未经充分规划或深思熟虑的项目变更都可能导致严重的技术债务。作为工程师，你必须接受这一点，因为企业或产品的生存往往比代码的美观更重要。

问题在于，如果你不断地“压平”蛋糕以便“再添加一些”，而不花时间确保蛋糕能够承受得住，它可能会开始散架。

这不是蛋糕，这是一团糟。

故事的结尾，我们的小男孩并没有得到他踏上这段旅程时梦寐以求的漂亮蛋糕，取而代之的是一团糟。

我做了什么？

看起来像黏糊糊的东西。

我觉得我做出了冰淇淋汤。

如果你从事开发工作一段时间，你肯定经历过这种情况；你肯定尝过“冰淇淋汤”的滋味。在多次发布、临时添加功能和赶工之后，很多时候为了给“更多那种东西”腾出空间，一些原本应该完善的东西会被“阉割”。

这些零零碎碎的小问题累积起来，最终会导致代码库缺乏凝聚力，到处都是复制粘贴的代码，而且在任何重大变更的地方都极易出现回归问题。你必须接受这一点。软件并非完美无缺，就像烘焙一样，需要时间、练习和经验才能让一切按计划进行（即便如此，也很少能完全如你所愿）。

这一切的关键在于，除了编写代码之外，软件开发过程中还有许多你无法控制的因素。归根结底，你的客户不会关心底层代码的运行情况；他们只想知道软件是否能按预期工作，是否“有效”。

也就是说，你可以注意以下几点，以避免你的项目变成一团糟：

• 迭代——如果你的领导层愿意倾听，那就努力争取缩短发布周期。即使只是内部版本，也能防止版本发布之间功能范围超出预期，从而更好地应对任何“自然”增长。
• 认真对待——这与其说是个人目标（虽然你也应该重视），不如说是一种文化。你的团队和管理者都应该关心产品，无论对内还是对外。当收到拉取请求时，要仔细检查，确保代码没有重复，也没有引入不良模式。这些都是小步骤，但却能产生影响。
• 坚持既定路线——科技发展日新月异，很容易让人想要追逐最新的框架或热门技术，但务必谨慎行事。这类决策需要经过深思熟虑，以确定它们是否适合你的项目、团队以及产品的长期目标。

好吃！

故事结尾，我们的小主人公吃完了蛋糕，却发现最后得到的却是和他原先计划完全不同的东西：冰淇淋汤。你或许会以为他会失望地把汤全扔掉，但他没有。他舀了一大勺，脸上带着灿烂的笑容，还大声说了声“好吃！”。

软件开发很少能完全按照计划进行，但这没关系。需求变更、范围蔓延和截止日期都是真实存在的，它们会迅速将一个美好的蓝图变成一锅乱炖。你的项目可能看起来很糟糕，里面可能充斥着你祈祷永远不会面世的糟糕代码。软件的妙处在于，最终用户很可能并不了解，也不关心你的架构、模式或那些蹩脚的代码。他们想要的是能够让他们的生活更轻松、更有能力的东西，但最重要的是：它必须能用。

就像那个男孩和他最终喝到的那碗冰淇淋汤一样，虽然看起来乱糟糟的，但味道依然很棒。软件系统也是如此。我确信，无数企业都是建立在用胶带、goto语句和梦想勉强拼凑起来的代码库之上的。关键的区别在于，尽管它们在幕后看起来很糟糕，但它们确实有效，并且能够创造价值。

构建系统时，专注于控制你能掌控的因素。努力在遵循最佳实践和务实之间找到完美的平衡点（如果无法控制，那就尽可能详细地记录下来）。努力激励你的同事也这样做，并培养精益求精的软件工艺文化。

所以，在下一次重大版本发布之后，不要纠结于缺点或代码库的混乱程度，而应该关注你为客户带来的价值。他们并不知道你的产品使用了多少不匹配的组件，也不知道你为了节省成本而使用了非原生数据库或非品牌的前端框架。他们只关心你的软件是否让他们的工作更轻松，是否赋予他们更多能力。

这相当于软件界的“Yum！”。