软件设计中的“公因式”

开发任务完成了之后，确实挺闲的。闲着没事肌肉就不舒服，感觉是快要萎缩的状态。赶上快过年了，学也学不动了。这里随便写一些自己在软件开发中的一些感悟。说实话这些感悟其实挺重要的，知道、了解还有发现问题这其中差别其实挺大的。这块作者主要说一下我们在数学中常见的就是提取公因式。

现实生活中的小区、城市甚至国家的产业布局在微观上都是聚合的。或者说是产业聚集的。像北京是政治中心，那么就有很多国家机关。像上海就有很多金融机构。为啥不把这些组织分割的很远的原因显然是搞事情不方便呗，加上路途遥远，得不偿失。再举个例子比如小区有公厕和运动场所。我们不能想象随地大小便，随地都可以运动的世界是什么模样。所以说我们在搞事情的时候一定注意提取公因式，将相同的属性的事物按照自然规律进行妥善摆放。

由于计算机是人类自己创造的，人定义的规则便是计算机寻找规律的边界。计算机也只能通过不断的试错来寻找合理甚至最优解，虽然计算机可以做这件事。然后通过模拟计算得出最优编程规则，甚至是架构设计的准则。然而这种过程确实比较复杂，其实也没有什么意义，建模也是相当费事。在某种程度上说让计算机来安排世界的运行，这件事其实是一个NP难问题.

但总归来说人在地球上活了那么长，显然理论上是问题不大的。加之计算机系统通过自己计算得出自己的结论显然太难。

既然计算机决定自己是意见很难的事情，那么剩下的就只能通过人按照自己的经验去决定了。在计算机世界里，确实随地大小便，随处运动场没有什么不可以。对于外在的人来说我们只关系其结果的准确性。但是如果要拥有一个强大的、永远不会脱离时代的系统。那么还必须有经验的人去设计。也就是要按照厕所是厕所、运动场是运动场的规范去做。这种规范责任保证系统具有竞争力的关键，因为咋不能说纪律严明的军队战斗力不强，炮兵是就是炮兵，工兵就是工兵。耦合的代码以及耦合的架构设计也必将走向一团散乱，最终的结果就是苟延残喘，终将被自己淘汰。

如此在代码实现和系统架构上系统设计人员还是要大刀阔斧的进行提取公因式。

程序编码过程中提取公因式简单的来说就是业务分包，按照业务领域进行拆分。再进一个程度就是广泛使用经典的设计模式来提升灵魂。业务拆分的原则就是核心共享，互不干涉。这就需要编码人员有较高的全局意识，能够根据业务总体在系统体系建设初期察觉到核心共享区域的逻辑，在项目的中期甚至后期再去发掘这种共性代码就为时已晚。互不干涉主要是对核心共享原则的说明，也就是我们在通过提取代码的公因式的时候的目标就是不能干涉业务。核心公因式代码本质上是为业务代码服务的，不能因为其他业务的修改而改变现有业务的逻辑结果。

架构设计阶段公因式，其实主要针对于各种服务的技术组件。换句话来说就是将编码的核心公因式代码换成核心公因式服务。我们需要在设计的初期对各个服务进行公因式提取。被提取的公因式要具有广泛的兼容性，因此在设计和实现的过程中一定要目标远大。不能以解决现有问题为目标，相反要以解决相关的所有问题为己任。也就是说公因式服务在能力上有非常强大，并具有对接任何应用的能力或者潜力。在抽取公因式服务之后整个系统平台就变成了专营的业务领域。每个服务只做自己擅长的事，并且提供所擅长的业务领域所有能力，并具有新业务的兼容能力。

在抽取完公因式之后，我们的服务就和代码就不再是耦合不清，厕所和运动场不分的垃圾代码了。当然可能问题也由此而出，是否每个系统都要按照提取公因式的方法进行改造？个人觉得需要分开来说，如果不是大型系统，那么就不需要提取架构公因式。但是代码的公因式在任何时候都需要严格执行，这是检测工程师能力的基础标准。对于大型系统来说肯定需要严格进行公因式抽取，否则在代码层面开始腐败，在架构层面产生瓶颈甚至逻辑死锁问题，最后终将被自己消耗致死。