三体，但是写软件

结构之间的关系是伴随着时间的推移逐渐形成的，因为我们把不同的部分看成整体的一部分在实践中，我们应该尽量避免这样做

最近几个月有很多工作要做我过得很艰难，需要休息我的放松方式是读书，我选了刘的《三体》在我开始阅读之前，我从来不知道这本书，也不知道三体，但读完之后我感到震惊《三体》是一部科幻小说，是地球过去三部曲的第一部这本书构建了一个三体——经典力学中最复杂的问题之一，并围绕它讲述了一个故事所以让我在不破坏原著的情况下，用自己的方式做同样的事情

三体问题

为了解释三体及其与软件开发的关系，让我从单体问题开始单体问题更常被称为有心问题向心力问题试图确定一个质点在一个中心力作用下的运动状态，这个向心力源的位置是固定的说白了，恒星可以看作是静止的行星的运动可以用三角函数来表示

考虑一个稍微复杂一点的情况我们假设两个质量体通过引力影响对方的运动状态，也就是两体问题这可以用来描述地球和月球相互绕转的运动或者举个更好的例子，冥王星和冥卫一，如下图动画描述

冥王星—卡戎系统的侧视图显示冥王星围绕它外面的一点旋转。

对于包括重力在内的多种力，广义二体问题都可以转化为二体问题，这样二体问题就可以完全解决了所以两体问题也有相应的解决方法

但是如果我们再增加一个质量物体，把整个系统变成一个三体，那么事情就会变得不可预测，经常会陷入混乱对于大多数初始条件，三体没有像单体或双体问题那样的一般封闭解

软件开发中n体问题的建立

三体和软件开发有什么关系其实无所谓但如果我们思考这两件事，可以发现它们是相似的相互影响的强耦合函数和弱耦合函数可以在同一个系统中和平共存，而不强迫其中一个发生变化我们来对比一下软件开发和N体问题

起初，事情很简单，容易理解我们有一个主角，也就是一个中心，其他一切都围绕着这个中心旋转软件里功能不多，不会互相冲突

例如，我们计划开发一个库存管理应用程序我们需要做的只是插入新条目，添加或删除数量，并了解库存状态所以我们完成了这些功能

过一段时间，我们需要添加一些新的东西最好开个网店在网上卖产品所以我们开始给库存管理软件增加新的功能

首先，添加一个网页我们用可用量获得库存状态现在这个网页需要描述可用库存的状态，但这并不意味着这些原本可用的商品不在库存中，它们只是改变了状态所以我们需要在库存中设置一个新的状态我们需要知道处于现货状态的货物数量和处于可销售状态的货物数量

但是现在我们需要改变获取网店可用数量的操作来反映这种变化如果我们卖不出去，仓库里有多少货也没用我们只想显示在线商店中的现货数量我们需要再次修改网店

系统中某些物体的引力吸引其他物体改变其运动状态这两部分之间存在竞争，直到达到稳定状态一旦我们优化了函数，事情就会回到原来的可预测状态一切都按计划进行，这使我们很高兴我们仍然可以相对容易地预测接下来会发生什么，并知道一个部分的变化会如何影响其他部分

两个质量相差很小的物体围绕一个共同的质心运动。

但是事情可以优化我们可以为顾客提供快递服务因此，我们检查了现有的系统，并在每一步都进行了更改

快递服务扩大了商业贸易一个仓库已经不能满足需求，我们希望在更多的地方发展业务，系统需要能够支持这种工作方式但是这将如何影响现有的系统呢需要调整库存以适应多个位置由于该网站将减少库存商品的数量，它也需要修改，以支持多个位置但是如何做到这一点呢这也需要库存和快递服务的变化...真是一团糟

三个初速度为零的相同物体在等边三角形顶点的近似轨迹回到单体问题。

怎么才能避免这个问题呢如何才能防止一个功能对其他功能产生严重影响

太阳系中有很多质量足够大的行星，可以影响彼此的运动状态可是，如果我们试图预测地球围绕太阳的轨道，我们可以完全忽略所有的行星，只关注太阳和地球这将给我们一个足够好的实际运动的初始近似对木星轨道和任何其他行星轨道的预测也是如此

