如无必要勿增实体:简单有效的app升级方案

app开发的时候需要经常给app发布新版本，修复bug，增加功能，提升用户体验。我曾经使用一直使用uniCloud的app升级中心，这是一个很方便的工具，可以让我在云端管理我的app版本，设置升级策略，推送更新通知，跟踪升级情况。uniCloud的app升级中心有一个免费方案，可以免费使用一定量的cdn流量和云函数调用。但是，随着app数量和单个app用户越来越多，免费方案的资源已经不够用了，很可能在未来需要升级到付费方案，这样就会图增成本。

前段时间，更新一个很久之前同事开发的app时发现，它使用了一种非常简单有效的app升级方案。它没有依赖于任何第三方服务，也没有依赖任何后端接口服务，只需要在服务器上放一个xml文件，里面包含了app的版本号、下载地址、更新说明等信息。每次打开app的时候，它就会请求这个xml文件，根据版本号判断是否需要升级。如果需要升级，它就会弹出一个对话框，显示更新说明，并提供一个下载按钮。点击下载按钮后，它就会跳转到浏览器，从指定的地址下载新版本的app文件，并提示用户安装。

这种方案非常简单有效，它只依赖于服务器上的一个xml文件和手动更新的下载地址，不需要任何额外的资源和费用。它也可以灵活地控制升级策略，比如可以设置强制升级或者可选升级，可以针对不同的平台或者渠道发布不同的版本等。它还可以保证用户获取到最新的版本，避免因为缓存或者网络问题导致下载失败或者下载错误的版本。它非常符合“如无必要勿增实体”的原则，它没有引入不必要的复杂性和成本，只使用了最简单和最有效的方法实现了app升级功能。我准备以后有新的app要编写时，都采用这种类似的简单方案，并做一些改进。比如，把xml文件改为json文件，这样更加简洁和易读。还可以参考uniCloud的方式把点击更新后跳转到浏览器下载的方式改为点击更新后当前页面自动下载app文件并自动安装的方式，这样更加方便和快捷。

在这个过程中，我感受到了“如无必要勿增实体”的重要性。这是一条经典的设计原则，也叫做奥卡姆剃刀原则（Occam’s razor），它告诉我们在解决问题时应该尽量使用最少和最简单的假设和方法。这样可以避免引入不必要的复杂性和成本，提高效率和可靠性。当然，并不是说越简单越好，而是说在满足需求和质量的前提下越简单越好。有时候为了实现更好的功能和体验，我们也需要引入一些复杂性和成本，但是我们应该尽量保持平衡和适度。
奥卡姆剃刀原则的逻辑思考可以应用在程序开发的各个角落，举个真实的例子（双引号内容为当时聊天原文），在一个前端框架交流群内，有人问了这么一个问题：

他：“有人做过打卡系统吗，现在遇到一个问题, 有个统计考勤, 但是数据库中只会存已经打卡的记录，没有缺卡的记录, 这就导致统计的时候不会给我反缺卡数据, 后端想让我自己补全这个缺卡, 但是我觉得不是很妥, 这个有没有后端的人提供下思路”

我：“打卡是一个人在一天内存了一个打卡的数据，没打卡，就是没存嘛，你觉得应该是谁在什么时间存入了缺卡的数据？”

（我觉得一件事情不应当这样处理时就会反问对方是怎么想的，因为我觉得缺少的数据这种东西本来就不应该存入数据库，所以想听听他的思路）

他：“我是这样认为的 想着数据库要是有一份缺卡记录就好了”

我：“那样更麻烦，又回到这个问题了，你想怎么存缺卡数据，我理解的只能让后端每天的00：:00搞定时任务才能存缺卡数据，但是本来你已知打卡信息了，缺卡就是本月天数-打卡，让后端搞定时任务就是脱裤子放屁，增加了没有必要的程序复杂度，万一定时任务没执行呢 万一用户修改了允许打卡时间，你这个定时任务执行的时间到底有没有bug，都不知道，如无必要,勿增实体”

我：“要么数据库保持不变，后端接口处把缺卡数据给你返回，要么前端前端 增加一份缺卡数据，这是比较合理的”

简而言之，“如无必要勿增实体”是一条值得我们遵循和学习的设计原则，不止是在编写代码时，我们应该尽量使用最简单和最有效的方案，避免不必要的复杂性和成本，提高用户满意度，在生活中也同样如此，不把本来可以简单完成的事情复杂化。