如果我们将软件系统的两个功能解耦，就可以像处理太阳系中的行星一样处理它们一颗行星的引力不足以影响另一颗行星的轨道虽然确实它们仍然相互影响，但是这些影响带来的变化不会很明显，在某些情况下甚至不存在

想象一下，如果我们试图计算未来十年复活节的日期复活节是基督教的节日，在春分后第一个月满月后的第一个星期天当我们计算这些日期时，我们真的关心木星的79颗卫星吗当然，我们也不必那样做

我们把软件开发方案分解成许多小部分，让每个部分围绕太阳运行这里的孙可以是一个信息中介，一个服务总线，或者仅仅是一个已建立的契约决定我们的太阳系需要多少解耦绕着太阳转的小部件是模块，域还是微服务并不重要重要的是小部件应该尽可能的独立这将使他们更容易理解你甚至不需要知道木星有79个卫星来这样计算复活节日期

事实上，月球显著地影响着地球的轨道如果我们关心的是太阳和地球的关系，那么我们不是在说地球和月亮绕太阳的轨道，我们只是在说地球的轨道无论一个函数有多复杂，我们只需要在整个系统中把它们看成一个整体

这样，我们不需要处理太阳系120万个天体，也不需要处理大约700个行星，小行星或卫星我们只考虑八大行星因为一般来说，当我们谈论太阳系的时候，我们只关心这八颗行星虽然这个计算结果并不完美，但对我们来说已经足够精确，不会给我们的工作带来问题

简化问题

当我们考虑仓库的库存时，我们到底在考虑什么可能是一个大仓库，里面储存了很多货物仓储工作是什么为了储存货物直到出售我们的软件系统应该只考虑这些功能

网店应该只负责展示商品，创造购买但是在网店购买需要改变库存状态那么如何解决这个问题呢现在有很多解决方法，但是请告诉我真相

购买已经是一个足够复杂的功能了它获得订单，检查库存以查看是否有可供购买的商品，执行支付并创建运输这可能看起来只是另一个功能，但是由于它的大小，它可以很容易地被分成单独的部分

我们制定了严格的库存合同根据合同，我们可以得到所有货物的清单和所有可用货物的清单我们可以检查这些货物是否可以出售，并减少它们的数量网店只需要知道有货就可以了如果我们决定支持软删除，或者在某一点上支持多个状态，就像我们在上面的例子中所做的那样，在线商店不需要知道这些变化只需更改网店收到的数据，在网店不知情的情况下，即可完成上述操作

我们需要为购买功能做同样的事情合同要求完成购买的操作网店发起了这个操作，然后它的任务就完成了购买功能接管它检查是否有可用的商品，然后如果一切正常，它就完成购买，并相应地减少库存商品的数量

在整个系统中，我们已经清楚地将所有可以独立存在的功能分开我们从库存开始，所以它当然有自己的系统接下来我们增加了两个功能，分别是网店和购买，可以独立实现

我们确实有快递服务，但是到目前为止整个过程都不需要知道它的存在所以我们也要把它当成一个独立的系统我们不应该把它强行塞进现有的体系里，让它们相匹配

好吧目前，我们还没有一个具有许多复杂依赖关系的功能的系统我们有许多子系统，每个子系统都有特定的复杂性，它们共同构成了一个兼容且可持续的解决方案

结论

建立，维护和扩展软件是一件复杂的事情一开始可能看起来很容易只是加了这个功能但是我们添加的东西越多，等式就变得越复杂如果我们想强迫太多的事情，最终我们会发现自己陷入了一个无法解决的问题两者之间只有一线之隔

对于多体问题，我们可以尽可能的简化系统，分成很多小的部分这些小问题很多人都能解决，比如小学生都能解决单项问题三体似乎没有解决办法但是，乍一看，这两类问题的区别很小所以我们可以尝试把它分解成几个部分，用软件设计的思想对问题做一些简化的近似

原始链接: